Last reviewed 29 August 2026
When a software business 'sells' its product, it almost never transfers ownership. It grants a licence: a contractual permission to use copyright-protected code within defined limits. Everything commercially important flows from how those limits are drafted — who may use it, on what hardware, in which territories, for how long and for what purpose.
Get the scope wrong and you either give away more than you intended or create friction that slows every deal. Get the liability and warranty positions wrong and a single failure can cost more than the contract is worth.
This guide walks through the clauses that matter in UK software licensing, whether you licence on-premise software, distribute through resellers or embed third-party components in your own product.
Defining licence scope
Scope is defined by a combination of variables: exclusivity, territory, term, permitted users, permitted purpose, environments and volume metrics. A licence that is 'non-exclusive, worldwide, perpetual' but silent on user numbers may allow an entire group of companies to use software priced for one entity.
Be explicit about affiliates and contractors. Customers routinely assume group companies are covered; licensors routinely assume they are not. Say which it is. Similarly, state whether the licence covers development, testing, disaster recovery and staging environments, or only production.
Ownership of IP and of customisations
The licensor should retain all intellectual property in the software, including any improvements it makes. The interesting question is bespoke work: if you build a customer-specific module, who owns it? Under English law, absent an assignment in writing, copyright in commissioned software generally remains with the developer — but that surprises many customers, so the position should be spelled out.
A common compromise is that the customer owns its own data and configuration, while the licensor owns the code, granting the customer a licence to the customisation. Where a customer insists on owning bespoke code, consider a licence-back so you are not blocked from using the underlying techniques elsewhere.
Support, maintenance and service levels
Support obligations should be separate from the licence grant, with their own commercial terms. Define response times and, where relevant, resolution targets by severity level, and state what is excluded — customer misuse, third-party environments, unsupported versions.
If you offer service credits, make clear whether they are the sole remedy for service failures. Also define an end-of-life or version-support policy: how many prior versions you support and how much notice you give before withdrawing support. Customers relying on a legacy version need to know, and it protects you from an open-ended maintenance obligation.
Warranties, indemnities and liability
Typical licensor warranties cover authority to grant the licence, conformity with documentation for a defined period, and absence of known malicious code. Resist warranting that software will be error-free — it is unachievable and unnecessary.
An IP infringement indemnity is normal and usually the customer's key ask. Cap it, carve out modifications made by the customer and combinations with third-party products, and reserve the right to procure a replacement, modify the software or terminate and refund.
Liability caps must be reasonable to survive the Unfair Contract Terms Act 1977 in business contracts where standard terms are used. A cap set at a nominal figure against a substantial contract value invites a challenge. Never attempt to exclude liability for death or personal injury caused by negligence, or for fraud.
Open-source components and third-party code
Most modern software includes open-source libraries. Permissive licences such as MIT and Apache 2.0 are generally low risk with proper attribution. Copyleft licences such as GPL and AGPL can require you to make your own source code available in defined circumstances — a serious commercial issue for a proprietary product.
Maintain a software bill of materials, run periodic licence scans, and make sure your customer-facing warranties are consistent with what your components actually permit. If you warrant that the software does not include copyleft code, verify it before signing.
Audit rights, termination and exit
Audit clauses let a licensor verify usage against licence metrics. Make them reasonable — advance notice, business hours, confidentiality obligations on the auditor, and a cost-shifting provision if underpayment exceeds a set percentage. Aggressive audit clauses damage relationships and are often unenforceable in practice.
On termination, address what happens to the customer's data, whether any run-off period applies, and whether licences for perpetual deployments survive. Source code escrow is worth considering for business-critical on-premise deployments; agree the release triggers precisely, because generic escrow terms are frequently unusable when they are actually needed.
Key points
- A licence is permission to use, not a transfer of ownership — define the limits precisely.
- State clearly whether affiliates, contractors and non-production environments are covered.
- Commissioned code stays with the developer unless assigned in writing.
- Liability caps must be reasonable to withstand challenge under UCTA 1977.
- Copyleft open-source components can undermine a proprietary licensing model.
- Escrow release triggers should be drafted for the scenario you actually fear.
Frequently asked questions
- What is the difference between a licence and an assignment?
- An assignment transfers ownership of the intellectual property permanently. A licence grants permission to use it while ownership stays with the licensor. Almost all software transactions are licences; assignments are rare outside acquisitions and bespoke development deals.
- Do I need a separate agreement for SaaS?
- Usually yes. SaaS is a service, not a delivered copy, so the drafting focuses on access rights, uptime, data protection and hosting rather than installation and copies. Using an on-premise licence for a SaaS product creates gaps around data and availability.
- Can I limit liability to the fees paid?
- Frequently, yes — a cap at the fees paid in the preceding twelve months is common in business-to-business software contracts. Whether it is enforceable depends on reasonableness under UCTA where standard terms apply, so the cap should bear a sensible relationship to the contract value and the risk.
- What should I check before using an open-source library?
- Identify the licence, whether it is permissive or copyleft, the attribution requirements, and whether distribution or network use triggers source-disclosure obligations. Record the answer in a bill of materials so you can answer customer due diligence questions quickly.