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

Code is owned by whoever wrote it, unless something transfers that ownership to someone else. For an employee in the UK, the employment contract usually does that, for work done in the course of employment. That one sentence 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 rights to what they write unless the contract says otherwise. Many early contracts, especially the ones agreed by email with a friend of a friend, say nothing. A surprising amount of the world's software is technically 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 has an author, and each author has rights unless they gave them up. 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. Almost every modern product is built on open-source components, and every one of them comes with a licence. Most licences ask little more than attribution. Some, the copyleft licences, ask that software combined with them be published under the same terms. 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. Producing the list is usually a day's work with the right tool; 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?