Who Owns the Code? IP, Handover and Getting Locked In

Why paying for it is not the same as owning it

The intuition almost every buyer arrives with is that commissioning something means owning it. You paid for the software, so it is yours, in the way that a commissioned photograph or a fitted kitchen is yours.

Copyright does not work that way. In most legal systems, copyright in a created work vests initially in its author. For an employee that is usually handled by employment law and the copyright sits with the employer. For a contractor or an agency, it stays with them unless it is assigned to you in a written agreement. Payment creates an implied licence to use the thing you paid for — but a licence is not ownership, and its scope is exactly as broad as a court later decides it was.

The practical difference matters most at the moments you care about. Under a licence you may not be able to modify the code with another firm, sell the business with the software included, or open-source any part of it. None of those come up while everyone is happy. All of them come up during an acquisition, a dispute, or a change of supplier.

What the assignment clause has to actually say

A workable IP clause has several parts, and contracts commonly get three of them right and one wrong.

• A present assignment, not a promise. "Supplier hereby assigns" transfers rights on the terms stated. "Supplier shall assign" is a promise to do something later, which requires their cooperation at precisely the moment you may not have it.
• Everything, named. Source code, but also designs, wireframes, database schemas, infrastructure-as-code, build scripts, test suites and documentation. Deliverables lists that say "the software" leave real arguments about the rest.
• Effective on payment, not on project completion. Otherwise a project abandoned at eighty per cent leaves you owning nothing while having paid for most of it.
• Further assurance: an obligation to sign whatever paperwork is needed later to perfect the transfer, including with registries.
• Moral rights waived where the jurisdiction recognises them, so an individual author cannot later object to how the work is changed.

One term deserves particular attention. "Work made for hire" is a specific concept in United States copyright law that applies to a narrow set of categories and, for most software, only when there is also a signed agreement. In the UK, the EU, India and many other jurisdictions the phrase has no equivalent statutory effect at all. A contract relying on it alone, governed by law outside the US, may transfer nothing. Use an express assignment and treat any "work for hire" wording as belt-and-braces rather than the mechanism.

What a supplier legitimately keeps

It is reasonable, and normal, for a development firm to retain some things. A supplier who assigns literally everything including their internal tooling is either not thinking clearly or is about to become unable to work efficiently for anyone.

The row that causes the most trouble later is the third. If a supplier's proprietary framework is woven through your application and licensed only to you, non-transferably, you own code you cannot move and cannot sell with the business. Ask directly whether any such component exists, and if it does, get the licence terms in writing before the first sprint rather than during the exit.

The four ways you get locked in while owning everything

Ownership is necessary and not sufficient. Most lock-in in this industry has nothing to do with intellectual property.

Infrastructure you do not control

If the application runs in the supplier's cloud account, under their domain registrar, with their certificates and their monitoring, then owning the source is close to theoretical. Insist that every account — cloud, DNS, error tracking, analytics, app store — is created under your organisation and that supplier access is granted rather than assumed. This is nearly free on day one and expensive to unwind on day four hundred.

Knowledge that was never written down

The deployment process lives in one engineer's head. The reason a particular queue exists is undocumented. Environment variables are set by hand. You own a repository that another team would need six weeks to become productive in, and six weeks of another team's time is a real switching cost. Documentation is not paperwork here; it is the thing that makes ownership operational.

Accumulated context

This one is legitimate and permanent. A team that has worked on your system for two years genuinely knows things a new team will take months to learn. No contract fixes it. It is the reason to choose carefully rather than to plan on switching, and the reason a good supplier does not need artificial lock-in.

A codebase nobody else wants to touch

No tests, no consistency, dependencies years out of date. Any firm you approach quotes high because their first month is archaeology. This is lock-in by decay, and it accrues silently. Periodic review by an outside engineer — even a few days a year — surfaces it while it is still cheap.

Do you need source code escrow?

Escrow — a third party holding a copy of the code, released to you if the supplier fails or breaches — is a standard answer to this problem and is usually the wrong tool for custom development.

It exists for licensed software, where the vendor genuinely will not give you their source. If you have commissioned bespoke software with a proper assignment, you should already have the code, in a repository you own, updated continuously. Escrow adds cost and a release-condition negotiation to obtain something you are entitled to hold anyway.

Where it earns its place: licensed platform software critical to your operations, or arrangements where a supplier retains genuine ownership of a core component. If someone proposes escrow as the answer to "can we have repository access", the answer you actually want is repository access.

A handover you could actually act on

Write this into the contract as the definition of completion, not as an optional final phase. A handover that has to be requested is a handover that arrives incomplete.

1. Full commit history in a repository under your organisation, not a zip file of the final state. History is how the next team understands why things are as they are.
2. A README that takes a competent engineer from a clean machine to a running local environment, and that someone has actually followed end to end.
3. The deployment process, written down and reproducible — ideally as code rather than as instructions.
4. All credentials and accounts transferred to your ownership, with supplier access removable by you.
5. Architecture notes covering the decisions that would be surprising: why this database, why this queue, what the awkward part is.
6. The dependency list with licences, so you know what you are shipping.
7. A recorded walkthrough. An hour of someone explaining the system is worth more than most documents and costs almost nothing to produce.

A useful test of any supplier: ask what their handover contains before you sign anything. A firm that answers immediately and specifically has done it before. A firm that treats the question as premature is telling you something.

We hand over on this basis as standard, and are happy to review an agreement you have been offered elsewhere if the ownership terms are unclear.