You paid for your software. Do you actually own it?

We get asked to look at a lot of systems somebody else built. The first thing we check is not the code. It is who owns it.

The answer is uncomfortable more often than you would think. The business is paying for the hosting, the software runs their operation, and yet the domain sits in a developer's personal account, the code lives in a repository nobody at the company can log in to, and the contract never mentioned copyright at all.

Nothing goes wrong with that arrangement until it does. Then it goes wrong all at once.

The test that takes twenty minutes#

Forget the contract for a moment. Ownership is not really a legal question first, it is a practical one. Work through this list and answer honestly.

1. The domain. Log in to the registrar. Are you the registrant, and is the billing card yours?
2. DNS. Whoever controls DNS controls where your email and your website go. Can you get in?
3. Hosting or cloud account. Is the AWS, Azure, DigitalOcean or shared hosting account in the company's name, with your billing details?
4. The code repository. GitHub, GitLab, Bitbucket. Are you the owner of the organisation, not a member of somebody else's?
5. The third-party accounts. Stripe, the mail sender, analytics, error tracking, the app store listings. Every one of them.

The test for each is the same, and it is deliberately blunt: could you remove your developer today and still get in tomorrow? Not "would they give me access if I asked". They almost certainly would. That is not the question. The question is what happens if the relationship ends badly, or if they are ill, or if they simply stop answering.

If the answer to any of those is no, you do not own that piece of your software. You have permission to use it, granted by somebody who can withdraw it.

Being a user is not the same as being the owner#

This is the distinction that catches people out. Most developers will happily add you to the accounts they control. You can log in, you can see everything, you feel like an owner.

Then you look at the account settings and find you cannot remove other users, cannot change the billing, and cannot transfer the account. You are a guest with a good view.

On every platform that matters there is exactly one role that counts, and it is usually called owner. On GitHub it is organisation owner. On a domain registrar it is the registrant. On Stripe it is the account owner. Everything else, however senior it sounds, is a permission somebody else granted and somebody else can take away.

The part almost every contract gets wrong#

Here is the one most businesses have never been told, and it is worth knowing before your next contract rather than after.

In the UK, if an employee writes software as part of their job, the employer owns the copyright automatically. That is in the Copyright, Designs and Patents Act 1988 and you do not need to do anything.

If a contractor or an agency writes it, the default is the opposite. The person who wrote it owns the copyright, and you have an implied licence to use it for the purpose it was commissioned for. Paying the invoice does not transfer ownership. Only a written assignment does.

Most small software contracts simply do not mention it. That is not usually anybody being clever. It is a template that never had the clause in it. But it means the honest answer to "do I own this software?" is often no, and neither party realised.

So what should you ask for? There are two legitimate answers, and it is worth knowing which one you are being offered.

Assignment. Copyright transfers to you on payment. You own it outright and can do anything with it, including selling it.

A written licence. Copyright stays with the developer, and you get a written, perpetual, irrevocable right to use that code for your project, modify it, and have anyone else modify it. You are not buying the right to resell it or to reuse it as the basis of a different product.

Neither of those is a trick. Which one you need depends on what you are buying. If the software IS your product, or you might sell the business on the strength of it, push for assignment. For most businesses buying a system to run their operation, a proper licence does everything they will ever need to do.

What is not acceptable is neither. A contract silent on copyright leaves you with an implied licence of uncertain scope, and the first time that matters is the day you want to move.

If you are offered a licence rather than assignment, read what it actually permits. It should be perpetual, should survive you changing supplier, and should explicitly let somebody who is not them work on the code. A licence that lapses if you stop paying a support fee is not a licence, it is a hostage arrangement.

We are developers, not solicitors, so take this as the thing to ask your solicitor about rather than as the advice itself. But do ask.

What about the open source in it?#

Nearly all modern software is built on open source components, and you will not own those. Nobody does, in the sense that matters here. What you have is a licence, and for the common ones such as MIT, Apache and BSD that licence is permissive, perpetual and free. It cannot be withdrawn from you.

That is fine, and it is not a gap in your ownership. What matters is that the licences are compatible with what you are doing, and that nothing in your system depends on a component with a licence that would force you to publish your own code. That is a rare problem, but it is worth a supplier being able to answer the question rather than looking blank.

Ownership you cannot use is not ownership#

There is a second half to this, and it is the one people miss even when the accounts are all in the right name.

Suppose you own everything on paper. The repository is yours, the hosting is yours, the copyright was assigned. Your developer disappears. Can another developer pick it up?

That depends on things that are easy to skip and expensive to add later:

• Is the code actually in the repository, or does the running system contain changes that were made directly on the server and never committed?
• Can it be run? Is there a readme that says how to get it working on a new machine, or is that knowledge in one person's head?
• How does it deploy? If deployment is somebody manually copying files over, that process leaves when they do.
• Where are the secrets? Not the values, which should never be in the code, but the list of what is needed.
• What did they decide and why? The odd decisions in any system are usually right for a reason nobody wrote down.

We take on a lot of systems in exactly this state. It is recoverable, and we do it most weeks. But the first job is reconstructing what should have been written down at the time, and you are paying for that twice: once when it was not done, and again when somebody has to work it out.

How to fix it if the answer was no#

Do not make it a confrontation. In our experience this is almost never bad faith, it is drift: an account got set up quickly at the start of a project and never got tidied up.

Ask for the accounts to be transferred, one at a time, starting with the domain and DNS. Those two are the ones that take your email and your website down, so they matter most. Then hosting, then the code, then the third-party services.

Take your own backup of the code and the database while you do it. Not because you expect a problem, but because a backup you hold yourself is the only one you can be certain of.

Then get the copyright assignment in writing, dated now. It does not have to be retrospective drama. It is a short letter.

If a supplier resists all of this, you have learned something important, and you have learned it while the relationship is still working rather than during an argument.

What we do#

We should be straight about where we sit on this, because we have just spent a page telling you to ask the question.

Every client of ours gets their own code repository and their own project from day one, in their name, along with the domain, the hosting and every account the system runs on. You have the code. There is no exit process to negotiate and nothing to request, because there is nothing to unwind.

On copyright, we take the second of the two routes above. We keep the copyright, and you get an indefinite licence to use that code for your project. In practice that means:

• You can use it forever, whether or not you are still working with us.
• You can change it, and you can have anyone you like change it. You do not need our permission and you do not need us involved.
• You keep a copy of the code, so nothing depends on us still being here.
• What you cannot do is take that code and use it as the basis of other projects, or sell it on, without our agreement.

The reason is straightforward. Almost nothing we write for anybody is written from nothing. It sits on thirty years of accumulated work, and assigning the copyright away on every job would mean signing away the tools we need for the next one. That is what would make us slower and more expensive, and it would be you paying for it.

The distinction matters less than it sounds for what this article is actually about. Everything that goes wrong when you do not own your software is a question of being able to move: can you get the code, can you keep running, can you hire somebody else. Our licence answers yes to all three, permanently. If the software itself is your product and you intend to sell it, tell us and we will talk about assignment properly, at a price that reflects it.

What we will not do is leave it vague. It is written down, it is the same for everybody, and you can read it before you spend anything.

If you are not sure where you stand with a system you already have, that twenty minute check at the top is the place to start. If you would rather someone went through it with you, that is a conversation we are happy to have with no obligation attached.