SaaS Contracts · Memo
IP Indemnification Carve-Outs in SaaS Agreements
A note on the carve-outs that should survive negotiation, the carve-outs that quietly defeat the indemnity, and how I size the remedy clause so it actually means something when an infringement claim lands.
The IP indemnity is usually the most heavily negotiated clause in a SaaS master agreement, and for good reason. It is one of the few provisions where the dollars at issue can dwarf the contract price by an order of magnitude. A patent troll demand on a CRM that costs the customer $40,000 a year can land at $4 million on the cover letter. The indemnity allocates that risk. The carve-outs decide what the indemnity actually covers when the lawsuit shows up. Counsel who treat the carve-outs as boilerplate are giving away the protection their client paid for.
Standard structure I expect to see
The vendor's first draft typically promises to defend, indemnify, and hold harmless the customer against third-party claims alleging that the service, as provided by the vendor and used in accordance with the agreement, infringes a third party's patent, copyright, trademark, or trade secret. The first negotiation point is whether the obligation is a defense obligation (vendor controls), an indemnity obligation (vendor pays), or both. I want both for the customer, with reasonable control mechanics around settlements that admit fault or impose injunctive relief on the customer.
The carve-outs follow. The reasonable ones are uncontroversial: claims arising from the customer's combination of the service with non-vendor materials where the infringement would not have occurred but for the combination; claims arising from customer modifications; claims arising from customer-provided data or instructions; and claims arising from use after the vendor delivered an infringement notice with a workaround. These are defensible carve-outs in any standard SaaS deal. The drafting question is how far they reach.
The combination-claim carve-out
The combination-claim carve-out is where most of the value leaks. A broadly drafted carve-out reads: Vendor has no obligation to indemnify Customer for claims arising from Customer's combination of the Service with any other product, software, or service not provided by Vendor. Read literally, this excludes the most common real-world infringement pattern for SaaS, where the vendor's product is alleged to infringe in combination with the customer's existing technology stack. Every CRM, analytics, marketing-automation, identity, or data-integration tool runs in combination with something. If the carve-out swallows that, the indemnity is decorative.
The narrowing language I push for: except where (a) the combination is contemplated by the Documentation, (b) the combination is with generally available enterprise software of a type that Vendor knows or should know the Service is commonly used with, or (c) the alleged infringement would have occurred from the Service alone. The third prong is the one vendors resist hardest. The drafting principle: if the vendor would still be on the hook had the customer never combined the product with anything, the combination is not the cause and the carve-out should not apply. Federal Circuit doctrine on apportionment in patent damages supports this framing, but the contract should not depend on it.
Customer-data carve-outs in the AI era
Vendors are pushing harder on customer-data carve-outs since 2024, citing the training-data exposure model from the AI cases. The reasoning is that if a customer uploads infringing training data, the vendor should not be liable for what comes out of the model. The reasoning is correct in principle and overdrawn in practice.
I separate two scenarios. In the first, the customer is providing inputs that the model is using to generate outputs for the customer's own benefit. If the customer has not warranted that those inputs are clean, a carve-out for customer-data-driven claims is appropriate. In the second, the customer is using the vendor's standard, pretrained model on customer prompts, and the alleged infringement is that the model's outputs reproduce someone else's copyrighted text. That is a vendor-side training-data problem. A customer-data carve-out should not reach it.
I draft the carve-out as: Vendor has no obligation to indemnify Customer for claims to the extent arising from (i) Customer's use of Customer Materials that themselves infringe a third party's intellectual property rights, or (ii) Customer's training, fine-tuning, or customization of the Service using Customer Materials, but Vendor remains responsible for claims arising from the Service's base model and any pretrained components provided by Vendor. Most sophisticated vendors will accept that split because it tracks how their actual risk maps to their actual conduct.
Remedies in lieu of indemnification
The other quiet exclusion is the remedies-in-lieu clause. Vendor's first draft typically allows the vendor to (a) procure for the customer the right to continue using the service, (b) modify the service so it is no longer infringing while remaining substantially equivalent, or (c) terminate the service and refund prepaid fees for the unused portion of the subscription term. Option (c) is the leak. A pro-rated refund of a year's fees is not a remedy for a customer whose business has migrated onto the platform and cannot exit on thirty days' notice.
My pushback: option (c) is available only if (a) and (b) are commercially unreasonable, and even then the refund is calculated to include reasonable transition costs documented by the customer. For mission-critical platforms, I add a transition-services obligation: the vendor must continue to provide the service for a transition period of six to twelve months at the post-termination price to permit orderly migration. The vendor will resist this. The customer is paying for it twice if they accept the bare refund.
Liability cap interplay
The last drafting point. Standard SaaS contracts cap liability at twelve months of fees paid. The customer wants the IP indemnity to be uncapped or capped at a multiple of the standard cap. The vendor wants it capped at the standard cap or, at most, at the same cap with a super-cap for IP-specific exposures. The right answer depends on deal size, customer size, and how much risk the customer can self-insure. For most mid-market customers, I aim for the IP indemnity to sit outside the general cap and inside a defined super-cap that is at least three to five times the annual fees, with a willful-misconduct carve-out that uncaps entirely.
The drafting trap: a general "carve-outs to the cap" clause that lists "IP indemnification" without specifying a separate IP-specific cap. That language reads as uncapped to a plaintiff and read as standard-cap-by-default to a defendant. Resolve the ambiguity on the front end. Specify the IP cap separately.
How I would pressure-test the clause before signing
The clause is fit for purpose if, applied to a hypothetical patent troll demand premised on the standard product used in a standard customer environment, the vendor would defend and pay through trial without invoking any of the carve-outs. If the vendor's lawyer can construct a colorable carve-out argument against that hypothetical, the language is too loose. Tighten the combination clause, narrow the customer-data clause, and reset the remedies-in-lieu mechanic. Recent infringement-claim activity in the AI-coding-assistant and AI-image-generation spaces (the Doe v. GitHub line and the Andersen v. Stability AI line) is unsettled enough that any indemnity which depends on those carve-outs surviving litigation is, in my view, a coin flip. I would rather have the language clear up front.
Negotiating a SaaS indemnity right now?
If you are working through a SaaS IP indemnity in either direction and want a written redline with the carve-out positions I would take, email me at owner@terms.law with the current draft and a brief note on which side you are on.
Sergei Tokmakov, Esq., CA Bar #279869. This memo is attorney commentary on legal questions and is not legal advice. Reading it does not create an attorney-client relationship. Past matter outcomes depend on facts and the responding party; nothing here is a prediction of result.