Who owns the code you paid for.

The default surprises people

Most business owners assume that if they paid for a piece of software to be written, they own it. Under UK copyright law that is not the starting point.

Source code is protected by copyright in the same way as written text. By default, copyright belongs to the person who wrote the work — or to their employer, if they wrote it as part of their job. When you commission an outside developer or agency, you are neither of those. The code they write for you belongs, by default, to them.

That holds even though you paid for it, and even though it was written entirely for your business. Without anything in writing, paying for the work will usually get you an implied right to use it for the purpose it was made for. A court might be prepared to infer something more from the circumstances, but relying on that means arguing about it after the relationship has already gone wrong, which is the worst possible time.

None of this is usually a problem while things are going well. It becomes a problem when you want to change supplier, sell the business, raise investment, or bring development in-house, and discover that the thing at the centre of your operation belongs to somebody else.

What fixes it

The fix is an assignment of intellectual property in the contract: a clause in which the supplier transfers ownership of the code they write for you to your company. In the UK an assignment of copyright needs to be in writing and signed by the party giving it up, so a friendly email saying "of course it's yours" is not a substitute.

A reasonable clause usually covers:

• What is assigned — the code, designs, documentation and other material created for you under the contract
• When it passes — commonly on payment. That is fair; it is normal for a supplier not to hand over ownership of work that has not been paid for.
• What the supplier keeps — their own pre-existing tools and libraries, which they will reuse elsewhere. You should get a permanent licence to use whatever of that ends up in your system.
• Third-party and open-source components — nobody can assign you ownership of code they did not write. Most software includes open-source libraries under their own licences, which is normal and fine; the contract should just be honest that it is there.

This guide describes the general position, not your particular contract. For anything significant — a large build, software the business depends on, or a sale or investment where ownership will be checked — have a solicitor review the agreement before you sign it.

Ownership on paper is not enough

A contract that says you own the code is necessary. It is not sufficient. If the only copy of that code is in the supplier's account, on the supplier's hosting, deployed with credentials only the supplier holds, then owning it on paper does not help much on the day you need it.

The practical side is where most real disputes happen, and it is avoidable:

• The code lives in your repository. A repository on GitHub or a similar service, under an organisation your business controls, with the supplier invited in as a collaborator. Not their account, with a promise to transfer it later.
• Hosting is in your name. The servers, the database and the backups sit in an account that you own and pay for. If the supplier resells hosting to you, ask what happens to it when you stop paying their invoices.
• Domains are registered to you. A domain registered in a developer's name is one of the most common, and most painful, things to recover.
• Third-party accounts are yours. Email sending, payments, maps, app store listings, analytics — each one set up under your business, with the supplier given access rather than holding it.
• Credentials are documented. You should know where the passwords and keys are kept, and be able to revoke the supplier's access without their help.

If you are taking over a system where none of this was done, the first job is usually getting it all back into the right name before touching anything else. Software rescue starts there.

Questions to ask any supplier

Before you sign, it is worth asking these plainly and getting the answers in writing:

1. Does the contract assign the IP in the work to us, and when?
2. Which parts, if any, will you keep, and what licence do we get to them?
3. Whose account will the code be in from the first day?
4. Whose name will the hosting, domains and service accounts be in?
5. If we stop working together, what do we need from you, and what do we already have?

The last one is the real test. A good answer is short: nothing much, because everything is already in your name. A long answer involving handover fees, export processes or "we'll sort that out at the time" tells you what leaving would actually be like.

How we handle it

Unless we agree otherwise up front, the code, the hosting, the domains and every third-party account are set up in the client's name as the work goes, rather than handed over at the end as a favour. Deployment is automated and the decisions are written down, so another engineer could pick the system up after us without an introduction. Bespoke software sets out the rest of how we work.

We would rather you stayed because the work is good than because leaving is difficult. It is worth expecting the same of anyone you hire, and a supplier who resists it is telling you something useful before any money has changed hands. If you are about to brief someone, writing a software brief is a good place to put these requirements down from the start.