← All insights Technology

The rights in your codebase, and who is actually holding them

A company can pay every invoice, part on good terms with every developer it has used, ship a product that works, and still discover years later that pieces of it belong to somebody else. Usually nothing has gone wrong. The paperwork was never done, and in the United Kingdom the paperwork is what moves ownership of software.

Copyright protects source code in much the same way it protects a manuscript. It arises automatically as the code is written, there is no register anyone can consult to check, and at the moment of creation it belongs to the person who wrote it. That last point is where the common assumption comes apart, because the person who wrote it is very often not the company that paid for it.

The gap stays invisible for a long time, and the reason it does is worth understanding before anything else. Ownership and use are different things. A business that commissioned work and never took an assignment of it can usually carry on using that work perfectly lawfully. Nothing breaks. Customers are served, releases go out, the accounts are signed off. The position only becomes visible when the company needs to do something that requires it to own rather than to use.

The default position, and the exception to it

The first owner of copyright in code is the person who wrote it. There is one clean exception in United Kingdom law: where the author is an employee and wrote the code in the course of their employment, the rights sit with the employer from the outset, unless the contract says otherwise.

Both halves of that exception carry more weight than they look. Whether someone is an employee is decided by the substance of the working relationship rather than by the label on the agreement, and a developer invoicing through their own company is generally not your employee however embedded in the team they were. And employment alone is not enough: the code has to have been written in the course of the job. A support engineer who built a tool at home in their own time, which the business later came to depend on, is not obviously covered by it.

Everyone outside that exception keeps their rights until they sign them away. A transfer of copyright has to be in writing and signed by the person giving it up. Payment does not do it. An enthusiastic email confirming the work is yours may not do it. A shared understanding between two people who both meant the same thing certainly does not.

What an implied licence gets you, and what it stops short of

Where work is commissioned and no assignment is taken, the courts of England and Wales will usually imply a licence permitting the client to use the work for the purpose it was commissioned for. This is why so little appears to be wrong for so long.

What is implied, though, tends to be the minimum needed to make the arrangement work commercially, and no more. An implied licence may well be non-exclusive, so the developer is free to build something similar for somebody else. It may not carry the right to have a different team rewrite or extend the code, which is a separate permission from the right to run it, and it is the permission that matters most when the original developer is no longer available. It may not be transferable at all, which becomes the central problem when the company itself changes hands.

So the business operates comfortably on rights that are perfectly adequate for operating and inadequate for selling, raising against, licensing onward, or stopping a former supplier from reusing the same work elsewhere.

Who is usually still holding something

The same handful of positions recur, and they tend to sit in the earliest and most structural parts of a product rather than in recent work.

• The contract developer. Engaged quickly, delivered, invoiced, moved on. The engagement was often a conversation and a purchase order, and there is nothing in the file that transfers anything.
• The agency. Agencies do have terms, which is the problem. Their standard terms frequently grant the client a licence to use the deliverable while retaining ownership of the frameworks, libraries and internal tooling the deliverable was built on.
• The founder who built the first version before the company existed. A company that has not been incorporated cannot employ anyone and cannot contract with anyone, so the rights in that early work sit with the individual until they are assigned. Where that founder has since left, the assignment is a negotiation rather than an administrative step.
• The employee whose contribution fell outside their role. Hired for one thing, wrote another, and the business now runs on it.

The agency position deserves a second look, because a signed assignment from an agency is only ever as good as the agency's own chain of title. Agencies subcontract. If the individual who actually wrote the code was engaged by the agency without an assignment of their own, the agency was not in a position to give you what it purported to give you, and no amount of care in your contract fixes that.

The retained background layer has a practical consequence that rarely gets priced at the time. Owning the deliverable while holding a licence to the platform it sits on means the deliverable cannot straightforwardly be taken somewhere else. Moving to another supplier means rebuilding rather than migrating, and the cost of that is usually discovered at the point the relationship has already broken down.

When the question is finally asked

It is almost always asked by somebody else. Investors and buyers run technical diligence precisely to trace who wrote what and whether it was properly transferred. Lenders taking security over intangible assets ask the same. So, increasingly, do large customers, whose procurement teams want a warranty that the supplier owns what it is licensing to them.

What those parties want is documents. The evidence available is typically a repository history and a folder of contracts, and repository history identifies whoever each developer configured it to identify: a personal address, a handle, an account the company never controlled. Attributing authorship confidently after the fact is slow work, and the people who could confirm it have often gone.

Where a gap is found, it does not usually stop a transaction outright. It converts into terms: a specific warranty, a disclosure against it, an indemnity, a portion of the consideration held back, or a condition that a confirmatory assignment be produced before completion. Each of those is a cost, and the last one has a particular character. It puts a named individual on the critical path of a deal with a published timetable, and invites them to consider what their signature is worth in that setting. The same signature, sought while the relationship was current and nothing turned on it, was usually available for the cost of sending the document.

People move, and companies get struck off

Retrospective tidying assumes the counterparty is findable, alive, solvent and willing. Often enough, at least one of those fails.

A developer may have emigrated, changed name, or died, in which case the rights form part of an estate and you are dealing with executors. An agency may have been acquired, and the entity that holds the rights is now part of a group with no interest in doing you a favour. Most awkwardly, where the work was done through a limited company that has since been dissolved, any property that company held, including copyright, may have passed to the Crown as bona vacantia. Recovering the position then means engaging with the Crown's representatives, or applying to restore the company to the register, neither of which moves at the speed of a transaction.

None of these situations are unusual, and each of them takes the problem outside the range of things that can be fixed by sending somebody a document and asking them to sign it. What was an administrative task while the relationship was live becomes a piece of work with its own timetable, and that timetable will not adjust itself to fit a deal.

What is not worth doing

Not every gap is worth closing, and treating them all as equally urgent wastes money that has better uses.

A business with no intention of raising, selling or licensing its software onward, running an internal system supplied under clear terms, may get very little for the cost of a retrospective assignment exercise. If the licence covers what the business actually does, and the supplier relationship is stable, the ownership question can reasonably sit where it is.

A blanket programme of chasing signatures from everyone who ever touched the repository is worse than disproportionate. Approaching a former contractor who has given the matter no thought at all, with a formal legal document and a request for urgency, is a reliable way of prompting them to wonder what it is worth. Where a relationship ended badly, that letter can turn a dormant question into a live dispute over an asset nobody was arguing about.

Most of the value sits in deciding which contributions still matter to the product as it stands today. Early code that has since been rewritten from scratch carries no ownership risk worth paying to remove, whatever the commit history says about who first wrote it. Doing that sorting is the cheap part of this work, and it belongs before any letter is drafted, not after.

This guide is general information about how these matters usually run. It is not advice, and nothing becomes advice until terms are agreed in writing. Brandleys Legal Ltd delivers reserved legal activities alongside regulated partners.