Most founders I meet assume the company owns its code, but far fewer have checked whether the paperwork supports that belief. In a typical startup the code has been written by founders before incorporation, by employees, by freelancers and by agencies in other countries, and increasingly with the help of AI tools, and all of it sits on top of open‑source libraries written by other people.
I raise this with founders early because customers ask for warranties about ownership and investors check it during due diligence, and a buyer will not pay full value for a product the seller cannot show it owns. Some of the code the company will own outright and some it will only have a licence to use, and both are acceptable as long as the company knows which is which and follows the licence terms.
Trace the people who contributed
Start by listing everyone who has written code or produced design work for the product, including founders, employees, freelancers and agencies, and then match each person to a signed document that gives the company rights in their work.
Under the Copyright Act 2022, work an employee creates in the course of their employment generally belongs to the employer, subject to the terms of the contract. A freelancer or agency, however, usually owns what they create unless they assign it to the company, and that assignment must be in writing and signed by the person giving it. Paying an invoice does not transfer copyright, and this is the gap I find most often.
An agency can only pass on the rights it has received from its own developers and subcontractors, so if you used an agency, it is worth asking how it obtained those rights and, at the least, getting a warranty and an indemnity from it. Where two or more people created a piece of work together, assignments may be needed from each of them.
Read the assignment against the work you use
An assignment should describe the work it covers and include future work produced under the same engagement, and it should name the correct company. Problems often arise where a Delaware parent was formed after a developer was engaged by the Nigerian company, or the other way round, because if the parent is meant to own the code there has to be a chain of documents from the developer to the parent.
Some agreements say ownership only passes once the developer has been paid in full or the work has been accepted. It is important to check whether that condition was met, and if it was not, to fix the position now with a properly dated document, since backdating a document to cover the gap creates a new problem.
Code is not the only asset to consider. The product may also involve inventions that could be patented and brand assets, each of which needs its own transfer, and because authors have moral rights under the Copyright Act, the assignment should deal with those rights as far as the law allows.
Account for third‑party components
The company should keep a list of the open‑source and commercial components it uses, recording where each came from and which licence version applies. Permissive licences such as MIT and Apache mostly require the company to keep copyright notices, while copyleft licences such as the GPL can require the company to release its own source code when it distributes the software. The AGPL can be triggered simply by offering the software over a network, so the way the product is delivered needs to be checked against these terms.
Commercial libraries come with their own limits on users and deployment, and often on transfer. Those limits should be read before the company lets customers host the product themselves or starts reselling it, and read again whenever the delivery model changes.
For code written with AI tools, the company should keep the tool's terms and a record of how the output was reviewed, which I discuss in using AI coding tools and understanding your rights. Any licence issue found by a code scan should be followed up until someone has decided either to comply with the licence or to replace the code.
Check rights brought from earlier work
Founders often bring code from a previous job or side project into the company. A former employer may own that code, and the founder may also owe confidentiality duties about it, so the dates and the old employment contract should be checked before the code is used in the product. Where there is doubt, the safer course is to rewrite the code independently and keep a record of how the new version was produced.
University projects and earlier collaborations raise the same question, since many universities claim rights in work produced by students and staff. In those cases the company should obtain permission or an assignment from whoever owns the work, or plan to replace it.
Where the company uses material under a licence, it should record what the licence allows, so that customer contracts and warranties do not promise more than the company actually has.
Keep control of what you need to run the product
The source code, build scripts, deployment documentation and infrastructure credentials should all sit in accounts the company controls. Before a developer leaves, someone else on the team should confirm that they can build and deploy the product without that developer's help, and recovery access should stay with the company when the developer's account is removed.
Domains and design files should be included in the company's asset register, with details of who owns them and whether any transfer is still outstanding, and designers outside the technical team should be included as well. I cover trademarks and domains in choosing and protecting the business name.
If a dispute with a contributor looks likely, the repository history and access logs should be preserved before anyone deletes accounts or changes permissions, and the company should take advice before restricting that person's access.
Give warranties the evidence supports
Customer and investor agreements usually ask the company to warrant that it owns its software or has the right to use it. Those warranties should match the company's records, with any exceptions disclosed through the agreed process, and where there is a gap in ownership, the company should decide what it can honestly promise while the gap is being fixed.
If you find a gap, the first step is to approach the person who holds the rights and agree a corrective assignment on accurate terms. If that person will not cooperate, the company may need to rewrite the affected code or limit how it is used, and it should tell its decision‑makers what remains unresolved. I explain how this plays out during a funding round in handling legal issues an investor finds.
The simplest protection is to make a rights check part of every release, so that when a new contributor or component is added, the agreement or licence is collected at the same time. That is much easier than trying to find a former freelancer two years later.
This article is general information and not legal advice. For guidance on your specific circumstances, speak with us directly.