Who owns the features a customer pays you to build?

Under UK copyright law, paying for a feature does not, by itself, transfer copyright to the customer. A software supplier can agree to retain its platform and reusable improvements while giving the customer the rights it needs. The contract must identify what each party keeps, what the customer can do with the result, and what happens when the relationship ends.

You have a platform used by several customers. A new customer pays for an approval workflow and an integration with its internal systems. Its contract says:

“All intellectual property rights in the Deliverables and all developments and improvements arising from the Services belong to the Customer.”

Your team expects to reuse the workflow engine. The customer expects to protect its investment. Both expectations need to be resolved before development starts.

This article considers business software contracts under English law, focusing on UK copyright and the commercial allocation of rights. Patents, database rights and other rights may need separate treatment. The project below is an example.

Does paying for development give the customer ownership?

Payment alone does not decide copyright ownership. The starting point is generally the author, with an exception for work created by an employee in the course of employment. A supplier using freelancers must also establish how their rights reach it. An assignment of copyright must be in writing and signed by or on behalf of the assignor. CDPA, section 11; section 90.

Where the contract is silent, a customer may still have an implied licence. In some circumstances, a court may instead imply an obligation to assign copyright. Neither outcome follows from payment alone. Agree expressly whether the customer may modify the software, appoint another developer or commercialise the result. UK Intellectual Property Office (IPO) guidance on commissioned works; Griggs, [2005] EWCA Civ 11, paragraphs 13–15. My Background IP guide discusses the different outcomes in Griggs and the software case Clearsprings.

The article on code written by contractors covers that starting position. Here, the negotiation is about which rights the supplier should retain and which rights the customer should receive.

What counts as your platform?

Define which platform materials the supplier retains and check that it holds the rights it promises. An exception for “Background IP” may preserve the existing platform, but a definition limited to material created before the contract can leave new, reusable improvements inside the customer's assignment.

The workflow engine in our example did not exist before the project. That does not prevent the parties from agreeing that the supplier will own it. It means the contract must expressly deal with reusable developments created during the project.

I would start with an allocation like this, then check it with the engineering team:

This is a proposed deal, not a division imposed by law. Calling code “generic” does not reserve it to the supplier. Calling it “bespoke” does not automatically give it to the customer.

A schedule should name meaningful components, functions or deliverables. Agree the classification of new work through change control, rather than letting either party relabel it at handover. For third-party components, see open-source software and customer warranties.

What does the customer actually need?

“We need to own it” can mean several things: we need to keep using it, modify it, replace you as the maintainer, sell the resulting product, or stop you giving the same development to a competitor. These requirements lead to different terms.

Example

What will the customer do with the product?

Use in its business · Platform and reusable improvements

Keep the foundation for other projects.

Retain the platform and reusable improvements, including new ones. Set out how the customer may use them as part of the product.

Agree the duration, permitted users and whether another team may maintain it.

Suggested reply

Let's identify the platform and reusable improvements that should remain ours. We can then agree the rights you need to use and maintain them as part of the product.

Use in its business · Customer-specific code

Define the rights the customer needs.

For customer-specific work, agree an assignment or a licence. Identify that work clearly in the contract.

Separate reusable platform improvements you need for other projects. Agree access to the source code.

Suggested reply

Let's identify the work built specifically for you and agree whether you need ownership or a licence. Reusable improvements to our platform should be dealt with separately.

Use in its business · Third-party libraries

Match the licences to the customer's needs.

Third-party libraries come with their own terms. Confirm that they allow the customer's intended use and maintenance by another team.

Your contract cannot change someone else's licence. Some components may need separate permission.

Suggested reply

The product includes third-party libraries under their own licences. Let's identify them and confirm that those terms support your intended use and maintenance.

Sell to its customers · Platform and reusable improvements

Allow product sales. Keep your platform rights.

Agree distribution of the required platform components and improvements with the product. Define what end customers may do.

Discuss modifications, maintenance and how they receive permission to use it. An internal-use licence does not cover this scenario.

Suggested reply

We can discuss rights to distribute the required platform components, including agreed improvements, with your product. Let's define what your customers may do while keeping the agreed platform rights with us.

Sell to its customers · Customer-specific code

Agree the rights needed for resale.

Identify which new deliverables the customer will own and which it may include in its product under licence.

The customer does not automatically need ownership of all your work. It needs rights that support its promises to its customers.

Suggested reply

Let's agree which new deliverables you will own and which you may distribute under licence. The rights should support your sales model without including all of our reusable work.

Sell to its customers · Third-party libraries

Check the distribution conditions.

Identify the notices and licence texts to supply, and whether and how source code must be made available.

You cannot automatically grant every permission on your own terms. End customers' rights must be consistent with the component licences.

Suggested reply

Before agreeing resale rights, let's check the distribution conditions for each third-party component. Your customers may need notices, source code or permissions under the original licences.

The terms depend on the rights you hold and the third-party licences.

Also agree whether other group companies may use the software and where it may be hosted.

Section 50C CDPA can permit a lawful user to copy or adapt a program to correct errors, where necessary for lawful use and not prohibited by the relevant agreement. It does not settle every maintenance requirement. Agree the customer's rights to modify the software and appoint a replacement maintainer, together with the source access needed to exercise them.

Read duration and termination together. A licence described as “perpetual” still needs clear treatment of termination rights and survival when the development or support agreement ends. UK government IP Rights Guidance Note, section 1.6.

For SaaS, separate access to the running service from rights in the underlying code. A perpetual software licence does not, by itself, promise perpetual hosting, support or future releases. The agreement needs to state what remains available after the subscription ends.

Which ownership arrangement fits the deal?

The supplier keeps the platform and reusable developments

This can work where the new functionality becomes part of a product offered to several customers. The customer receives the agreed licence or service access, with adequate continuity arrangements. The supplier remains free to develop the retained components for other customers, subject to confidentiality and any agreed restrictions.

The customer's funding still needs a commercial explanation. It may be paying for priority, integration, a particular specification or an earlier release. Make that bargain visible instead of treating reuse as something the customer should discover later.

The customer owns identified bespoke deliverables

The customer might own a particular integration while the supplier retains the platform and workflow engine. The customer also needs sufficient rights in any retained components required to use its integration. If the contract does not define those rights, a court may imply rights needed to fulfil the agreed purpose, and their scope may be wider than the supplier expects.

If the supplier needs to reuse material included in the assignment, negotiate an express licence back for identified material and purposes. Do not assume a right to maintain the customer's system also permits resale to other clients. Equally, a broad licence back should not quietly defeat exclusivity sold to the customer.

What if you agree joint ownership?

Joint ownership needs its own operating rules. It does not, by itself, let either party reuse the code. For jointly owned UK copyright, each owner generally needs the others' consent to copy or adapt the code, as well as to license it to others, subject to statutory exceptions. Agree in advance what each party may do without fresh approval, including any authority to grant licences. Set out revenue sharing, enforcement and exit; a 50:50 split does not resolve them. Ownership by one party with a properly scoped licence to the other may be simpler. CDPA, section 16; section 173(2); IPO guidance on joint authors.

The customer buys a defined period of exclusivity

A customer concerned about competitive advantage may accept a limited restriction on the supplier offering a specified development to named competitors or within an agreed market. Define the functionality, prohibited conduct, duration and exceptions. Protect the supplier's ability to support existing customers and make unrelated improvements.

This is different from an exclusive copyright licence. Under section 92, an exclusive copyright licence must be in writing and signed by or on behalf of the copyright owner. Within its scope, it excludes everyone else, including the owner. A contractual restriction on competing supply needs its own drafting and an assessment of enforceability and competition law. CDPA, section 92.

Nor does ownership of code necessarily give the customer a monopoly over what the feature does. Copyright in a program does not protect functionality as such. A promise by the supplier to restrict its own conduct does not bind an independent competitor. SAS Institute, C-406/10, paragraphs 39–46; Court of Appeal, [2013] EWCA Civ 1482, paragraphs 45–52.

Can you reuse code you wrote for a client?

You can reuse code only if you have the necessary rights and the proposed reuse complies with the contract, confidentiality obligations and applicable third-party licences. Retaining copyright does not by itself give you unrestricted reuse rights.

In Clearsprings Management Ltd v Businesslinx Ltd [2005] EWHC 1487 (Ch), paragraphs 23 and 38–53, the contract did not expressly allocate copyright. The customer received a non-exclusive licence to use, maintain and upgrade the system, without ownership or a right to sub-license. The court also recognised a restriction on the developer using the system as a whole, for example by selling it to a third party. Generic routines remained available for reuse, subject to protection of the customer's operating procedures. The court left the precise limits of that restriction unresolved. The outcome depended on the facts, so the contract should settle reuse expressly.

In our example, the reusable approval engine and the customer's confidential approval rules need separate treatment. Removing the customer's name does not necessarily remove its confidential information. The Trade Secrets Regulations treat use or disclosure of a trade secret as unlawful where it breaches confidence. Define permitted reuse, identify excluded customer material and check how they can be separated in the code. Trade Secrets Regulations 2018, regulation 3.

How should rights affect the price?

There is no automatic legal entitlement to a discount or premium. This is a commercial negotiation about what the customer receives and what future use the supplier gives up. Agree it before the work starts, including how later changes to the specification affect both price and rights.

Also agree whether source delivery, transition assistance and support are included in the development fee or priced separately. A change in ownership does not settle the cost of providing those services.

What would I change in the ownership clause?

Return to the customer's request for all developments and improvements. Adding an exception for pre-existing code leaves the new workflow engine unresolved. The revision should make the agreed allocation visible.

This illustrates the boundary of the transfer, not a complete clause. Clauses 12.2 and 12.3 still need the operative assignment and a licence that supports the agreed use, modification and maintenance, including replacement providers. The supplier must hold the rights it promises. Other IP rights require their own treatment where relevant.

Agree when the assignment and licence take effect, how the customer can test or use the work before final payment, and what survives termination. Do not let a broad definition of “Deliverables” or an ownership warranty elsewhere undo the agreed exceptions.

Check which document prevails if the statement of work or a later change order uses a different ownership formula.

For the claims and costs you agree to cover, see software IP indemnities: what suppliers should agree before signing.

What happens if the supplier can no longer support it?

A customer can own its integration and still depend on the supplier's runtime, documentation and infrastructure. Ownership alone will not make that integration independently operable.

For delivered software, agree source-code access, build and deployment instructions, dependencies and the practical handover to another maintainer. For SaaS, address export of data and configuration, the transition period, assistance and charges. Check whether an alternative operator could actually run the relevant system.

Escrow can be one part of that arrangement: agreed materials are held by an independent party and released on specified events. UK government guidance discusses source-code escrow where a supplier retains rights, with defined release events and updated deposits. Model Services Contract Guidance, section 2.7.3.

I would also require a clear licence on release and a way to verify that the deposit is usable. For a cloud service, source files alone may not include the infrastructure configuration, external services or operational knowledge needed to restart it. Any continuity promise should reflect those dependencies.

What should you check before signing?

1. Identify the retained platform. Record the components being brought into the project and establish the supplier's rights.
2. Allocate new developments. Cover reusable improvements created during the project as well as customer-specific deliverables. Update the allocation when scope changes.
3. Match rights to use. Check operation, modification, distribution, replacement maintenance and the position after termination against the actual delivery model.
4. Make reuse and exclusivity explicit. Identify what the supplier may use elsewhere and protect customer material, confidentiality and third-party rights.
5. Agree a workable exit. Connect legal rights with source access, data export, handover and any escrow arrangements.
6. Check the whole contract. Definitions, statements of work, warranties, licence restrictions and termination clauses must reflect the same bargain.

The contract should let the customer use what it paid for on the agreed terms, while making clear which developments the supplier can continue to use in its business.

If a customer's draft would transfer your platform or restrict reuse of your code, my code rights review examines the proposed terms, the underlying rights and the changes needed before signing.

General information, not advice on a particular contract.