IP Licensing and Source Code Handover in Software Contracts

Why does intellectual property matter so much in software contracts?

Intellectual property is one of the most important and most misunderstood areas of any bespoke software contract. Clients often arrive at the negotiating table focused on a single question: ‘Do we own the IP?’ That is the wrong place to start.

The key question is not whether the client owns the intellectual property, but what rights the client has to use, modify, and maintain the software after delivery. Ownership is a label. Practical control is what lets you run the platform, change it as your business changes, fix it when something breaks, and bring in whoever you like to help. A client can hold a perpetual licence rather than outright ownership and still have every practical right they need. Equally, a client could in theory own the IP and yet find their hands tied by open-source obligations or missing components. So the productive conversation is about rights, not labels.

This guide explains the two main models (licensing and assignment), how source code handover is staged against payment, and the specific protections to look for. It is a companion to the broader practical guide to software development contracts, which covers IP alongside nine other contract areas.

Licence or assignment: which model do most contracts use?

Most bespoke software contracts use a licensing model rather than outright IP assignment. The distinction is worth understanding because the two allocate ownership very differently while, in practice, leaving the client in much the same position.

How a licence works

Under a licence, the development partner retains ownership of the intellectual property but grants the client a broad, perpetual right to use, copy, modify, and maintain the software. This is not a limitation on the client. A well-drafted licence gives the client everything they need to run and evolve the platform independently, including the right to engage third-party developers.

The word ‘perpetual’ is doing real work here. A perpetual, irrevocable licence does not expire and cannot be withdrawn, so the client is not exposed to the risk of the partner one day switching the platform off or renegotiating the terms. Combined with the right to modify and the right to sublicense to third-party contractors, a perpetual licence gives the client durable, independent control.

How assignment works, and why it is less common

Assignment means transferring ownership of the intellectual property to the client outright. In principle that sounds cleaner, but in practice it is less common, because it creates complications around the things bespoke software is actually built from.

Bespoke software is rarely written entirely from scratch. It is assembled from pre-existing components, open-source libraries, and shared frameworks that the development partner uses across multiple projects. The partner cannot assign ownership of an open-source library it does not own, and it usually cannot assign ownership of a reusable framework it relies on for other clients without undermining its own business. So an assignment tends to end up riddled with carve-outs and licence-backs, at which point it offers the client little more than a licence would have, with more complexity. A licence avoids these issues while still giving the client full practical control.

When do I actually get the source code?

Source code handover is typically tied to payment, and understanding why removes a lot of anxiety from the negotiation.

During the build and payment period, the development partner stores the source code in their own repository, such as GitHub Enterprise. Once all payments are made in full, including any IP licence fee, a complete copy of the source code is provided to the client in repositories of their choosing. The client can then host and manage the code on any platform they choose, with no restrictions imposed by the partner.

Why handover is staged against payment

This staged approach exists because the source code is the development partner’s security during the payment period. Once the code is handed over, the client could in theory engage a third party to maintain the platform without completing their payments. Tying handover to full payment protects both parties: the client knows they will receive the code, and the development partner knows they will be paid.

It is worth being explicit that this is a protection, not a restriction in disguise. The client is not at risk of being denied the code, because the trigger is clear and within the client’s own control: pay in full, receive the complete code. The arrangement simply aligns the moment the partner loses its security with the moment the client has met its commitment. This is also why, as the main contracts guide notes, the minimum support period should align to the payment and handover timeline rather than an arbitrary fixed term: until handover, the client cannot engage a third-party support provider anyway.

How does this differ from copying an existing product?

It is easy to confuse two questions that are genuinely different.

This guide is about the licensing and handover of newly commissioned software: software your development partner is building for you, and the rights you receive to it. The separate question of what you can lawfully replicate when you replace an existing product you do not own (a SaaS tool, for example) is about copyright in someone else’s software, not about the contract for your own build. UK copyright protects the expression of software, not its functionality, and there are defensible ways to build a replacement, but that is a different legal analysis. We cover it in the guide on what you can and cannot legally copy when replacing SaaS.

A third, related thread is ownership of AI-assisted code. As development partners increasingly use AI tools to write code, clients reasonably ask who owns the output and whether it is safe to use. That question sits alongside the licensing model rather than replacing it: the licence still governs your rights to the delivered software, while AI provenance affects the quality and risk assurances you should expect. Our blog on AI code ownership for UK CTOs goes into the detail.

What is an SBOM and why should I ask for one?

Because bespoke software is assembled from many third-party and open-source components, you need a way to see what is inside the box. That is what a software bill of materials (SBOM) provides.

An SBOM identifies all the third-party and open-source components that make up the software. It is the inventory that lets you confirm that open-source components are compatible with your intended use, understand exactly what you will be responsible for maintaining, and assess security and licensing risk on an ongoing basis. Without an SBOM, a client can hold a perfectly good licence and a complete copy of the code, yet still be blind to the obligations attached to the open-source libraries woven through it. Some open-source licences, for instance, attach conditions to how you distribute or modify the code, and you want to know about those before you build a business on top of them.

Treat the SBOM as a standard part of handover, delivered alongside the source code, not as an optional extra.

What to look for in your contract

When reviewing the intellectual property and source code provisions of a bespoke software contract, check for the following:

• A perpetual, irrevocable licence to use, copy, modify, and maintain the software.
• The right to sublicense to third-party contractors for maintenance and development.
• A clear trigger for full source code handover, typically payment in full.
• A software bill of materials (SBOM) identifying all third-party and open-source components.
• No restrictions on how the client hosts or manages the code after handover.
• Confirmation that open-source components are compatible with the intended use.

Together, these provisions give you the practical control that matters: the ability to run, change, fix, and move your platform, with whoever you choose, for as long as you need it. That is the substance behind the ownership question, and it is achievable under a well-drafted licence without the complications of outright assignment.

Where to go from here

This guide is a deep dive into one of the ten areas covered in our practical guide to software development contracts, which sets IP licensing and source code handover in the context of capped investment, liability, acceptance testing, exit rights, support, and more.

If you are reviewing the IP and handover terms of a bespoke software contract and would like to talk them through, book a consultation.

This guide explains how intellectual property licensing and source code handover commonly work in bespoke software development contracts, in plain English. It is not legal advice. For advice specific to your circumstances, consult a solicitor qualified in intellectual property, technology, and commercial contracts. It reflects common UK market practice as at June 2026.