Software Source Code Ownership: Settle It Before You Sign

The most expensive sentence in a software contract is the one nobody wrote. Software source code ownership is settled in a paragraph if it is dealt with before development begins, and settled by bargaining position — usually not yours — if it is raised for the first time on the day you want to move. This piece lists the questions worth putting in writing, explains what each one protects you from, and describes what a genuine handover contains, because “we will give you the code” turns out to mean several different things depending on who is saying it.

Why software source code ownership gets skipped

It is not usually malice. Ownership is an uncomfortable subject at the start of a relationship that both sides want to feel collaborative, and it competes for attention with scope, price and timeline — all of which feel more urgent. So it gets deferred, and deferral favours whichever party holds the code, which is never the client.

There is also a genuine confusion underneath. Buyers assume that paying for software means owning it, in the way that paying for furniture means owning it. Software does not work that way. What you have bought is defined by your contract, and in the absence of a term, a client can find they hold a right to use a system rather than a right to take it elsewhere. The gap between those two positions only becomes visible at the moment it becomes expensive.

The five questions to settle in writing

1. Who owns the code?

Name it explicitly. There are three respectable answers — the client owns it outright, the developer owns it and licences it to the client, or ownership is split between a shared platform and client-specific work — and any of them can be the right arrangement. What is not respectable is silence. If ownership transfers on final payment, say that. If it transfers on delivery, say that instead, and be clear about what “delivery” means.

2. Who owns the data?

This should be uncontroversial and it usually is, but the clause that matters is not the ownership one. It is the extraction one: can you export your complete data, in a documented and usable format, at any time, without asking and without a fee? Data you own but cannot retrieve is data you do not have. Ask for an export while the relationship is good, and check that what comes out is genuinely loadable rather than a set of screen-shaped reports.

3. What happens if you change developers?

Write down the exit before you need it. A workable clause covers what will be handed over, in what form, within how many days of a written request, and what assistance is included — typically a short transition period in which the outgoing team answers the incoming team’s questions. The absence of this clause is what turns a routine change of supplier into a hostage situation, and it is the single most common reason businesses stay with a developer they have stopped trusting.

4. Exclusivity and reuse

Be precise here, because absolutism helps nobody. No developer builds authentication, reporting engines or common components from scratch each time, and you do not want to pay for them to. What you should insist on is a line: your business logic, your data model, your workflows, your screens and anything derived from your commercial knowledge are yours and are not resold. Generic infrastructure may be reused. Write down which is which, and if you are commissioning something you intend to sell onward, say so at the start — that is a different arrangement and it should be priced as one.

5. Third-party components and licences

Ask for a list of the open-source and commercial components the system depends on, and their licence terms. Most of the time this is entirely routine. Occasionally it is not: a component with restrictive terms, or a paid licence held in the developer’s name rather than yours, can become a problem exactly when you are trying to move. It is a five-minute question that occasionally saves a very bad month.

The middle arrangements worth knowing about

Ownership is not a binary, and two intermediate arrangements cover many real situations honestly.

Source code escrow. The code is deposited with a neutral third party and released to you on defined triggers — the developer ceasing to trade, failing to support the system for a stated period, or breaching the agreement. Escrow is the usual answer when a developer licenses one product to many clients and cannot hand each of them the source. If that is what you are buying, ask three things: does a deposit actually exist, who verifies that what is deposited genuinely builds, and what precisely triggers release. An escrow nobody has ever test-built is a ceremony rather than a protection.

Licence now, handover on exit. The developer retains ownership during the engagement, and the contract commits them to a full handover — source, schema, deployment configuration — at a defined price if either side ends the relationship. This keeps a productised arrangement commercially workable for the developer while removing the hostage scenario for you. The clause to scrutinise is the price of the exit: if it is not fixed in advance, it will be discovered at the worst possible moment.

Neither arrangement is as clean as owning the build outright, but both are honest, and either is far better than the silence most contracts contain.

What a real handover contains

“We will hand over the code” is where the ambiguity concentrates. A handover that leaves you genuinely independent has four parts.

• The source code, complete, with its version history — the history is what lets a new developer understand why something is the way it is.
• The database schema, together with the migration scripts that build it, so the structure can be recreated rather than reverse-engineered from a live copy.
• The deployment configuration — how the system is built, where it runs, what environment variables and services it depends on, and how a new environment is created from nothing.
• Documentation written for a developer who has never seen the system, sufficient to build, run and deploy it without a conversation.

Test the handover rather than filing it. The only meaningful check is whether a developer who was not involved can take what you were given and get the system running in a fresh environment. Everything short of that is paperwork. A practical way to run the test without hiring anyone is to ask the developer to record the deployment — a screen capture of the system being built and brought up in a clean environment, following only the written documentation. Every place the recording departs from the document is a place the document is not yet a handover.

The other half: can your staff run it?

Ownership of code protects you from a developer. It does nothing to protect you from your own turnover. A system whose operation lives in one trained employee’s head is just as fragile as one whose code lives with a vendor who no longer answers — the dependency has simply moved indoors. Written per-role manuals and training on your own data are the equivalent handover for the people side, and we make that argument fully in why systems die when people leave.

Where Linksoft stands

We hand over source code and the database schema where a client wants to own the build outright, including white-label arrangements where a client sells the product onward under their own name. That is a normal engagement here, not an exception negotiated under duress — and it is the basis of our software product development work, where the client’s intention from the start is to own and commercialise the result. Where a product is licensed rather than sold outright, the exit terms go into the agreement at the beginning, because we would rather compete on the next delivery than on the cost of leaving.

The same principle governs the other direction. When we work on a system somebody else built, the client’s source code is handled under NDA and deleted from our machines once the requested work is delivered, which is the arrangement we describe in working with the system you already have. We would rather be chosen each time than retained by the fact that leaving is difficult, and our approach to delivery is built on that footing.

If you are about to sign a development contract — with us or with anyone — read it for the exit rather than the entrance. If the exit is not described, ask for it in writing before the first payment, and send it to us if you would like a second opinion on what it actually says.