Who Owns the Code in Bespoke Software and Why Software Escrow Matters

When a business pays for bespoke software, most people assume the business owns the code. Under UK law that isn’t automatic, and the question usually only comes up when a supplier relationship ends, a company changes hands or the original developer stops trading. Source code ownership, licences and software escrow are all ways of making sure you keep control of software your business depends on, and they’re worth settling before any bespoke software development for UK businesses begins.

This article explains the general position in plain terms. It isn’t legal advice, and contract terms for your own project should be reviewed by a solicitor who can look at your specific circumstances.

Who Owns the Code by Default

Software is protected by copyright in the UK. The Copyright, Designs and Patents Act 1988 treats a computer program as a literary work, so the code your supplier writes has the same kind of protection as a book or a report. Copyright arises automatically when the code is written, and there’s no register to join.

The first owner is normally the author. Where code is written by an employee in the course of their employment, section 11 of the Act makes the employer the first owner. That’s why software written by your own staff usually belongs to your business, while software written by an outside supplier usually doesn’t.

The Intellectual Property Office’s guidance on ownership of copyright works is clear on commissioned work. The person or organisation that created it is the first owner, not the commissioner, unless something else is agreed in writing. Where the contract is silent, a court may find an implied licence to use the work for its intended purpose, but that may only be a limited, non-exclusive right rather than ownership.

Assignment and Licences Explained

There are two main ways a contract can give you rights in code written by a supplier. It can transfer ownership to you, or it can give you permission to use code the supplier continues to own. Each is common and each suits different situations.

The terms below come up in most software contracts. Knowing what each one means makes it much easier to read a proposal or a set of terms and spot what’s missing.

Assignment

A transfer of copyright ownership from the supplier to you. Under section 90 of the Act it must be in writing and signed by or on behalf of the supplier.

Licence

Permission to use code that someone else owns. Its scope, duration and any restrictions are set by the licence terms.

Background IP

Code, tools or components a supplier owned before your project began. Contracts usually license this to you rather than assigning it.

Software escrow

An arrangement where an independent third party holds a copy of the source code. It is released to you only if agreed trigger events occur.

The requirement for a written, signed assignment is set out in section 90 of the Copyright, Designs and Patents Act. An email saying the code is yours, or an invoice marked paid, is unlikely to be enough on its own.

What Software Escrow Is and When It Matters

Software escrow exists for situations where you rely on software you don’t own. The supplier deposits the source code, and usually build instructions and documentation, with an independent escrow agent. If a trigger event happens, such as the supplier becoming insolvent or failing to meet its support obligations, the agent releases the deposit so you or another developer can keep the software running.

Escrow is most common with licensed products, where the supplier sells the same software to many customers and won’t assign ownership to any of them. It’s also used for critical systems where the cost of losing access would be severe. The value depends on the deposit being complete and current, so many arrangements include verification, where the escrow agent checks that the deposited code can be built into working software.

Escrow protects your access to code you don’t control. If the contract already hands you the code, the repository and the documentation, the case for escrow becomes much weaker.

For fully bespoke software that is assigned to you, escrow is often unnecessary. The practical protection comes from having the code in a version-controlled repository you can access, with documentation good enough for another developer to pick it up.

Open Source Components in Bespoke Software

Almost all modern software includes open source libraries and frameworks. These save time and are often well maintained, but they’re not owned by your supplier, so they can’t be assigned to you. You receive them under their own licences, which the Open Source Initiative lists in its register of approved open source licences.

Most of these licences are permissive and cause no issues for business use. Some place conditions on how modified code is shared, which matters if you plan to sell or distribute the software. The government’s guidance to be open and use open source suggests checking that a component’s licence is acceptable for your business requirements, and the same check is sensible for any bespoke build.

Third-party components also affect security. The NCSC’s supply chain security guidance applies to software dependencies as much as to suppliers, so a record of what’s included and how it’s kept up to date should form part of the handover documentation.

What to Agree Before the Build Starts

Ownership is far easier to agree at the start of a project than at the end of a relationship. The contract should say who owns the bespoke code, how any background IP and open source components are licensed and what you receive at handover. It should also cover your data, whether that sits in custom web applications, a customer portal or the connections built through systems integration.

The comparison below shows the difference between terms that protect you and terms that leave gaps. It isn’t a template, and a solicitor should review the final wording.

Priority Pixels keeps everything it builds under version control from day one, with documentation delivered alongside the code. Code, data and documentation belong to the client and are handed over cleanly if the client ever moves on, because the aim is to leave you with a maintainable asset rather than a dependency. If you’re planning a build with Priority Pixels, the discovery stage is a good point to raise ownership questions, so they’re settled alongside the scope before any development begins.