Open Source Code: Who Owns Your Software IP?

Hiring developers can feel like a big step forward for your startup. Your product is finally being built, features are shipping and your codebase is starting to look like a real asset.

Then someone mentions open source software and investor due diligence, and the whole thing can suddenly feel less straightforward. If your developers have used open source components, does your business still own the software? Can you sell it, licence it or raise investment on it?

The good news is that open source code is normal in modern software development. The key is knowing what was used, what the licence says and whether your contracts and open source software policy clearly protect your business.

Can You Own Software That Uses Open Source Code?

Yes, you can own software that uses open source code, but you usually won't own the open source components themselves.

Think of your software as a house. Your developers may build custom rooms, layouts and features that belong to your business. They may also use pre-made materials, such as open source libraries, frameworks and packages. You can own the custom work, but you use the open source parts under their licence terms.

That distinction matters because open source doesn't mean free from legal obligations. It means the owner of that code has made it available under a licence. That licence may let you use, copy, modify and distribute the code, but only if you follow the rules attached to it.

For many startups, this isn't a problem. Common permissive licences, such as MIT, BSD and Apache 2.0, are often workable in commercial products if you keep the required notices and follow the licence terms.

Other licences need more care. Copyleft licences, such as GPL and AGPL, can create obligations to share source code in certain situations. AGPL can be especially sensitive for SaaS products because it may apply where users interact with the software over a network.

So, the real question usually isn't, can we use open source? It's:

• Which open source components are in the product?
• What licences apply to those components?
• Have your developers complied with those licences?
• Does any licence restrict how you can commercialise your software?

These are the open source software legal risks investors often look for because they affect whether your product can be sold, licensed to end users, funded or acquired cleanly.

Who Owns Software Code In The UK?

It depends on who wrote the code and what your written agreements say.

In the UK, software code is usually protected by copyright as a literary work under the Copyright, Designs and Patents Act 1988. You don't register copyright with the UK IPO in the way you register a trade mark. Copyright generally arises automatically when the code is created.

But automatic copyright doesn't always mean your company owns it.

If Your Employee Writes The Code

If an employee creates software in the course of their employment, the employer is usually the first owner of copyright, unless there's an agreement saying otherwise.

Even so, your employment contract should still include clear IP wording. This helps avoid arguments about side projects, work done outside normal hours, inventions, documentation, designs, databases and confidential information.

If A Contractor, Freelancer Or Agency Writes The Code

If an external developer writes code for you, they usually own copyright in their work unless they assign it to your business in writing.

Paying an invoice doesn't automatically transfer copyright. A copyright licence to use the work isn't the same as ownership. This is where many startups get caught, especially when the first version of a product was built quickly by a contractor or a friendly developer before the company had proper documents in place.

For a UK copyright assignment, the assignment needs to be in writing and signed by or on behalf of the person assigning the rights. In practice, your software development agreement should include an IP assignment clause, and sometimes you'll also want a separate software IP assignment deed to tidy up past work.

Companies House records can show who owns shares in your company, but they won't prove that your company owns the code. Investors will usually want to see the contracts or assignments that show the IP has actually moved into the company.

What Are The Main Open Source Software Legal Risks?

The main risk is that open source terms may limit what you can do with your product or create compliance issues that worry customers and investors.

Open source risk isn't just a technical issue. It can affect valuation, funding, sale negotiations and your ability to give warranties to enterprise customers.

The most common risks include:

• Copyleft obligations: Some licences may require you to make source code available if you distribute software that includes or links to the open source component.
• AGPL issues for SaaS: AGPL licences can be triggered by network use, including API access, which is why SaaS startups need to be especially careful.
• Missing notices: Many licences require copyright notices, licence text or attribution to be included with your product.
• No audit trail: If nobody has tracked which packages were used, you may struggle to answer investor or customer questions later.
• Developer misunderstandings: A developer may assume an open source package is fine because it's publicly available, without checking the licence.
• Contract breaches: Your customer contract or terms of use may promise that the software doesn't contain certain open source code, even though your developers used it.
• Security and maintenance issues: Old packages can carry security vulnerabilities, which can also affect your UK GDPR and Data Protection Act 2018 compliance if personal data is involved.

Here's a practical example. Maya runs a UK SaaS startup and is raising a GBP 400,000 seed round. Two contractors built the first version of her platform using 18 open source packages. Most are MIT licensed, but one server-side library is AGPL licensed.

During diligence, the investor asks for an open source inventory and the contractor agreements. Maya has invoices, but no signed IP assignment from one contractor. She also can't show that anyone approved the AGPL library.

The commercial outcome is simple: the investor doesn't necessarily walk away, but they ask Maya to fix it before completion. She needs to get a signed assignment, replace or ring-fence the AGPL component and document the remaining licences. That costs time, slows the round and gives the investor a reason to push for stronger warranties.

What Should An Open Source Clause In A Software Development Agreement Say?

Your software development agreement should say when open source can be used, who approves it and what the developer must do to keep your business compliant.

A vague clause saying the developer may use open source software is usually not enough. It doesn't tell you which components are being used, which licences apply, whether the use is allowed in your product or who is responsible if the licence terms are breached.

A stronger clause will usually cover:

• Approval: The developer must not include open source code without your prior written approval, or must only use it within agreed rules.
• Disclosure: The developer must give you a list of all open source components, including version numbers, licence names and links to the licence terms.
• Licence compliance: The developer must comply with the relevant licence terms, including notices, attribution and source code obligations.
• Restricted licences: The developer must not use copyleft or network copyleft licences, such as GPL or AGPL, in a way that could require your proprietary code to be disclosed or licensed, unless you have expressly agreed.
• IP ownership: The agreement should still assign the developer's original work to your company, while making clear that open source components remain subject to their own licences.
• Records and delivery: The developer should provide an open source schedule or inventory with the final code, so you're not trying to reconstruct it later.
• Fixes: If the developer uses unapproved open source software or breaches a licence, they should help replace it, remediate it or bring it into compliance.

The right wording depends on the nature of your product. A small internal tool, a mobile app, an enterprise SaaS platform and a product you're planning to sell to regulated customers may need different levels of control.

Practically, you don't want a clause that blocks developers from using everyday, low-risk tools. You want a process that lets them move quickly while making sure the business knows what is in the product and can answer customer or investor questions confidently.

How Can You Manage Open Source Code In Your Business?

You don't need a complicated legal process for every package. You do need a sensible system that your developers will actually follow.

For most startups and scaleups, that means:

• Keeping an up to date open source inventory or software bill of materials.
• Setting rules for which licences are pre-approved and which need legal or founder approval.
• Requiring developers to record new packages when they add them, not months later.
• Checking notices and attribution before release.
• Reviewing higher risk licences before distribution, customer onboarding, fundraising or a sale process.
• Making sure old contractor work has signed IP assignments and open source records where possible.

Your policy can be short and practical. For example, it might say MIT, BSD and Apache 2.0 components are generally permitted if notices are preserved, while GPL, LGPL and AGPL components need approval before use. It can also explain who approves requests and where records should be stored.

This is also a good time to check your customer-facing documents. If your terms say your software is entirely proprietary, but it actually contains open source components, that wording may need to be adjusted. Many software businesses instead explain that the product may include third party open source components that are licensed under their own terms.

What Will Investors And Buyers Want To See?

Investors and buyers are usually trying to answer one question: can the company commercialise the software without a serious IP problem?

They may ask for:

• Software development agreements and IP assignments from contractors, agencies and founders.
• Employment contracts with IP clauses for technical staff.
• An open source inventory, including licence details.
• Evidence that risky licences have been reviewed and managed.
• Copies of customer contracts and terms that match how the software is actually built and supplied.
• Confirmation that required open source notices and attribution have been included.

If you can provide these quickly, it sends a strong signal that your company is organised and that your software IP is investable. If you can't, it doesn't always mean the deal is over, but it can create delay, extra legal costs and uncomfortable warranty discussions.

The best time to fix this is before a funding round, enterprise customer deal or acquisition process. Cleaning up IP ownership and open source records early is usually much easier than doing it under pressure during due diligence.

Key Takeaways

• You can own your custom software code even if it uses open source components, but the open source parts remain subject to their own licence terms.
• In the UK, employee-created code is usually owned by the employer if created in the course of employment, but contractor code needs a written assignment.
• Open source licences vary. Permissive licences are often manageable, while copyleft and AGPL licences can create bigger commercial risks.
• Your software development agreement should control open source use, require disclosure and keep a clear record of the components used.
• An open source policy and inventory can make fundraising, customer contracting and sale due diligence much smoother.
• If your product was built quickly by contractors, it's worth checking IP assignments and open source compliance before investors or customers ask.

If you'd like help with software development agreements, open source policies, IP assignments or investor due diligence, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.