Notes / Software & IP
Software IP indemnities: what suppliers should agree before signing
How to negotiate a software IP indemnity: claims, exclusions, defence, remedies and liability caps, with a sample exclusion clause.
A software IP indemnity allocates responsibility for specified intellectual property claims. Before agreeing to one, a supplier should identify the claims it covers, who manages the defence, what happens to the product and how much liability it accepts. The word “indemnity” does not answer those questions by itself.
Your customer accepts that you own the platform and it receives a licence. Then its standard contract asks you to cover “all losses arising from any intellectual property claim relating to the software”.
That could involve more than paying a copyright owner. What if a patent claim concerns the customer's combination of your product with another system? Who pays to replace a disputed component? Can the customer settle a claim and send you the bill?
This article sets out a supplier's negotiation approach. The suggested drafting is illustrative and incomplete. The choices need to fit the product, customer use and the rest of the agreement.
1. Identify the claim you are agreeing to cover
Separate a third party's infringement allegation from the customer's claim that you broke your own contract.
Suppose another developer alleges that your product copies its code. That is the kind of third-party claim an IP indemnity can cover. Suppose instead that the customer discovers you did not own a component, despite promising ownership of everything. The customer may have a contractual claim even if the component is properly licensed and no rightsholder alleges infringement.
A clause confined to third-party infringement claims may not cover that second situation. Read the ownership warranty, indemnity and remedies together. For the underlying allocation of rights, see who owns customer-funded software.
In Wood v Capita, the Supreme Court interpreted an indemnity by considering its language, the whole contract and context. The claim failed because the relevant losses did not arise from the specified claims or complaints. The case concerned a business sale, not software, but illustrates why the trigger matters. Wood v Capita [2017] UKSC 24, paragraphs 10–13 and 38–41.
If you agree to defend allegations before liability is established, say so. Separately identify what you pay: defence costs, court awards and authorised settlements. Decide whether the customer's own investigation costs, disruption and replacement costs are also covered.
2. Match coverage to the product and permitted use
Identify the software, versions and services covered. Decide whether protection extends to documentation, customer-specific work, embedded components and use by affiliates or authorised contractors.
List the relevant rights and territories. Copyright, patents, trade marks and confidential information raise different issues. A contract governed by English law still needs to say which territorial claims the supplier accepts.
Code independently created without copying does not infringe copyright in someone else's code, but using it can still infringe a patent. Development controls that reduce copying risk therefore do not resolve patent risk. A supplier may seek to limit patent coverage, for example to specified countries. Copyright, Designs and Patents Act 1988, section 16; Patents Act 1977, section 60.
The permitted use should reflect the actual deal. Internal use is different from embedding the software in a product sold to others. If integration is part of the agreed solution, an exclusion for every combination with other software could remove protection from its intended use.
Avoid assuming that everything supplied by a third party can be excluded. If the supplier selected and integrated a library, the customer may expect the supplier to handle claims about it. The supplier should investigate that exposure and price or limit it expressly.
Open-source components need the same attention. Their licence terms and the promises made to the customer are separate questions. See open-source software and customer warranties.
3. Connect exclusions to what caused the claim
Possible exclusions include unauthorised customer changes, use outside the agreed scope and customer-provided materials. Their wording should address the connection between that conduct and the alleged infringement.
Consider a customer that changes an unrelated report layout. An exclusion for any modified software could be argued to remove protection for a claim about an unchanged component. A more targeted negotiation asks whether, and to what extent, the customer's change caused the allegation.
For example, this fragment addresses only that exclusion:
“The exclusion applies only to the extent that the alleged infringement is caused by a modification made by or for the Customer without the Supplier's authorisation. It does not apply to modifications made by the Supplier or required by the agreed implementation.”
It still needs agreement on authorised changes and the treatment of mixed causes. Apply similar care to combinations: identify approved integrations and dependencies instead of using an exclusion that contradicts the specification.
Customer instructions also need precision. A request for an outcome, such as a search function, leaves the supplier substantial design choices. Requiring a particular piece of code is different. Decide which materials and mandatory instructions the customer takes responsibility for, and whether it gives a corresponding indemnity. Symmetry alone does not establish a sensible allocation.
4. Agree how a claim will be handled
A defence process needs to work before the court decides who is right.
Five terms to negotiate
Notice of the claim
Specify how the customer gives notice, who receives it and what information must follow. As indemnifier, the supplier may want prompt notice to be a condition of its obligations. A negotiated compromise reduces protection only to the extent late notice materially prejudices the defence. Whether a notice requirement operates as a condition depends on the wording, so state the intended consequence expressly.
Lawyers and defence strategy
If the supplier is paying for the defence, it may want to select lawyers and control strategy. The customer needs information, reasonable participation and a route to protect itself if the supplier does not act promptly. Address conflicts of interest and who pays for separate representation when needed.
Consent to settlement
Settlement control needs limits. A monetary settlement paid by the supplier is different from one requiring the customer to admit liability, stop using essential software or accept continuing obligations. Specify when the customer's consent is required and whether it may be refused only on reasonable grounds.
The customer's own actions
Address admissions, commitments and settlements by the customer too. The supplier may require prior written consent and exclude responsibility for unauthorised settlements of covered claims. Define any exceptions for urgent protective action or a failure by the supplier to conduct the defence, including what notice is practicable and which resulting costs the supplier must cover.
Funding before the outcome
Deal with urgent injunction applications, cooperation costs and claims combining covered IP allegations with unrelated matters. Decide how defence costs are funded while the parties dispute coverage. A promise to reimburse the final award leaves that immediate cash-flow question unanswered.
5. Preserve the use the customer bought
An indemnity payment alone may not keep the customer's systems running. Agree what happens if continued use is challenged or prohibited.
Three remedies
- Obtain a licence
- Replace the component
- Modify it
Define what counts as an acceptable fix: agreed functionality, security, performance, compatibility and support should survive. Set a workable deadline and allocate testing, migration and deployment costs.
The UK government's Model Services Contract provides one concrete example. Clause 17 permits a licence or replacement or modification, with conditions protecting equivalent performance and functionality, the wider environment and the customer's costs. It also addresses termination and substitute costs if those steps do not resolve the claim. This is a template for high-value, complex public procurement, not a universal position for software deals. Model Services Contract, England and Wales, version 2.2A, clause 17; intended scope.
For a smaller subscription, the parties might agree a narrower fallback: termination of the affected service, a defined refund and transition assistance. A refund may be insufficient if the customer has invested heavily in integration. Negotiate that consequence before describing replacement or refund as the customer's only remedy.
6. Read the indemnity beside the liability cap
Three possible arrangements
Agree how the IP indemnity relates to the liability cap.
Then make the operative clauses say the same thing. For a separate cap, state whether it sits within the general cap or adds to it.
The Model Services Contract expressly makes its IP indemnity unlimited in clause 23.2. It also expressly applies a mitigation obligation to indemnity losses in clause 23.10. These are provisions of that contract, not consequences that follow simply from using the word “indemnity”. Core Terms, clause 23.
For a negotiated cap, check whether defence costs erode it, whether connected claims share a limit and how the limit interacts with other claims arising from the same event. A rolling fee-based cap needs a reference period and a rule for claims after termination.
Address the costs of obtaining a licence, replacement, modification, migration and transition assistance separately. Specify whether these obligations have a financial limit, whether the supplier's own spending on them counts towards the liability cap, and how refunds are treated.
Read exclusions of loss with equal care. Does an exclusion of lost profits affect sums awarded to a third-party claimant, the customer's own losses, or both? State the intended treatment rather than relying on a general label.
If the indemnity is an exclusive remedy, identify its precise subject matter and preserve any separately agreed continuity or termination rights. Check enforceability separately. Do not assume contractual labels settle questions about recovery, mitigation or mandatory legal limits.
7. Compare the promise with your upstream protection
A component vendor or AI provider may offer an indemnity, but it covers the claims and beneficiaries described in its own agreement.
Anthropic's Commercial Terms, for example, exclude defence and indemnification to the extent a claim arises from specified modifications, combinations or the practice of a patented invention contained in output, among other matters. Its payment promise covers court judgments on covered claims, or arbitral awards under Anthropic-approved settlements, alongside a separate duty to defend. It is not a general promise to reimburse every customer loss. Anthropic, sections K.1–K.4.
OpenAI's API terms exclude coverage where output has been modified or transformed, or combined with products or services not provided by or on behalf of OpenAI. Unlike Anthropic's wording, that exclusion does not expressly limit its effect to the extent the change or combination caused the claim. This is the causation issue discussed in section 3; assess coverage under the full agreement and the facts. OpenAI Service Terms, section 1.
Compare the actual product and plan, the contracting entity, covered uses, exclusions, notice duties, control of the defence and financial limits. Your customer contract may require you to defend a reseller or end user whom the upstream contract does not protect.
Your supplier's control of the defence can also conflict with control you promised your customer. A settlement you approve downstream may need upstream consent before any reimbursement is available.
Record the gaps and decide whether to accept, insure, limit or remove the relevant exposure. Do not describe the promises as matching until you have compared them. For AI development, see ownership and customer promises concerning AI-generated code.
Before signing
Test the proposed clause against three concrete situations: a claim about unchanged supplier code, a claim caused partly by customer changes, and a claim that forces a key component to be replaced.
For each, establish who defends, who pays, which exclusions apply, what the customer can keep using and where the financial limit sits. If the answers differ between the indemnity, product specification, liability clause and upstream contract, resolve that conflict before signature.
An effective IP indemnity gives the customer a credible response to a covered claim and the supplier a defined responsibility it can manage.
If you are negotiating software rights, warranties or IP indemnities, see how a code rights review can help.
General information, not advice on a particular contract.