GB
.png)
Platforms such as Cursor and Claude Code can build, debug and ship features from a simple prompt, sometimes before you’ve hired your first developer. For founders using AI to build an MVP, that’s genuinely powerful. It makes it possible to test ideas, launch products and get them in front of customers faster than ever.
But there’s a catch.
One prompt can introduce third-party code into your product that you didn’t write, didn’t actively choose and might not be free to use however you like.
That probably won’t feel like the biggest concern when you’re racing to get an early demo working. It becomes much more important when you start signing enterprise customers, raising Seed or Series A investment, or preparing for an acquisition.
Open-source software can be used by startups, but it remains subject to licence conditions.
Founders using AI coding tools should understand:
Open-source software isn’t the problem. The risk comes from using it without knowing what is in your product or which conditions apply.
Very few software products are built entirely from scratch.
Developers routinely use existing packages and libraries to handle common functions such as user authentication, payment processing and email notifications. Many of these components are open source, meaning the code is made available for others to use under the terms of a licence.
Imagine asking an AI coding tool to add a login system to your product. It might create some of the code itself while also installing an existing open-source package to handle authentication.
The feature works. Brilliant.
But that package is still third-party software, and its use is governed by its own licence.
Under the Copyright, Designs and Patents Act 1988, computer programs are protected by copyright. An open-source licence gives you permission to use, copy or adapt that code, but that permission will usually come with conditions.
The important question isn’t simply whether you’re using open-source software. It’s which licence applies, whether you’re complying with it and whether its conditions work for your business model.
MIT, Apache 2.0 and BSD licences are generally considered founder-friendly.
They typically allow startups to use, modify and incorporate code into proprietary products, provided certain conditions are followed. These might include retaining copyright and licence notices, documenting changes or complying with other attribution requirements.
They’re often relatively straightforward to work with, but they still shouldn’t be ignored. “Permissive” does not mean “no obligations whatsoever”.
GPL, LGPL and AGPL licences contain what are known as “copyleft” conditions.
Depending on the particular licence and how the software is modified, combined, distributed or made available to users, you may need to license relevant parts of your software on the same terms and make the corresponding source code available.
That doesn’t automatically mean using one GPL-licensed component will force you to publish your entire codebase. The answer will depend on the licence, the component and exactly how you’re using it.
It does mean you shouldn’t install it and hope for the best.
Open-source software isn’t the problem. Using it without knowing which licence applies, or whether its conditions fit your business model, is where the software licensing risk begins.
Most open-source compliance issues don’t arise because a founder deliberately decides to ignore a licence.
They build up gradually because nobody has been given responsibility for checking what is entering the product.
Here are some of the mistakes we see most often.
Code posted on GitHub or another public platform may still be protected by copyright.
If there is no licence attached, there may be no clear permission to copy, modify or incorporate it into your product. Publicly visible does not necessarily mean free to use.
An AI tool might add several external packages while completing a single task.
You check whether the feature works. It does. You move on.
What can easily get missed is which components were introduced, where they came from and what licence terms apply to them.
One open-source package may depend on several other components, which may themselves rely on even more components.
Each dependency can have its own licence. Checking only the headline package might not give you the full picture of your open-source exposure.
As employees, freelancers, agencies and AI tools contribute to the product, it becomes increasingly difficult to remember what was built internally and what was introduced from elsewhere.
Without a basic record, the company may struggle to explain:
Paying someone to build your product doesn’t necessarily mean the copyright transfers to your company.
Unless the rights are properly assigned in a written and signed agreement, a freelancer will usually remain the first owner of the copyright in the work they create.
That can leave a significant gap in your software IP ownership, especially if the freelancer built an important part of your core product.
Customer and investment agreements may ask you to confirm that the company:
Those promises are difficult to stand behind if nobody has reviewed the codebase or kept records of what it contains.
Vibe coding doesn’t create a new category of intellectual property law. Existing copyright and software licensing rules still apply.
What AI-assisted software development changes is the speed of development and, potentially, how much visibility a founder has over the way a product is being built.
The courts distinguish between copying protected code and independently developing software that performs a similar function.
In SAS Institute Inc v World Programming Ltd, the Court of Justice of the European Union found that the functionality of a computer program was not protected by copyright in the same way as the particular expression contained in its source code.
In other words, a startup can develop software that performs a similar function to another product. What it can’t do is reproduce protected code without permission.
AI-assisted development can make that distinction harder to monitor in practice.
You might know what you asked the tool to create, but not necessarily whether the output was:
Building something quickly and building something you can confidently say you own are not always the same thing.
At MVP stage, incomplete records can feel like a problem for another day.
But as your startup grows, investors, customers and potential buyers will expect your position to be clear.
During Seed or Series A fundraising, investors may carry out software IP due diligence to understand whether the company owns its core technology and has the right to use every important third-party component in its product.
Enterprise customers may ask for warranties and indemnities confirming that your software doesn’t infringe anyone else’s rights and that you’re complying with applicable open-source licences.
A potential buyer will investigate the same issues during acquisition due diligence.
Finding an open-source compliance problem at that stage can mean:
None of those jobs is especially convenient when you’re trying to close a major customer, complete a fundraise or sell the company.
Open-source compliance isn’t just technical housekeeping. It can affect customer confidence, your negotiating position, the speed of a transaction and, in more serious cases, your valuation.
An early-stage startup doesn’t need a hugely complicated open-source compliance programme from day one.
It should, however, be able to explain what its product contains and why it is entitled to use it.
A few practical steps can make a significant difference:
That final step isn’t a substitute for specialist legal advice or a proper technical review. It can, however, help you create a much clearer record from the outset.
The founders who get this right aren’t the ones who avoid open-source software or stop using AI coding tools.
They’re the ones who build with visibility.
They know what is in their product, who owns it and why the company is entitled to use it.
That starts earlier than most people think. Not when an investor starts asking questions or a buyer opens the data room, but with the first prompt, the first package and the first line of code that didn’t come from your own keyboard.
At Founders Law, our specialist technology and IP lawyers help Seed and Series A startups navigate open-source licensing, software IP ownership, development agreements, AI-assisted development and customer warranties.
Getting these foundations right early is usually much easier and considerably less expensive than trying to fix them under the pressure of a fundraise, major contract or acquisition.
The founders who arrive at due diligence with clean records don’t just complete the process more smoothly. They negotiate from a stronger position too.
Open-source software can generally be used commercially, but the conditions depend on the relevant licence.
Permissive licences such as MIT, Apache 2.0 and BSD are often relatively straightforward. Copyleft licences such as GPL, LGPL and AGPL can impose additional conditions, depending on how the software is modified, combined, distributed or made available.
Not automatically.
The answer depends on the relevant licence, the component and exactly how it has been used. Copyleft or unfamiliar licences should be reviewed carefully before the component is incorporated into your product.
Paying a freelancer doesn’t necessarily transfer the copyright in their work to your company.
Unless the rights are properly transferred through a written and signed agreement, the freelancer will usually remain the first copyright owner.
During Seed or Series A due diligence, investors may want to confirm that the company owns its core technology and has the right to use important third-party components.
They may also examine whether the company has complied with relevant open-source licences.
Start by keeping a record of external packages, their versions and their licences.
You can also ask developers and AI tools to identify new components before installing them, check package dependencies and use scanning tools to identify potential licensing issues.
These steps don’t replace specialist legal advice or a proper technical review, but they can create greater visibility from the outset.
Building with AI or concerned about your open-source exposure? Get in touch for specialist open-source software and AI development legal advice. We’ll help you protect your IP and make sure your codebase is ready for whatever comes next.
