Who owns the source code? A software ownership guide

Picture this: your software is live and works. A year later you want to change supplier, build on it with your own team, or integrate it with a new platform. Then you find out that you do not own the source code, that the data is stuck with the old vendor, or that the domain is registered in the vendor’s name. That is vendor lock-in. It is expensive, and a few requirements at the start prevent it.

This guide covers the digital assets you should own as a software buyer, and what to ask your development partner for before you sign.

Who owns the source code?

The developer does, unless the contract says otherwise. Under the Danish Copyright Act, copyright initially belongs to the person who creates the work, and § 59 gives an employer the copyright to computer programs its employees write as part of their job (ophavsretsloven). When you buy software from an agency, the agency holds the rights to its employees’ code. Paying the invoice does not transfer those rights to you.

The transfer has to be agreed, and it should be explicit. § 53(3) of the Act means that a transfer of the right to use a work in one way does not cover other ways. A contract that only lets you “use” the software may not let you change it, have another supplier change it, or sell it on.

So ask for:

• a written assignment of the rights to the custom code and documentation, not only a licence to use them
• an explicit right to modify, further develop, distribute and sub-license
• a list of the vendor’s pre-existing components, frameworks or libraries, and the licence you receive to use them
• a list of open source components and their licences, so you know your obligations

The law differs between countries. If your supplier or your company is outside Denmark, check which law governs the contract. This guide is practical advice, not legal advice; have a lawyer read the actual contract.

What about code written with AI?

Copyright protection for AI-assisted code depends on the human creative input. Copyright protects original expression that reflects a person’s own creative choices. The Confederation of Danish Industry points out that code produced by AI with little human input may not meet that threshold, while code for which a developer makes the key design choices and edits the result may do so (DI).

In practice: ask your supplier how they use AI, and make sure the contract and the delivered documentation (architecture notes, version history, reviews) show the human work behind the product.

Why is clear ownership critical?

Clear ownership lets you change supplier, hire in-house, raise capital or sell the company without the technology holding you back. It is not just a legal formality that matters when you exit.

When ownership is unclear, four problems tend to show up:

• Switching gets expensive. A new supplier has to recreate what you have already paid for.
• Data gets hard to move. The export comes in a format nobody else can read.
• Operations depend on one person. Nobody else has access to the accounts, the code or the infrastructure.
• Due diligence fails. An investor or buyer discovers that the company does not own its own software.

In regulated fields such as medtech and the life sciences, you also need access to the code, the data and the documentation to respond to audits and keep the product’s technical file up to date, both on the way to CE marking and after launch.

The assets you should own

Secure ownership of seven assets: source code, data, domain and DNS, hosting, third-party services, documentation and a written exit plan, with the access, documentation and rights you need for each. This does not mean doing everything yourself.

1. Source code and version control

Keep the code in a Git repository under your own organisation on GitHub, GitLab, Azure DevOps or similar, not under the vendor’s account. A user account in someone else’s organisation is not ownership.

• All repositories, including infrastructure as code and deployment scripts.
• At least two administrators on your side.
• A codebase that builds without access to the vendor’s private environment.
• The secrets and configuration needed to run it, stored where you control them.

2. Database and data

Data is often the most valuable asset and the hardest to move. You should be able to export it in an open format without asking permission.

• A documented data model and export process.
• Database access through an account you own.
• Backup and restore procedures that have been tested, not just configured.

If the vendor processes personal data for you, GDPR requires a data processing agreement that makes the vendor delete or return all personal data at the end of the service, as you choose (GDPR Article 28(3)(g)). Use that clause.

3. Domain and DNS

Register the domain in your company’s name, with your own contact details, and retain the login credentials for the registrar account. The domain is your address on the internet. The same applies to the DNS zone, because DNS controls email, subdomains and verification records. The vendor can get access to set up records; you retain ownership.

4. Hosting and cloud

The cloud account is often where lock-in is most expensive. If the vendor owns the account, the vendor effectively owns your operations.

• The cloud account is yours, with your billing and your security policies.
• The vendor gets role-based access, not ownership.
• The infrastructure is described as code, so it can be recreated.

Since September 2025 the EU Data Act has also given business customers rights when switching between cloud and other data processing services, and switching charges are being phased out by 12 January 2027 (Data Act). Amendments are under negotiation, so check the current text. These rights help, but they do not replace owning the account.

5. Third-party services and API keys

Modern products run on many services: payment, email, SMS, AI, maps, analytics and support. Each one has an account and a key. If the key sits in the vendor’s account, it is not yours. Keep a list of each service, its purpose, who owns the account, where the keys live and what happens to the subscription when the collaboration ends.

6. Documentation

Documentation enables another team to take over the system. Ask for the architecture and data model, including the architecture decisions and their reasons, a runbook for operations, deployment and rollback, the test strategy and known limitations, and a handover that includes a walkthrough, not just a zip file.

7. A written exit plan

Describe in the contract how code, data, accounts and documentation are handed over when the collaboration ends, whatever the reason, and what the vendor helps with during the transition. Source code escrow is mainly relevant when the vendor keeps the code, for example with licensed or SaaS software. If the code is already in your repository, the exit plan matters more than escrow.

Software ownership checklist

Go through this list before you sign, and again once a year:

• The contract assigns the rights to the custom code and documentation to you.
• Third-party and open source components are listed with their licences.
• Every asset has a named owner in your company.
• All accounts (Git, cloud, domain, DNS, third-party services) are in your company’s name.
• Data can be exported in an open format.
• A data processing agreement covers deletion or return of personal data.
• There is a documented exit plan.
• Someone outside the vendor has built and run the system from your repository.

How bon.do handles ownership

At bon.do, all code, data and IP are yours from day one. We work in repositories and cloud accounts in your name where possible, build on open, well-documented tools, and include documentation and a handover in the work, whether it is a fixed-scope MVP or an ongoing team. Ownership is part of how we build and run software for our clients.

Unsure who owns what in your current product? Contact us for a no-obligation review of your code, accounts and contract.