Who owns the code?

Ask a founder who owns the company's code and the answer is immediate: we do, obviously. Ask for the paperwork and the room goes quiet. In every technology review I have done for a lender or an investor, ownership was the first thing checked and the most common gap, and the gap is almost never the result of anyone doing anything wrong. It is the result of nobody having done anything at all.

How ownership goes missing

In the UK, copyright in code usually belongs to whoever wrote it. The main exception is an employee writing it in the course of their employment, where the employer owns it by default. That rule hides three ways ownership goes missing.

The first is work done before the company existed. Founders write the first version at the kitchen table, then form the company, then carry on. Nothing transferred the kitchen-table code to the company. It still belongs to the person who wrote it, who is now a shareholder, a director, and possibly, in a few years, an ex-founder with a grievance.

The second is contractors. A contractor is not an employee, and the default is that they keep the copyright in what they write unless the contract assigns it. The client may have some right to use the work, but that is not ownership, and it may not be enough for a buyer or a lender. Many early contracts, especially the ones agreed by email with a friend of a friend, say nothing. A good deal of software in small companies is, strictly, still owned by freelancers who have long since forgotten it.

The third is the things nobody thinks of as code: the data an AI feature learned from, the designs, the documentation, the firmware in a device that a contract manufacturer's engineer adjusted on the production line. Each may have an author with rights of their own unless those rights were assigned. For AI features the question has a second edge, because the company also needs the right to use the data it trained on, and data has a way of arriving without its permissions.

Why it matters at the worst moment

None of this stops the company working. The product runs, customers pay, nobody asks. The question arrives with money: a loan secured on the business, an investment round, an acquisition. At that point someone's lawyers ask for the chain of title, the documents that show every contribution was assigned to the company, and the company discovers it has a chain with missing links.

The fix at that point is to go back to every contributor and ask them to sign. Most will. Some cannot be found. One or two, having worked out what the signature is worth to the deal, will name a price. I have watched deals slow to a crawl over exactly this. The company that had done the paperwork five years earlier, for the cost of a template and an afternoon, would have walked straight through.

Open source: the other half

The second half of ownership is what the company has taken in. Modern software products commonly incorporate open-source components, each governed by a licence. Most licences ask little more than attribution. Some, the copyleft licences, can require software combined with them to be released under the same terms, depending on the licence and on how the software is distributed or, for some licences such as the AGPL, offered to users over a network. That is a fine bargain for a community and a bad surprise for a company whose business is selling the software.

A review asks for a list of components and their licences, a software bill of materials, and whether the company has a policy about which licences it accepts. Most small companies have neither. With the right tool the list can often be produced quickly; deciding what to do about the one component that should not be there can take longer. The same list is the starting point for knowing what else the product depends on, which is the next question any reviewer asks.

What good looks like

Good is boring. Every founder, employee and contractor has signed an assignment of the intellectual property in their contributions to the company, including anything from before incorporation. The signed copies are in one place. There is a current list of third-party components and their licences, and someone owns the job of keeping it current. Where the product depends on something the company does not own, a platform, a model, a supplier, the dependence is written down with what the company would do if it changed.

A company can put all of that in place in a few weeks, for very little money, at any time before it is needed. Doing it after the question has been asked costs more, takes longer, and occasionally cannot be done at all. It is one of the things that separates a professional system from a hobby one, and it has nothing to do with how well the code is written.

Three things worth taking seriously

For founders: find the assignments this week. If any founder, employee or contractor has not signed one, get it signed while everyone is still on good terms.

For investors and lenders: ask to see the assignments, not to be told they exist. The Technology Risk Snapshot starts with this question because it is the one most often answered with assurance rather than evidence.

For CTOs: the bill of materials is yours to own. Produce it once, keep it current, and decide the licence policy before the reviewer asks what it is.

I am an engineer, not a lawyer. The principles above are the ones a technology reviewer works to; for the position of a particular contract or contributor, ask someone who is.

When did your company last see, rather than assume, the paperwork that says it owns its own product?