Who Owns the Code? IP and Licensing in Custom Software

By Grocito15 October 2026

Paying for custom software does not automatically mean you own the code. Ownership depends on what your contract says: the developer may assign the intellectual property to you, or may only grant you a licence to use it. Components that were not written for you, such as vendor tools and open-source libraries, usually stay under their own licences. This is general information, not legal advice, so have a qualified lawyer review your contract.

Key takeaways

Paying for a project and owning its intellectual property are two separate questions, and only the written contract answers the second one.
An assignment (or work-for-hire arrangement, where your law recognises one) transfers ownership. A licence only lets you use the software on agreed terms.
Even when you own the custom code, the developer's pre-existing tools and any open-source components normally keep their own licences.
Domains, hosting accounts, repositories, design files and credentials should be created in your name from day one.
Agree the handover at the start: what you receive, in what form, and when.
Laws and contract wording vary by country, so treat this as a checklist to discuss with a lawyer, not as a substitute for one.

Does paying for software mean you own it?

Not by default. Many business owners assume that if they paid for the build, they own everything produced. In practice, the default rules differ between countries, and many agreements are written so that the developer keeps ownership of the code and gives the client a licence. Some contracts transfer ownership only after the final payment. Others transfer the custom parts and keep the reusable parts.

Neither approach is wrong in itself. A licence-based deal can be cheaper, and a developer who reuses their own framework across projects often needs to keep it. The mistake is not knowing which deal you signed.

What does intellectual property mean in a software project?

Intellectual property (IP) is the legal right over something created: here, mostly the source code, but also designs, text, images, database structures, documentation and sometimes the ideas behind a unique process. The person or company holding those rights decides who may copy, change, sell or reuse the work.

In plain terms, in a software project there are usually several layers:

The custom code written specifically for you.
The developer's pre-existing tools, such as internal libraries, templates or starter kits they bring to every project.
Third-party and open-source components written by other people and used under their licences.
Content and design assets, such as logos, photographs, fonts and interface designs, which may be yours, the designer's or licensed from a stock source.
Your data, which should remain yours in every scenario.

Assignment, work for hire and licence: what is the difference?

Assignment

An assignment is a written transfer of ownership from the developer to you. After it, you hold the rights and can change the code, hire another team or sell the product. Many jurisdictions require the transfer to be in writing and signed, so a verbal understanding is risky.

Work for hire

In some countries, work created under certain kinds of engagement can belong to the commissioning party from the start. Whether that applies to an outside software developer varies widely and often does not apply the way people expect, so do not rely on the idea without advice. Many lawyers prefer an explicit assignment clause either way.

Licence

A licence is permission to use the software under conditions. Check whether it is exclusive or non-exclusive, perpetual or time-limited, transferable or not, and whether it allows you to modify the code, host it elsewhere or let another developer maintain it. A broad, perpetual, exclusive licence can sometimes serve you nearly as well as ownership, but only if those words are actually in the contract.

What about vendor tools and open-source components?

Almost no modern application is written entirely from scratch. It stands on frameworks, libraries and services that other people own. That is normal and good engineering, but it affects what you can claim.

Pre-existing developer tools: ask for a clear licence to keep using them with your software, and find out what happens if you leave the developer.
Open-source components: these come with licences that set conditions. Some are permissive, and some require you to share certain changes. Ask for a list of the components used and their licences. Our guide to open source versus proprietary software explains the difference at a plain level.
Paid third-party services: payment gateways, maps, email and analytics tools are usually rented. You hold an account, not ownership.

A good vendor will provide a bill of materials, meaning a simple list of the components and their licences. If they cannot, that is a warning sign.

Which accounts, files and credentials should be in your name?

Code is only one asset. Many disputes are really about access. Keep the following in your own name or your company's name:

Domain names, registered to you as owner, with you holding the registrar login.
Hosting and cloud accounts, with the developer added as a user rather than the other way round.
Source-code repositories, created in an organisation you control, with the developer invited as a collaborator.
App store developer accounts, since your app listing is tied to the account that published it.
Design files, including editable source files, not just exported images.
Credentials and keys, stored in a shared password manager, with a record of who has access.
Third-party service accounts, such as payment, email, analytics and maps.

Our guide to choosing a web development agency suggests asking about this before you sign. It is far easier to set it up correctly on day one than to recover control later.

How should source-code handover and escrow work?

Handover should be a planned event, not a favour. Agree in the contract what you receive at the end of the project: the full source code, build instructions, configuration, database structure, documentation and access to every account. Ideally you also receive updates at each milestone, so you are never one dispute away from losing everything.

If you rely on software the developer continues to own, a source-code escrow arrangement may be worth discussing. In escrow, a neutral third party holds a copy of the code and releases it to you only under agreed conditions, such as the developer going out of business. It adds cost and process, so it suits critical systems more than small ones.

Ongoing care matters too. See our guide to software maintenance and support after launch for what to agree so that someone can keep the system running.

What should go into the contract?

Use this as a list of topics to discuss with your lawyer, not as finished wording:

Deliverables: what exactly will be built, in what form, by when.
Ownership: who owns the custom code, designs and documentation, and when the transfer takes effect.
Licences: terms for any pre-existing or third-party material, including whether you can modify it.
Confidentiality: an NDA covering your business information, data and ideas, in both directions.
Warranty: what the developer promises about the quality of the work, and for how long they fix defects.
Handover: the list of assets and access to be delivered, and the format.
Payment link: whether ownership passes on payment or on delivery.
Termination: what happens to code, access and payments if either side ends the agreement early.
Support and changes: how later updates are owned and priced.

Which red flags should you watch for?

The contract is silent on ownership.
The developer holds the only copy of the code and refuses milestone access.
Domains, hosting or app store accounts are in the developer's name.
No list of third-party components is available.
Unusual restrictions, such as not allowing another team to ever touch the code.
Resistance to any written handover plan.

A worked example

Imagine a small training company that hires a freelancer to build a booking portal. The contract says only that the freelancer will deliver "a working portal". The freelancer registers the domain and hosting in their own name and builds on a private toolkit. A year later they stop responding, and the company cannot log in, move the domain or update the code. A better start would have been a short contract stating ownership and licences, accounts in the company's name, a component list and a handover checklist, all reviewed by a lawyer. Our app development services team is happy to talk about how we structure handover.

FAQ

Who owns the code if I pay a developer to build my software?

It depends on the written contract and the law in your country. Some agreements assign ownership to you, others keep ownership with the developer and give you a licence. Ask for the ownership clause in plain words and have a lawyer confirm it.

What is the difference between owning code and having a licence?

Ownership means you hold the rights and can change, sell or move the code. A licence lets you use it under conditions that may limit modification, hosting or transfer. Check whether a licence is exclusive, perpetual and transferable.

Do I own the open-source parts of my custom software?

Usually not. Open-source components stay under their own licences, and you are allowed to use them on those terms. Ask your developer for a list of the components and licences used, and have a lawyer check any obligations.

Do I need a lawyer to review a software development contract?

It is strongly recommended. Ownership, licences and liability wording are easy to get wrong, and the rules vary by country. A short review before signing costs far less than a dispute later.

Next steps

Look at your current or planned software project and check three things: who holds the domain, hosting and repository accounts, what your contract says about ownership, and whether a component list exists. Take those answers to a qualified lawyer before you sign or pay the final milestone. If you would like to talk through a project and how handover should work, contact us.