Who owns the code you're paying for?
Without a clear contract, the vendor usually keeps the copyright to code you've paid for – you're left with only a right of use. If you want to be able to switch vendors, keep developing, or sell the company, the contract needs to explicitly transfer ownership to you, plus access to the repo and accounts from day one.
Many buyers discover too late that they don’t own the system they paid hundreds of thousands of kronor for. They have a working product, but not the right to change it, move it, or bring in someone else. It’s rarely malice – it happens because nobody wrote down who owns what. Here’s what you need to know before the next invoice goes out.
Ownership, exclusive license, and right of use
Three concepts decide how free you are, and they’re often mixed up.
- Ownership (copyright). You can use, modify, sell, and relicense the code however you like. It’s the strongest position, and the only one that makes you fully independent of the vendor.
- Exclusive license. The vendor keeps the copyright but grants only you the right to use the code. Better than a plain license, but you may still be limited in what you can change and who’s allowed to do it.
- Right of use. You can use the system for a defined purpose. Often neither the source code nor the right to let a third party keep developing it is included. This is what you get by default if the contract is silent.
The point is simple: payment doesn’t decide what you own – the contract does. Under Swedish copyright law, the right arises with whoever creates the work, and it stays there until something else is agreed in writing.
The contract wording to require
A good contract doesn’t need to be complicated, but it does need to be explicit. Make sure the following is included:
- Transfer of copyright. All copyright to custom-developed code transfers to you upon full payment. Without the link to payment, the right can end up in limbo if a project is cancelled.
- Right to source code and documentation. You should have the readable source code, not just a runnable system, plus the documentation another developer needs to take over.
- Handling of third-party code and open source. Almost every system is partly built on ready-made components. The contract should list these and their licenses, so you know what you can and can’t do with them.
- No lock-in via dependencies. Require that the vendor’s own frameworks or tools the system rests on can also be used and handed over, or you own a car without a key.
A quick review of this with a lawyer before the project starts costs a fraction of what a dispute or a forced reinstallation costs later.
Practical ownership: repo, accounts, and keys from day one
Legal ownership is worthless if you don’t actually have access to anything in practice. The most common mistake is letting the vendor own the infrastructure “for simplicity.”
| Asset | Who should be listed as owner |
|---|---|
| Code repo (e.g. GitHub, GitLab) | Your company's account – the vendor is invited in |
| Cloud account and servers | Your company pays for and owns the account |
| Domain and DNS | Your company |
| App store and service accounts | Your company |
| Deploy and API keys | Held by you, shared as needed |
The rule is that anything that would be painful to lose should be in your name from the start. The vendor gets access to work, of course, but as an invited guest – not as owner. That way, switching vendors becomes an administrative task instead of a negotiation where you’re at a disadvantage.
A concrete scenario
A company had an agency build its customer portal and paid just over a million kronor over two years. Everything lived in the agency’s repo and the agency’s cloud account, and the contract said nothing about ownership. When the relationship soured, the company wanted to move the system – but was told they only had a right of use, and that an export would cost extra. With an ownership clause and their own repo from the start, the move would have been an afternoon’s work instead of a month with lawyers.
Want to avoid ending up in the same spot? It pays to settle ownership before the build begins. In our services we always work in the client’s repo and hand over code and accounts on an ongoing basis, and a technical due diligence of an ongoing project quickly gives you a clear picture of where you actually stand today.
Frequently asked questions
Do I automatically own the code if I pay for it?
No. Under Swedish copyright law, the right arises with whoever writes the code – the vendor or consultant. Paying for the work doesn't automatically hand you ownership – only what the contract explicitly transfers. Without a clause on this, you normally get a right of use, not ownership.
What's the difference between ownership and a right of use?
Ownership means you can freely use, modify, sell, and license the code. A right of use means you can use it for a defined purpose, often without the right to touch the source code or bring in anyone else. The difference decides whether you're free or locked in.
Do I need the source code if the system works anyway?
Yes, if you want to keep developing, troubleshoot, or switch vendors. Without the source code and the right to change it, you're stuck with a single party. Require that the code sits in a repo you own, not just in a hosting environment you can't reach.
What happens to the code if the vendor goes bankrupt?
If you already have ownership and access to the repo, the impact is minimal – you can move the work to someone else. If you only have a right of use and the code sits with the vendor, you risk losing everything. That's why access should be secured on an ongoing basis, not at some imagined end point.
What should I put in the contract?
A clause transferring all copyright to delivered code to you on payment, the right to source code and documentation, plus access to the repo, accounts, and deploy keys. Also address open source and any reused components, so no unexpected license terms come along with them.