Source code ownership is the clause that decides whether the software you paid for is an asset on your balance sheet or a rental agreement you did not know you signed. It sits three pages into a statement of work, it is rarely read aloud in a kick-off meeting, and it is almost never renegotiated once the project is running. Then a supplier relationship ends, a funding round starts, or an acquirer sends a due-diligence questionnaire, and the question arrives at the worst possible moment: who actually owns this?
The honest answer for a great many British companies is not you. Paying an invoice does not transfer copyright. In the UK, and in most of the countries British firms outsource development to, the person who writes the code owns the code until a written agreement moves it. A supplier who has been perfectly reasonable for two years can still be sitting on the intellectual property in your core product, entirely lawfully, because nobody wrote the right sentence into the contract at the start.
This guide walks through source code ownership the way it actually fails in real projects rather than the way it is described in a legal textbook. It covers the default legal position and how it differs by jurisdiction, the three source code ownership models suppliers put in front of you, and the background IP and open-source carve-outs that quietly hollow out an assignment clause.
It then turns practical: the specific wording that makes a transfer of source code ownership stick, where software escrow genuinely helps and where it is theatre, and how to prove at handover that you can rebuild the product without the people who built it. If you are still choosing a supplier, read it alongside our software development contract checklist, which covers the surrounding clauses.
Table of contents
- Source Code Ownership Is Never Automatic — Start With the Law
- The Three Models of Source Code Ownership in Outsourcing Contracts
- What Source Code Ownership Actually Includes Beyond the Repository
- Where Source Code Ownership Quietly Fails: Background IP and Open Source
- Contract Clauses That Make Source Code Ownership Real
- Source Code Escrow: Useful Fallback or Expensive Theatre?
- The Handover: Proving Source Code Ownership Actually Transferred
- What Source Code Ownership Costs — and What Disputes Cost
- Recovering Source Code Ownership After You Have Already Signed
- Source Code Ownership FAQ
- References
Source Code Ownership Is Never Automatic — Start With the Law
The single most expensive assumption in outsourced development is that commissioning work means owning its output. It does not. Source code is protected as a literary work under copyright law, copyright has a default owner — the author — and source code ownership moves away from that default only when a document says so.
The default rule puts the code with whoever wrote it
Under section 11 of the Copyright, Designs and Patents Act 1988, the author of a work is its first owner. For software, the author is the developer who wrote it. If that developer works for an agency, the agency owns it. If they are a freelancer, they own it personally. Your invoice, your requirements document and your brand on the login screen change nothing about source code ownership.
Employees and contractors are treated completely differently
There is one significant carve-out: work created by an employee in the course of employment belongs to the employer automatically. That is why in-house teams rarely raise source code ownership questions. The moment work moves outside the payroll — to a contractor, an agency, a studio or an offshore partner — the automatic rule stops applying and source code ownership reverts to the person holding the keyboard until an express written assignment moves it back.
“We paid for it” is not a legal argument
Courts will sometimes imply a licence where a client clearly commissioned and paid for bespoke software, on the basis that the contract would otherwise make no commercial sense. That sounds reassuring until you look at what an implied licence gives you: typically a non-exclusive right to use the software for the purpose it was commissioned for. It does not reliably give you the right to modify it, to have a different supplier maintain it, to sub-licence it to your own customers, or to sell it with the business. Implied rights are a consolation prize, not source code ownership.
The jurisdiction you outsourced to changes the default
Outsourcing across borders adds a second layer. Moral rights, which cover attribution and objection to derogatory treatment, cannot be assigned in several European jurisdictions and must be waived instead — and in some cannot be waived at all. Work-for-hire doctrines that US clients rely on do not translate cleanly into English law.
| Jurisdiction | Default owner of commissioned code | What you must do | Moral rights |
|---|---|---|---|
| England and Wales | The supplier (author) | Express written assignment, signed | Waivable in writing |
| United States | Supplier unless a valid work-for-hire applies | Assignment plus work-for-hire wording | Narrow, largely waivable |
| Germany | The individual author, always | Exclusive licence of exploitation rights | Cannot be assigned |
| Poland | The author | Assignment listing fields of exploitation | Non-transferable |
| India | Supplier, subject to contract | Assignment plus employee flow-down proof | Limited, waivable |
| Ukraine | Shared by default in some structures | Explicit exclusive transfer wording | Personal rights retained |
The practical takeaway is simple. Wherever your development partner sits, source code ownership has to be created by contract, and the contract has to be written for that jurisdiction rather than copied from a template drafted somewhere else.
The Three Models of Source Code Ownership in Outsourcing Contracts
Suppliers do not usually refuse to discuss ownership. They offer one of three source code ownership models, and the differences between them are worth a great deal of money.
Full assignment gives you the code outright
The client takes all intellectual property in the deliverables. You can modify it, move it to another supplier, resell it, or sell the company with the software attached. This is what most clients believe they are buying, and it is the only model that gives you unambiguous source code ownership. It usually costs more, because the supplier gives up any ability to reuse the work.
A perpetual licence looks similar and is not
The supplier keeps source code ownership and grants you rights to use the software. The quality of that deal lives entirely in the adjectives: is the licence perpetual, irrevocable, worldwide, exclusive, sub-licensable, and does it include the right to modify and to have third parties modify on your behalf? A licence missing the right to modify means you cannot legally hire another developer to change your own product.
Joint ownership sounds fair and creates deadlock
Joint ownership is the source code ownership model that reads well in a negotiation and behaves badly afterwards. In several jurisdictions each co-owner needs the other’s consent to license or exploit the work, which means your former supplier holds a veto over what you do with your own product. Avoid it unless there is a specific commercial reason and the contract spells out exactly what each party may do alone.
| Capability | Full assignment | Perpetual licence | Joint ownership |
|---|---|---|---|
| Modify the code yourself | Yes | Only if expressly granted | Usually yes |
| Move to another supplier | Yes | Only if sub-licensing allowed | Often needs consent |
| Resell or sub-licence to customers | Yes | Rarely | Needs consent |
| Survives supplier insolvency | Yes | Contested | Complicated |
| Clean answer in due diligence | Yes | Flagged as a risk | Flagged as a risk |
| Typical price impact | Highest | Moderate | Lowest headline price |
If a supplier resists full assignment, the productive question is which specific components they want to keep reusable, not whether you can have source code ownership at all. That conversation usually ends with an assignment of the bespoke work and a broad licence over the supplier’s generic libraries, which is a perfectly reasonable outcome.
What Source Code Ownership Actually Includes Beyond the Repository
An assignment clause that says “the source code” is narrower than most clients imagine. Software is not just the application files, and a handover that delivers only those files leaves you with something you cannot run. Useful source code ownership covers everything needed to build, deploy and maintain the product.
Repository history is part of the asset
A zip of the current files is not equivalent to the repository. Commit history tells a maintainer why a decision was made, which lines are load-bearing, and who to ask. Branches, tags and release history let you reproduce a build from six months ago when a customer reports a regression. Specify that source code ownership extends to the repository itself, not to an export of it.
Build pipelines and infrastructure code are where projects die
Modern applications are inseparable from the machinery that builds and deploys them. Continuous integration configuration, container definitions, Terraform or CloudFormation templates, deployment scripts and environment configuration all need to be inside the scope of the assignment. Teams that treat DevOps tooling as the supplier’s internal business discover at handover that they own an application nobody can deploy.
Designs, documentation and tests carry their own copyright
Figma files, architectural decision records, database schemas, API specifications and automated test suites are separate copyright works. Each needs to be listed as a deliverable and covered by the same assignment. Test suites matter more than clients expect: without them a new maintainer cannot change anything with confidence.
Credentials and accounts are not IP, but you still need them
Domain registrations, cloud accounts, app store listings, code-signing certificates, DNS control and third-party API keys are frequently registered in the supplier’s name. None of this is intellectual property, so an ownership clause does not touch it. Add a separate schedule requiring transfer of every account and credential on termination.
Where Source Code Ownership Quietly Fails: Background IP and Open Source
Most source code ownership disputes are not about a missing assignment clause. They are about what the assignment clause excludes.
Background IP is a legitimate carve-out that gets abused
Suppliers reasonably want to keep the frameworks, utilities and boilerplate they bring to every project. That is background IP, and excluding it from an assignment is normal. The abuse is a definition broad enough to cover the interesting parts of your product — “any methodology, know-how or component developed by the Supplier” can swallow half the codebase. Insist that background IP is listed in a schedule by name before work starts, not defined abstractly and identified later.
The licence-back you receive must be broad enough to be useful
Wherever background IP is excluded, you need a perpetual, irrevocable, worldwide, royalty-free, sub-licensable licence to use, modify and have modified those components as part of the deliverables. If that licence is limited to internal use or terminates with the contract, your source code ownership over the bespoke layer is worthless — the product will not run without the parts you do not own.
Open-source components carry obligations that outlive the contract
Every commercial codebase includes open-source dependencies, and each arrives with a licence. Permissive licences like MIT and Apache 2.0 impose attribution obligations. Copyleft licences like the GPL can require you to release your own source code if you distribute a derivative work. A supplier’s assignment cannot override an upstream licence, so source code ownership brings those obligations to you along with the code.
Ask for a software bill of materials, not a promise
The reliable control is a machine-generated inventory of every dependency and its licence, delivered at each release rather than described in a warranty. A software bill of materials in a standard format makes licence review a filter rather than an archaeology project, and it is the only way to know what you inherited. The Open Source Initiative licence list is the reference point for classifying what turns up.
Contract Clauses That Make Source Code Ownership Real
The difference between a source code ownership clause that works and one that does not is usually a handful of words. These are the ones worth arguing about.
Present assignment beats an agreement to assign
“The Supplier hereby assigns” transfers source code ownership the moment the work is created. “The Supplier shall assign” is a promise to sign something later, which is worth exactly as much as the supplier’s willingness to sign it during a dispute. Ask for present-tense assignment language covering both existing and future works.
Payment-conditional assignment is a trapdoor
Many supplier templates make the transfer conditional on payment of all sums due. That sounds fair and behaves badly: any invoice dispute, however small, suspends your source code ownership over the entire product at the exact moment you most need it. Negotiate it out, or narrow it so that only the specific unpaid deliverable is affected.
Subcontractor flow-down is the most common gap
An agency can only assign rights it holds. If it used freelancers or an offshore studio without written assignments from them, its promise to you is unenforceable in part. Require a warranty that every individual contributor — employee, contractor or subcontractor — has assigned or waived their rights, and ask for evidence rather than reassurance.
Moral rights need an explicit waiver
Assignment of copyright does not carry moral rights with it. Include a waiver to the fullest extent permitted by law, and where a jurisdiction does not allow waiver, a covenant not to assert them.
Escrow, exit and continuity clauses belong together
Ownership without access is academic. The assignment clause should sit next to a delivery obligation with a schedule, a repository access right during the term, and an exit assistance obligation with defined duration and day rates. Our guide to fixed-price versus time-and-materials contracts covers how the commercial model changes the leverage you have in these negotiations.
| Clause | Red flag wording | What to ask for instead |
|---|---|---|
| Assignment | “shall assign on request” | “hereby assigns, with full title guarantee” |
| Payment condition | “conditional on payment of all sums” | Unconditional, or limited to the disputed item |
| Background IP | “any pre-existing or generic material” | Named list in a schedule, fixed before kick-off |
| Licence-back | “non-exclusive licence for internal use” | Perpetual, irrevocable, sub-licensable, right to modify |
| Subcontractors | Silent | Warranty of flow-down assignment plus evidence |
| Open source | “may include third-party components” | Bill of materials per release, no copyleft without consent |
| Delivery | “on completion” | Continuous access to a client-owned repository |
| Exit | Silent | Defined exit period, rates and artefact list |
Source Code Escrow: Useful Fallback or Expensive Theatre?
Escrow is what suppliers offer when they will not assign source code ownership. A third-party agent holds a copy of the code and releases it to you if a defined trigger occurs — usually insolvency or sustained failure to support.
Escrow protects continuity, not ownership
An escrow release gives you a licence to use and maintain the code for your own purposes. It does not make you the owner, and it rarely lets you sell the software or bring it to market as your own product. Treating it as a substitute for source code ownership is the mistake; treating it as a disaster-recovery control for licensed off-the-shelf software is entirely sensible.
Unverified deposits are the standard failure
The cheapest escrow tier accepts whatever the supplier uploads and confirms only that a file arrived. When the trigger fires years later, clients discover an incomplete deposit, missing dependencies, no build instructions, or a snapshot two years stale. Verification — where the agent compiles the deposit and confirms it builds and runs — is what converts escrow from paperwork into a control.
Triggers are narrower than clients assume
Release conditions are usually limited to insolvency and material breach of support obligations. A supplier who simply becomes slow, expensive or hostile does not trigger anything, which is why escrow is a poor proxy for source code ownership. Read the trigger list and ask what happens in the scenario you actually fear.
The Handover: Proving Source Code Ownership Actually Transferred
A signed assignment is a legal fact. Whether you can operate the software is an engineering fact, and the two are independent. The test that settles it is a clean-room rebuild.
Rebuild the product on hardware the supplier has never touched
Take the delivered artefacts, give them to someone who did not write them, and have them build and deploy a working environment using only the documentation provided. Every step that requires a phone call to the supplier is a gap between paper source code ownership and real control. Run this test before final payment, while you still have commercial leverage.
Own the repository from day one
The cheapest control in this entire article is creating the repository under your own organisation account at the start of the project and adding the supplier as a collaborator. It converts handover from a transfer event into a permissions change, and it means source code ownership and possession never diverge. Apply the same logic to cloud accounts, CI systems and app store listings.
Work through a written artefact checklist
Handover disputes are usually about scope rather than refusal. A source code ownership checklist agreed at contract stage removes the argument.
| Artefact | Why it matters | Accepted when |
|---|---|---|
| Git repository with full history | Context, blame, release reproduction | Transferred to your organisation |
| CI/CD pipeline definitions | You cannot ship without them | A build runs in your account |
| Infrastructure as code | Environments are reproducible | A fresh environment provisions |
| Secrets and configuration inventory | Nothing silently expires | Rotated into your vault |
| Software bill of materials | Licence and vulnerability exposure | Generated per release |
| Automated test suite | Safe to change after handover | Passes on your infrastructure |
| Architecture and runbook docs | Onboarding a new maintainer | A stranger completes a rebuild |
| Signed assignment and waivers | Due diligence evidence | Executed by every contributor |
What Source Code Ownership Costs — and What Disputes Cost
Suppliers price source code ownership because assignment removes their ability to reuse the work. That is a real cost to them and it is negotiable rather than outrageous.
Expect a premium, and compare it to the alternative
A full assignment typically adds somewhere between five and fifteen per cent to a bespoke build compared with a licence-only deal, and more where the supplier has a genuine reusable platform underneath. Set against the cost of a failed IT outsourcing exit or a discount taken off an acquisition price, it is one of the better-value line items in the project. The same reasoning applies when you are budgeting ongoing software maintenance cost — you cannot competitively tender maintenance for code you do not own.
The cost of getting it wrong is not mostly legal fees
Legal costs are the visible part. The larger costs are the delay while a transaction stalls, the discount an acquirer applies to unclear source code ownership, the price of rewriting components you cannot secure rights to, and the leverage a supplier gains in every subsequent negotiation once both sides understand the position.
Recovering Source Code Ownership After You Have Already Signed
Most companies reading this already have live software and a contract they did not draft. The position is usually recoverable, and it is worth doing before a transaction forces the issue.
Establish what you actually hold
Collect every master agreement, statement of work, purchase order and email that might contain terms, then map each component of the product to the document that governs its source code ownership. Long-running relationships accumulate work done under expired agreements or none at all, and those are the gaps that matter.
Use renewal and change requests as leverage
The natural moment to fix source code ownership is when the supplier wants something: a renewal, a new phase, a rate increase, or a reference. Attaching a clean assignment deed to a change request is a normal commercial trade, and most suppliers will sign one for work already paid for rather than jeopardise the next phase.
Ask for a confirmatory assignment deed
A short standalone deed confirming source code ownership over everything delivered to date, with a moral rights waiver and a subcontractor warranty, is far easier to get signed than a contract renegotiation. It is also exactly the document a due-diligence lawyer will ask for.
Fix possession even where ownership stalls
If the supplier will not budge on rights, you can still improve your position considerably: move the repository into your own account, take over the cloud and app store accounts, obtain a build that a third party can compile, and commission a software bill of materials. Ownership and control are separate problems, and solving the second one buys time. A structured vendor management review is the right vehicle for this work, and pairs well with a broader look at your outsourcing strategies.
Source Code Ownership FAQ
Does paying for software mean I own it?
No. Payment creates a debt that has been settled; it does not transfer copyright. Source code ownership passes only by written assignment, and in its absence you may have nothing more than an implied licence to use the software as commissioned.
Can a supplier reuse code they wrote for us?
If the assignment is properly drafted, no — except for background IP that was explicitly carved out and listed. If the contract is silent, the supplier owns the work and can reuse it freely, including for your competitors.
Is escrow a reasonable alternative to owning the code?
For licensed off-the-shelf software, yes. For bespoke software you commissioned and paid for, it is a weak substitute: escrow gives continuity rights on narrow triggers, not source code ownership, and unverified deposits often fail when tested.
What if freelancers wrote part of our product?
Then those individuals may still own their contributions. Ask the agency for evidence of written assignments from every contributor. Where none exist, a confirmatory deed signed by the individual is the standard remedy.
Does open source in the codebase affect our rights?
It does not affect the bespoke code you own, but it imposes obligations that travel with the product. Copyleft components in distributed software are the ones to check carefully, which is why a per-release bill of materials matters.
How do we prove ownership during due diligence?
With the signed assignment, moral rights waivers, subcontractor warranties, a licence inventory from your bill of materials, and evidence that your organisation controls the repository and deployment accounts. Assembling this after a term sheet lands is how deals slip.
What should be in the contract if we are starting a new project now?
A present-tense assignment, a named background IP schedule with a broad licence-back, subcontractor flow-down warranties, a moral rights waiver, continuous repository access under your own account, an open-source policy with a bill of materials, and a defined exit assistance obligation. Working with a software development company in Chester or any other partner, those seven items are the ones to settle before the first sprint. If you are building a first release, the same principles apply to MVP development services — early-stage code becomes the foundation everything later is built on.
Should ownership terms differ for a discovery phase?
They should be identical. Discovery outputs — architecture, schemas, prototypes and research — are copyright works with real value, and they are the assets you take to a different supplier if the main build goes elsewhere. Cover them in the same assignment, as our software development RFP guide recommends doing from the tender stage onwards.
References
Copyright, Designs and Patents Act 1988, Section 11: First ownership of copyright
Copyright, Designs and Patents Act 1988, Section 90: Assignment and licences
Intellectual Property Office: Ownership of copyright works
GOV.UK: Intellectual property — an overview
Open Source Initiative: OSI Approved Licenses
OpenChain Project: ISO/IEC 5230 Open Source Licence Compliance
SPDX: The Software Package Data Exchange Specification
