Checklist · Technology

Reviewing a Software License Agreement: A Practical Checklist

Type
Checklist
Jurisdiction
National
Date
2024-09-11
Topic
Technology

Most software license agreements bury the real risk in three unremarkable clauses: a liability cap the size of one quarter's fees, a data license that lets the vendor "improve" its products with your uploaded information, and an audit right that reprices overage at list. This checklist gives a reviewer a repeatable order of attack — context first, then the license grant and its metric and audit rights, then service levels, data rights, IP and open source, warranties, indemnification, and the limitation of liability with its carve-outs, and finally term and bankruptcy continuity. Each phase pairs checkboxes with the reason the clause matters, the good-acceptable-dangerous spectrum, and the authority that gives it teeth (Vernor, Adobe, MDY, ProCD, Specht, Nguyen, UCC §§ 2-316 and 2-719, 11 U.S.C. § 365(n), and Mission Product). Worked hypotheticals show how the same clause can be a deal-breaker in one transaction and background noise in another. The goal is not to read every word with equal care but to find the words that carry the money.

Reviewing a Software License Agreement: A Practical Checklist

Technology > Contract Review | Published 11 September 2024 - Updated 12 October 2024 | UpLaw - uplaw.us

A software license review is a triage exercise, not a proofreading pass. This checklist orders the work so that the clauses controlling money and continuity — the grant and its metric, the data license, the liability cap and its carve-outs, and the bankruptcy escape hatch — get the scrutiny they deserve, and the boilerplate gets the glance it deserves.

Keywords: software license agreement review, SaaS agreement, license grant scope, license metric, software audit clause, service level agreement, data rights, AI training data, IP indemnification, limitation of liability, liability cap carve-outs, warranty disclaimer, UCC 2-719, source code escrow, Section 365(n), clickwrap enforceability, anti-assignment, open source SBOM, vendor contract review

A vendor's paper arrives on a Thursday with a note that the business needs it signed by Monday, because the sales rep's quarter closes and the discount evaporates at month-end. Forty pages, single-spaced, defined terms in title case, three schedules and an order form on top. Somewhere in there is a clause capping the vendor's total liability at the fees paid in the trailing twelve months; a clause granting the vendor a license to your uploaded data "to operate, maintain, and improve its products and services"; and an audit clause that lets the vendor inspect your usage and invoice any overage at "then-current list prices," which happen to be triple the rate you just negotiated. None of the three is bolded. None is labeled dangerous. Each one decides what happens if the deal goes wrong.

Reviewing a license well is not about reading every word with equal attention — a discipline that guarantees you will spend your energy on the notices clause and run out of it before the indemnity. It is about knowing which words carry the risk, what those words are supposed to say, and what to do when they say something else. The order of the work matters as much as the substance, because the same provision can be a deal-breaker in one transaction and genuine background noise in another. A liability cap of one month's fees is a scandal for the platform that runs your payroll and a rounding error for the browser plug-in that formats your calendar invites. Context tells you which is which, so context comes first.

One framing point reorganizes how you read everything that follows. Almost no commercial software is sold. It is licensed, and it is licensed precisely to keep the customer a licensee rather than an owner. An owner of a lawful copy can resell, lend, or transfer it under the first-sale doctrine, 17 U.S.C. § 109; a licensee cannot, because the license withholds the title that would trigger the doctrine. In Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010), the Ninth Circuit blessed this arrangement, holding that a user is a licensee rather than an owner where the agreement (1) specifies that it grants a license, (2) significantly restricts the user's ability to transfer the software, and (3) imposes notable use restrictions. The sharp edge for a reviewer is what follows: exceeding the scope of a copyright license is not merely a breach of contract, it can be copyright infringement. Adobe Systems Inc. v. One Stop Micro, Inc., 84 F. Supp. 2d 1086 (N.D. Cal. 2000), held that out-of-scope distribution was infringement as a matter of law, which unlocked statutory damages, attorney's fees, and injunctive relief that a bare contract claim would never reach. Read the grant with that consequence in mind. For the conceptual background on why licensing displaced sale in the software economy, see How Software Licensing Works: An Overview and the clause-level map in Anatomy of a Software License Agreement: A Comprehensive Guide.

How to Read This Checklist

Work the phases in order. Phase 1 sets the stakes and tells you how hard to read the rest. Phase 2 defines what you are actually buying and how the vendor will measure and enforce it. Phases 3 through 5 allocate operational and legal risk — uptime, data, IP, and warranties. Phase 6 is where the money lands: the limitation of liability, the term and renewal machinery, and the provisions that decide whether you keep running when the vendor files for bankruptcy. Each phase gives you checkboxes to run down, a short explanation of why the clause matters, and the authority that gives it teeth. The checkboxes are the mechanics; the prose is the judgment. Skip the prose and you will tick every box and still miss the thing that hurts.

Two habits separate a fast, defensible review from a slow, anxious one. First, translate every clause into a concrete operational consequence before you decide whether to fight it — "no benchmarking" is abstract until you remember your engineering team publishes performance comparisons, at which point it is a live problem. Second, assign a negotiation priority to each issue as you go, so that when the business asks "what are the three things we cannot sign," you already know. A review that produces a flat list of forty issues is a review the business will ignore; a review that produces three deal-breakers, six should-fixes, and thirty-one acceptables is a review that closes.

Phase 1 — Context Before Clauses

  • [ ] Identify the deployment model: SaaS, on-premise, or hybrid, because it decides which clauses even matter.
  • [ ] Gather the business facts: total contract value (annual and over the full term), business criticality, seat or user count, data sensitivity, integration dependencies, expected duration, alternatives considered, and how much time pressure is real versus manufactured.
  • [ ] Identify every regulatory regime the data touches and confirm the required addendum exists: HIPAA (a business associate agreement under 45 C.F.R. § 164.504(e)); GDPR (an Article 28 data processing agreement plus a lawful transfer mechanism); CCPA/CPRA ("service provider" terms under Cal. Civ. Code § 1798.140); and, as applicable, PCI-DSS, GLBA, FERPA, and FedRAMP.
  • [ ] Confirm the agreement is even enforceable as written: a negotiated, signed order (good) versus a click-through order form layered on online terms the vendor reserves the right to change unilaterally (a structural problem).
  • [ ] Calibrate effort: maximum scrutiny for high-value or high-sensitivity deals; a light, checklist-only pass for a low-value, low-sensitivity tool.

Where the software runs and where the data lives determines which provisions carry weight, and getting this wrong wastes the whole review. In a SaaS deal, the contract is a services contract wearing license clothing. The customer never possesses a copy; it receives a right to access a system the vendor hosts and operates. The thin "right to access and use" grant is close to irrelevant, and the money moves to uptime commitments, data ownership, security, and exit. On-premise inverts the emphasis: the customer installs and runs copies on its own machines, so the license grant, the copy counts, the maintenance terms, and the audit and true-up mechanics dominate, while uptime service levels are largely beside the point. A hybrid deal — hosted service plus a downloadable agent or connector — carries both sets of risks, and reviewers routinely miss the downloaded-component license because the deal "felt like SaaS." For the full taxonomy of deal shapes, see The Landscape of Software Transactions: An Overview.

Regulated data drags a second contract into the transaction, and its absence is itself a red flag. A cloud vendor that stores or processes protected health information is almost always a business associate, not a mere "conduit," and the conduit exception is far narrower than vendors like to claim — it covers transient transmission (think a courier), not storage or processing. Without a compliant business associate agreement, the covered-entity customer is exposed under the HIPAA rules at 45 C.F.R. Parts 160 and 164, and the vendor's blithe assurance that it is "HIPAA compliant" means nothing without the paper. The mechanics of business associate status, the conduit exception, and required agreement terms are worked out in HIPAA in the Cloud: Business Associates, BAAs, and Protecting ePHI. Where personal data leaves the European Economic Area, confirm the transfer mechanism is real and current — Standard Contractual Clauses backed by a transfer impact assessment, or reliance on the EU-U.S. Data Privacy Framework — because a European regulator will not accept "the servers are in Virginia" as an answer. The post-Schrems II framework is mapped in Moving Personal Data Out of the EU After Schrems II: SCCs and Transfer Impact Assessments, and the broader governance picture in Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork.

Enforceability deserves a hard look before you spend an hour on substantive terms, because a clause you cannot rely on is not worth negotiating. Courts routinely enforce clickwrap — an "I agree" button presented with the terms — because the user has manifested assent to terms reasonably communicated. ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), started this line in the shrinkwrap era, and the modern reasonable-notice standard is captured in decisions like Meyer v. Uber Technologies, Inc., 868 F.3d 66 (2d Cir. 2017). Browsewrap — terms reachable only through a hyperlink the user is never required to see — is a different animal. Courts refuse to enforce browsewrap where the user lacked reasonable notice and never manifested assent. Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002); Nguyen v. Barnes & Noble, Inc., 763 F.3d 1171 (9th Cir. 2014). The structural trap in enterprise deals is the "hybrid" order form: a signed order that incorporates online master terms the vendor may amend "from time to time" by posting a new version. That construction can leave the customer bound to terms it never read and cannot freeze. The fix is to attach the operative terms as an exhibit, fix them by version and date, and require mutual written agreement for any change.

Worked example. Meridian Health Analytics, a hospital-system vendor, sends a startup called Larkspur Clinics an order form for a patient-scheduling platform. The order form is two pages; it points to "the Terms of Service available at the Provider's website," which the vendor can revise at will. Larkspur's reviewer stops at the incorporation clause. Two problems surface before a single substantive term is read: the platform will handle protected health information but the packet contains no business associate agreement, and the governing terms are a moving target the vendor controls. The correct first moves are to demand a signed business associate agreement and to replace the "available at the website" reference with a specific, dated set of terms attached as Exhibit A. Everything else in the review is provisional until those two structural defects are cured.

Phase 2 — The License Grant, Its Metric, and the Audit Right

  • [ ] Map the grant's four questions against real-world use: what may be done (access, install, copy, modify, create derivative works), who may do it, where, and for what purpose.
  • [ ] Check the affiliates row: define "Customer" to include entities under common control, and add language expressly permitting internal reorganizations without re-licensing.
  • [ ] Check the contractors row: permit use by contractors and outsourcers acting on the customer's behalf and for its benefit.
  • [ ] Pin down the license metric — named users, concurrent users, seats, cores, instances, transactions, or tier — precisely enough that both sides will count the same way two years from now; specify whether read-only access, API calls, and service accounts count.
  • [ ] Translate each restriction — reverse engineering, decompilation, no sublicensing, no assignment, no service bureau, no benchmarking, no competitive use — into a concrete operational consequence and assign it a negotiation priority.
  • [ ] Flag the red flags: license tied to specific hardware, vague purpose limits, unilateral modification rights, ambiguous user counting, silent treatment of test/staging/development environments, and missing backup and disaster-recovery copy rights.
  • [ ] Review the audit clause: advance notice (at least 30 days), limited frequency (once a year is standard), scope limited to the licensed software, a self-certification option before an on-site inspection, overage priced at contract rates rather than list, a cure period, and a carve-out so that a good-faith usage dispute is not itself a material breach.

The grant is the spine of the agreement, and the discipline is to read it against your actual deployment rather than against an abstract ideal. Break it into four questions. What may be done captures the verbs — access, install, execute, copy, modify, create derivatives — and each verb you need but do not see is a gap. Who may exercise the rights is the affiliates-and-contractors problem, addressed below. Where covers territory, and for cloud services also the permitted geographies for data storage, which loops back to the transfer-mechanism question from Phase 1. For what purpose is the sleeper: a grant limited to "internal business operations" quietly forbids using the software to provide services to your own customers, which may be exactly your business model.

The affiliates and contractors rows cause more post-signing pain than any other part of the grant, because the harm surfaces during a reorganization or an outsourcing transition — moments when leverage is already gone. If "Customer" is defined as a single legal entity, then rolling the software into a newly formed subsidiary, or letting a managed-services provider operate it on your behalf, can breach the grant even though the same people are doing the same work on the same screens. The classic cautionary tale is SQL Solutions, Inc. v. Oracle Corp., 1991 WL 626458 (N.D. Cal. 1991), where a licensee's corporate restructuring was treated as a prohibited "transfer" of the license, notwithstanding that the software never left the corporate family. Define "Customer" to sweep in entities under common control, and add an express permission for internal reorganizations, so that a merger, a holding-company reshuffle, or a spin-out does not require the vendor's consent — and a re-purchase.

The metric is where audits are born. A "user" that is undefined is an invitation to a six-figure true-up two years later, because the vendor will count in whatever way maximizes the invoice — named individuals rather than concurrent seats, every service account and API key as a separate license, read-only viewers the same as full users. Nail the metric down so that both sides can run the count independently and reach the same number. And remember the stakes are not merely contractual: where usage genuinely exceeds the licensed scope, the Adobe logic converts overuse from a breach into potential copyright infringement, with the enhanced remedies that follow. This is why a sloppy metric is not a minor drafting nit; it is an uncapped, un-carved-out exposure hiding in a definitions section.

The restrictions deserve a translation pass, not a skim. Most are standard and fine, but each interacts with real operations and, in some cases, with law that the contract cannot fully override. Reverse-engineering and decompilation bars are usually acceptable, but they collide with two things a reviewer should know exist. First, U.S. copyright law recognizes a fair-use interoperability defense for decompilation undertaken to achieve interoperability with an independently created program. Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); see also the interoperability exception to the DMCA's anti-circumvention rules, 17 U.S.C. § 1201(f). Second, contracts can nonetheless waive that defense: in Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003), the Federal Circuit enforced a shrinkwrap prohibition on reverse engineering and held it was not preempted by the Copyright Act — though other courts, notably Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988), have found particular anti-copying license terms preempted. In the European Union, by contrast, the decompilation right for interoperability under Article 6 of the Software Directive (2009/24/EC) is non-waivable, so a global "no reverse engineering" clause is partly unenforceable against EU users regardless of what the contract says. The point for a reviewer is not to litigate these questions at the negotiating table but to know that a reverse-engineering bar is not a pure formality — it can foreclose a legitimate integration project, and its enforceability varies by forum. The line between a license condition (whose breach can be infringement) and a mere covenant (whose breach is only contract) is drawn in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010); which side of that line a given restriction falls on decides whether violating it risks statutory damages or only ordinary contract damages. The deeper treatment of the covenant-versus-condition distinction and how to negotiate the grant lives in Software License Agreements: Key Terms and How to Negotiate Them.

The audit clause is the enforcement engine bolted to the metric, and its defaults run entirely in the vendor's favor unless you change them. The single most expensive default is overage priced at "then-current list price." List price is a fiction that exists to be discounted; a customer who negotiated 60% off list and then trips an audit finding gets billed for the shortfall at the undiscounted rate, effectively paying a penalty of more than double the real price for the same seats. Fix it to your contract rate. Then build in the procedural guardrails: at least thirty days' notice, no more than one audit per year absent cause, scope limited to the licensed software rather than a fishing expedition through your whole environment, a self-certification option that lets you report your own count before anyone shows up, a cure period to true up before penalties attach, and — critically — a provision that a good-faith dispute over usage does not by itself constitute a material breach. Without that last carve-out, the vendor can treat a contested audit finding as grounds to terminate and shut off a system your business depends on, which is coercion dressed as contract enforcement.

Worked example. Larkspur Clinics licenses an on-premise imaging tool metered by "concurrent users." The order says fifty. Over two years Larkspur grows, adds a radiology partner practice, and stands up a staging environment that mirrors production. An audit clause lets the vendor inspect annually and bill overage at list. The vendor's audit counts (a) every named account that ever logged in, not concurrent sessions; (b) the partner practice's clinicians, who are affiliates the grant never mentioned; and (c) the staging environment as a second production instance. The invoice: 180 "users" at undiscounted list, a mid-six-figure number. Every dollar of it traces to three drafting failures a Phase 2 review would have caught — an undefined metric that let the vendor swap "concurrent" for "named," an affiliates gap, and silence about non-production environments. The lesson is not that Larkspur used the software wrongly; it used it the way any growing practice would. The contract simply failed to describe that use as permitted.

Phase 3 — Service Levels, Support, and On-Premise Continuity

  • [ ] Read the SLA's three parts together — the uptime commitment, the exclusions, and the remedy — because a "99.9%" promise with unlimited vendor-defined "maintenance windows" excluded is not a 99.9% promise.
  • [ ] Translate the uptime percentage into wall-clock downtime (99.9% ≈ 8.8 hours per year; 99.95% ≈ 4.4 hours; 99.99% ≈ 53 minutes; 99.999% ≈ 5 minutes) and confirm the measurement period and calculation method.
  • [ ] Fight for a termination-for-chronic-failure right (for example, a miss in three consecutive months or four in a rolling year) and make sure service credits are not the sole remedy for a material outage.
  • [ ] In the support terms, distinguish a response commitment from a resolution commitment, fill in the severity matrix, and flag every cell that reads "commercially reasonable efforts."
  • [ ] For on-premise software, confirm the version-support horizon, whether security patches are included or sold separately, and the end-of-life terms.
  • [ ] For mission-critical on-premise deployments, negotiate source-code escrow with verified, current deposits and operational release triggers — not bankruptcy alone.

Service levels are where vendors win the headline number and take it all back in the fine print. The uptime commitment, the exclusions, and the remedy are three parts of one machine, and reading any of them alone produces a false picture. Uptime percentages sound precise but are only as good as their exclusions: if scheduled maintenance, "emergency" maintenance, third-party failures, and force-majeure events are all carved out of the availability calculation, a nominal "99.9%" can coexist with far more real downtime than the number implies. Translate the percentage into hours before you react to it — 99.9% is nearly nine hours of permitted downtime a year, which is a full business day your customer-facing app can be dark without breaching the SLA. Then read how availability is measured: over what period, in what increments, and whether partial degradation (the system is up but crawling) counts as downtime at all.

The remedy is usually the weakest link. Standard SLAs offer service credits — a percentage of the monthly fee refunded when uptime falls below the threshold — and those credits are almost always trivial relative to the business harm of an outage. A 10% credit on a monthly fee is cold comfort when a day-long outage costs you a day of revenue and a chunk of your customers' goodwill. Two moves restore real leverage. First, secure a right to terminate for chronic failure, so that a vendor which misses repeatedly hands you the exit rather than a string of small refunds; the threat of losing the account disciplines vendor behavior in a way that a capped credit never will. Second, make sure the service-credit remedy is expressly not the sole or exclusive remedy for a material-breach outage — otherwise the credit becomes a liability cap in disguise, converting even a catastrophic, negligent failure into a small refund. The interplay between service credits, exclusivity, and the broader liability cap is a recurring theme; the drafting-side view is in Anatomy of a Software License Agreement: A Comprehensive Guide.

Support terms hide a quieter trap: the difference between a promise to respond and a promise to resolve. A vendor that guarantees a one-hour response to a severity-one incident has promised only that a human will acknowledge your ticket within an hour — not that anything will be fixed. Resolution commitments are rare and worth pushing for on critical systems, but at minimum the severity matrix should be filled in with defined categories, defined response targets, and defined escalation paths, and every cell that reads "commercially reasonable efforts" should be flagged as an unenforceable aspiration rather than a commitment.

For on-premise software, continuity is the analog of uptime, and source-code escrow is the tool. The customer runs a compiled binary and cannot maintain, patch, or port software whose source it cannot see; if the vendor abandons the product, goes dark, or fails, the customer is stranded on frozen code. An escrow arrangement deposits the source with a neutral agent, to be released to the customer on defined triggers. The common drafting error is to make bankruptcy the only release trigger, which is both under-inclusive and legally fragile. It is under-inclusive because the more likely disasters — the vendor simply stops supporting the product, or is acquired by a competitor that sunsets it — are not bankruptcies. It is fragile because a release condition keyed solely to the licensor's bankruptcy risks treatment as an unenforceable ipso facto clause under Bankruptcy Code § 365(e)(1), which nullifies contract terms that modify rights "solely because of" a bankruptcy filing. Tie release to a cluster of operational triggers — failure to provide contracted support, discontinuation of the product, repeated uncured material breach — and require verification testing so the deposit is current and actually builds, rather than a one-time dump that no one has confirmed compiles. Escrow structures for hosted and hybrid deployments, including the harder problem of escrowing a running SaaS environment, are surveyed alongside the bankruptcy analysis in Phase 6.

Phase 4 — Data Ownership, Security, Breach, and Exit

  • [ ] Confirm the customer owns its Customer Data, including data derived from it, and that the vendor receives only a limited license to provide the service.
  • [ ] Scrutinize the vendor's data license: no use for the vendor's other products, no use to train AI or machine-learning models, no aggregation with competitors' data, no sale or sharing, and automatic termination of the license when the agreement ends.
  • [ ] Pin down any "anonymized and aggregated" carve-out with a real de-identification standard, a contractual bar on re-identification, and an opt-out.
  • [ ] Demand specific, auditable security: encryption in transit (TLS 1.2 or higher) and at rest (AES-256 or equivalent), access controls, multi-factor authentication, and a SOC 2 Type II report rather than a Type I.
  • [ ] Read the breach-notification clause for a hard deadline ("without undue delay and in any event within 72 hours of discovery") and confirm breach-related costs are carved out of the liability cap.
  • [ ] Secure exit rights before signing: export in a standard, usable format (CSV, JSON, or a documented API), a 30-to-90-day post-termination access window, capped transition-assistance rates, and a certificate of data destruction.

For any hosted solution, the data provisions are the contract. The customer is handing its information — sometimes its most sensitive information — to a third party, and the terms governing what that party may do with it, how it will protect it, what happens when it fails, and how the customer gets its data back are the whole ballgame. Start with ownership: the agreement should state plainly that the customer owns Customer Data, including data derived or generated from it, and that the vendor acquires only a limited, terminable license to use that data as necessary to provide the service. Vendors sometimes claim ownership of "derived" or "usage" data, which can quietly hand them the analytics built from your business, so read the derived-data line as carefully as the primary grant.

The vendor's data license is where the real fight is, and the language has migrated. For years the phrase to hunt was "to improve our products and services" — an open-ended grant that lets the vendor mine your data for its own benefit. That phrase is now the hook vendors cite for training artificial-intelligence models on customer data, which is a categorically larger concession: a model trained on your data can encode and regurgitate it in ways ordinary "product improvement" never contemplated, and the resulting model does not disappear when your contract ends. Insist on an explicit, standalone provision on model training rather than accepting a buried definition, and default it to "no." If the vendor genuinely needs some training right, negotiate it deliberately — scoped, de-identified, opt-in, and separately consented — rather than letting it ride in on a boilerplate improvement clause. The legal terrain here is unsettled and moving quickly; the litigation shaping it is tracked in Generative AI on Trial: Copyright Infringement Claims After the New York Times and Getty Suits, and the broader risk map in Key Legal Issues in Artificial Intelligence: A Comprehensive Guide for Business and Counsel. The related problem of terms-of-service restrictions on data harvesting — the mirror image, where you are the one whose scraping or ingestion is restricted — is analyzed in Web Scraping and the Law After hiQ v. LinkedIn: Where the CFAA, Contract, and Copyright Collide.

"Anonymized and aggregated" deserves its own scrutiny, because it is the fallback vendors offer when you strike the training language, and it can give back much of what you took away. True de-identification is a technical standard, not a label; poorly anonymized data is routinely re-identified. If the agreement permits use of anonymized, aggregated data, tie it to a recognized de-identification methodology, add a contractual prohibition on any attempt to re-identify, and secure an opt-out for sensitive datasets. The data-minimization principles behind these limits — collect and retain only what the purpose requires — are developed in Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork.

Security clauses must commit to specifics or they commit to nothing. "Industry-standard security" is not a standard; it is a phrase. Insist on named controls — encryption in transit and at rest with named protocols, role-based access controls, multi-factor authentication, logging and monitoring — and on independent verification. The verification distinction that matters is SOC 2 Type II versus Type I: a Type I report describes the vendor's controls at a single point in time, essentially a snapshot of what the vendor says it does, while a Type II report reflects testing of whether those controls actually operated effectively over a period of months. A vendor that offers only a Type I is offering a promise; a Type II is closer to evidence. The operational side of vendor security review — how a customer builds this into a repeatable program — is laid out in Standing Up a Privacy Compliance Program: A Practical Checklist.

The breach-notification clause is where security failures meet the liability architecture, and the two must be read together. A "prompt" or "reasonable" notice window is meaningless; specify a hard deadline — "without undue delay and in any event within 72 hours of discovery" mirrors the GDPR Article 33 standard and is a defensible anchor. But notice timing is the smaller half of the problem. The larger half is whether breach-related liability sits inside or outside the liability cap, which is a Phase 6 question you should preview here: if a data-security failure is capped at twelve months' fees, then a vendor whose negligence exposes a million customer records owes you, at most, a refund of last year's subscription — a sum wildly disproportionate to the notification costs, regulatory exposure, and reputational harm you will actually bear. Carve data-security breaches out of the cap, or the security clause is decorative.

Finally, secure exit rights while you still have leverage, which is before signing, not after the relationship has soured. Lock-in is the most underappreciated risk in any hosted deal: the more your operations depend on the vendor, the less you can afford to leave, and the vendor knows it. Negotiate, up front, the right to export your data in a standard and usable format — not a proprietary blob that only the vendor's tools can read — with a defined post-termination window (thirty to ninety days) during which you retain access to retrieve it, transition-assistance obligations at capped rates, and a certification that the vendor has destroyed its copies when you are done. A vendor that resists reasonable exit terms is telling you something about how it plans to treat you once you cannot leave.

Phase 5 — Intellectual Property, Open Source, Warranties, and Indemnification

  • [ ] Confirm the IP ownership allocation — vendor owns the software, customer owns its data, no implied licenses — and address ownership of any custom development and the assignment of feedback (cap feedback to what is "voluntarily provided" and avoid joint ownership).
  • [ ] Require open-source assurances: a software bill of materials (SBOM) on request, a warranty that open-source components impose no copyleft obligation on the customer, vendor responsibility for open-source compliance, and indemnity coverage for open-source claims.
  • [ ] Read the express warranties and the disclaimers together; confirm a core warranty that the software will perform materially in accordance with its documentation, and keep a copy of the documentation as it existed at signing.
  • [ ] Confirm that disclaimers of the implied warranties of merchantability and fitness for a particular purpose are conspicuous (capitals or bold), and resist letting non-infringement slide onto the disclaimer list.
  • [ ] Review the IP indemnity: defense and indemnification obligations, covered claim types (patent, copyright, trademark, trade secret, open source), carve-outs tested against causation and fault, and remediation options where any termination-and-refund fallback is substantial rather than nominal.
  • [ ] Narrow the customer indemnity so the customer never indemnifies the vendor for the vendor's own handling of Customer Data.

Intellectual-property ownership in a license is usually straightforward at the top line — the vendor keeps the software, the customer keeps its data — but two side doors let value leak out. The first is custom development: if the vendor builds features, integrations, or configurations specifically for you, who owns them? Silence typically defaults ownership to the vendor, which can then resell your investment to your competitors. Decide this deliberately. The second is the feedback clause, which commonly assigns to the vendor a perpetual, royalty-free right to use any "feedback, suggestions, or ideas" you provide. That is often acceptable for casual suggestions, but drafted broadly it can sweep in genuinely valuable input; cap it to feedback "voluntarily provided" and avoid any structure that leaves you jointly owning improvements you helped design. The layered ways software is protected — copyright, patent, trade secret, and contract, each doing different work — are mapped in How the Law Protects Software: Copyright, Patents, Trade Secrets, and Contract Rights.

Open source deserves its own line of inquiry, and the common instinct about it is backwards. People treat open-source components as low-risk because they are "free," but open-source licenses are enforceable conditions on a copyright license, and violating them is potential copyright infringement, not a mere breach of a gratuitous promise. The Federal Circuit made this explicit in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), holding that the terms of an open-source license (there, the Artistic License) function as conditions whose violation can support an infringement claim. The practical risk to a licensee is copyleft: a strong copyleft license such as the GPL can, in some architectures, require that software combined with the covered component be distributed under the same open terms — which for a proprietary product is a catastrophe. Require the vendor to deliver a software bill of materials on request, to warrant that no open-source component imposes copyleft obligations on the customer's use, to take responsibility for its own open-source compliance, and to indemnify open-source-based claims. The full risk taxonomy — copyleft, derivative works, license incompatibility, SBOMs, and enforcement trends — is developed in Open Source Licensing Traps in Enterprise Software: Mapping the Hidden Risks and the operational controls in Open Source Software Compliance: A Practical Checklist.

Warranties and their disclaimers are two halves of one thought and must be read together. On the express side, the core warranty worth having is that the software will perform materially in accordance with its documentation for a defined period; that warranty is only as good as the documentation it references, so preserve a copy of the documentation as it existed at signing, because the vendor controls the live version and can quietly narrow it. On the disclaimer side, the implied warranties of merchantability and fitness for a particular purpose can be excluded — but only if the disclaimer is conspicuous, meaning presented so that a reasonable person ought to have noticed it. Article 2 of the Uniform Commercial Code requires conspicuousness for these disclaimers, UCC § 2-316, and defines "conspicuous" at § 1-201(b)(10); a disclaimer buried in plain-type body text may not survive, which is why vendors set them in capitals. Two drafting points repay attention. First, whether the UCC even governs a software license is itself contested — courts split on whether software is a "good," a service, or a license sui generis — but reviewers should assume UCC principles inform the analysis and draft to satisfy them. Second, watch the disclaimer list for non-infringement: a vendor that disclaims the implied warranty against infringement is trying to shift to you the risk that its own product infringes someone else's IP, which is precisely the risk the IP indemnity is supposed to carry. Push it off the list.

The IP indemnity is one of the most valuable protections a customer can obtain, for a simple reason: it covers a risk the customer cannot evaluate and the vendor can. You did not write the code; you have no way to know whether it infringes a third party's patent or copyright, and no practical means to defend a suit about code you cannot see. The vendor built it and is far better positioned to assess and bear that risk. A strong indemnity commits the vendor both to defend the customer against covered claims and to indemnify it for the results, across the relevant claim types — patent, copyright, trademark, trade secret, and open-source claims. Read the carve-outs with suspicion, because they are where vendors claw back what the indemnity gives: exclusions for the customer's modification of the software, combination with other products, or use outside the license are fair only to the extent the customer actually caused the problem, so tie each carve-out to causation and fault. And scrutinize the vendor's remediation options — typically, the vendor may procure a license, modify the product, or terminate and refund. If the refund is nominal (a pro-rated slice of prepaid fees), the "remedy" is really the vendor's escape hatch, leaving you to rip out an infringing system on your own dime; insist that any termination-and-refund option return something proportionate to your investment and switching cost. Finally, read the customer indemnity in the mirror: the customer should never indemnify the vendor for the vendor's own handling of Customer Data, a reversal vendors sometimes slip in through a broad "your data" indemnity. The mechanics of scoping indemnities — defense obligations, caps, baskets, and the fault-based carve-outs — carry over from general commercial practice and are worth cross-checking against a dedicated indemnification framework.

Worked example. Vantage Cloud licenses an analytics platform to Larkspur. Buried in the components is an open-source charting library under a strong copyleft license, and the vendor's warranty disclaims, in plain type, "all warranties including non-infringement." A competitor later asserts that the charting library infringes its patent and sues Larkspur, the visible deployer, rather than the vendor. Larkspur turns to the contract and finds: no SBOM (so it did not know the library was there), a non-infringement disclaimer (so no implied protection), an IP indemnity riddled with carve-outs (one of which the vendor argues applies because Larkspur "combined" the platform with its own dashboards), and a liability cap that would swallow any recovery even if the indemnity applied. Each of these is a Phase 5 checkbox that, unticked, converts a vendor's coding decision into the customer's lawsuit. A review that demanded an SBOM, struck non-infringement from the disclaimer, tied the combination carve-out to actual causation, and carved the IP indemnity out of the cap would have kept this risk where it belongs — with the party that chose the library.

Phase 6 — Limitation of Liability, Term, and Bankruptcy Continuity

  • [ ] Read the cap structure carefully: the amount, whether it is a multiple of fees, the measurement period (trailing twelve months versus total contract value), and whether it is per-claim or aggregate.
  • [ ] Confirm the consequential-damages exclusion and recognize that it strips your most significant losses — lost profits, business interruption, lost data — from any recovery.
  • [ ] Negotiate the carve-outs that should sit outside both the cap and the exclusion: the IP-infringement indemnity, confidentiality breaches, data-security breaches, gross negligence and willful misconduct, and the customer's payment obligations.
  • [ ] Confirm that any "repair or replace" warranty remedy has a genuine cure obligation and a fallback, so it cannot "fail of its essential purpose" (UCC § 2-719(2)), and that the consequential-damages exclusion is drafted as expressly independent of that remedy.
  • [ ] Review the term, the renewal mechanics (caps on price increases, defined renewal pricing, and a generous notice window before auto-renewal), and the termination triggers and their effects.
  • [ ] Confirm the agreement acknowledges the customer's 11 U.S.C. § 365(n) rights, treats any escrow as a "supplementary agreement," and does not waive these bankruptcy protections.

If you read only one provision in the entire agreement, read the limitation of liability, because it sets the maximum financial consequence to the vendor of breaking every promise it made — and therefore how seriously the vendor takes those promises. A cap is a statement about incentives: a vendor whose worst-case exposure is one quarter's fees has little economic reason to invest in getting the hard things right. Start by understanding the cap's shape. The amount is often expressed as a multiple of fees, and the period matters enormously: a cap of "fees paid in the trailing twelve months" on a contract that ramps over time can be a fraction of "total fees paid under the agreement," which is itself a fraction of the harm a failure can cause. Note whether the cap is aggregate (one pool for all claims over the life of the deal) or per-claim, and whether the same cap purports to limit the vendor's indemnity obligations, which is a common overreach.

Then find the consequential-damages exclusion, and understand what it takes from you. A mutual waiver of indirect, incidental, special, and consequential damages sounds even-handed, but it is not symmetrical in effect, because the customer's most serious potential losses — lost profits, business interruption, the cost of reconstructing corrupted data — are exactly the categories the exclusion labels "consequential" and removes. After a consequential-damages waiver and a fees-based cap, a vendor that destroys your data through gross negligence may owe you nothing beyond a partial refund. The UCC permits sophisticated commercial parties to allocate risk this way — § 2-719(3) provides that limitation of consequential damages for commercial loss is not prima facie unconscionable — so the exclusion is generally enforceable between businesses. The lever is not to attack the exclusion wholesale but to carve specific obligations out of it. For a primer on what "consequential" and "direct" damages actually mean and how courts draw the line, see Contract Damages: How Courts Make the Injured Party Whole.

The carve-outs are where the liability section is won or lost. Certain obligations should sit outside both the cap and the consequential-damages exclusion, because capping them defeats their purpose: the IP-infringement indemnity (a capped indemnity may not cover the very judgment it exists to absorb), confidentiality breaches, data-security breaches, gross negligence and willful misconduct, and the customer's own payment obligations (which vendors always carve out for themselves — reciprocity is the argument for carving out the ones that protect you). The data-security carve-out is, in many deals, worth more than every pricing concession combined. With it, a breach that exposes your customers' data can fall outside the cap entirely, and the vendor faces liability proportionate to the harm; without it, that same breach is capped at twelve months' fees, and the vendor's negligence becomes your loss. When you triage a review into three deal-breakers, this carve-out belongs on the list far more often than the headline price does.

Two UCC mechanics deserve a closer look because they interact in a way that decides whether your remedy is real. Many licenses provide an "exclusive" or "sole" remedy for breach of the express warranty — typically "repair or replace." Section 2-719(1) permits parties to agree on such a limited remedy, but § 2-719(2) provides that where "an exclusive or limited remedy fails of its essential purpose," the buyer may pursue the ordinary remedies the Code otherwise supplies. In plain terms: if the vendor's only promised fix is to repair the software, and the vendor cannot or will not actually repair it, the exclusive-remedy clause collapses and the full range of remedies reopens — the classic scenario in Chatlos Systems, Inc. v. National Cash Register Corp., 635 F.2d 1081 (3d Cir. 1980), where a computer system that never worked as promised defeated the seller's attempt to hold the buyer to a limited remedy. But there is a sting in the tail: vendors respond by drafting the consequential-damages exclusion as independent of the limited remedy, so that even if "repair or replace" fails its essential purpose, the consequential-damages bar survives. Whether that independence holds is a question on which courts divide, and the outcome turns on the drafting. From the customer side, insist that the limited remedy include a real cure obligation and a meaningful fallback (a refund, a right to terminate) so it cannot fail in the first place; from either side, understand that the "fails of its essential purpose" doctrine and the consequential-damages exclusion are separate questions that must be drafted deliberately rather than left to a court to reconcile.

Term and renewal mechanics are where money leaks quietly over years rather than dramatically in a dispute. Auto-renewal is standard and usually fine, but read the machinery: the notice window to prevent renewal (a thirty-day window buried in a multi-year contract is a trap designed to catch you asleep; negotiate sixty or ninety days), whether renewal pricing is defined or left to the vendor's discretion (an undefined "then-current rates" renewal can spike 20% or more each cycle), and whether price increases are capped. On termination, read both the triggers (who can terminate, for what, with what cure period) and the effects — what happens to your data, your access, and your prepaid fees when the music stops, which loops back to the exit rights from Phase 4.

The last provision, and the one most often skipped, governs what happens if the vendor goes bankrupt — and it is more counterintuitive than reviewers expect. The starting problem is that a bankruptcy trustee can reject an executory contract, including a software license, which historically stripped the licensee of its rights. Congress fixed part of this for intellectual-property licenses by enacting 11 U.S.C. § 365(n), which lets a licensee of patents, copyrights, or trade secrets elect to retain its rights under the license notwithstanding the trustee's rejection — a direct legislative overruling of Lubrizol Enterprises, Inc. v. Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985), which had held that rejection extinguished the licensee's rights. The Supreme Court reached the same pro-licensee result for trademarks (which § 365(n) does not list) in Mission Product Holdings, Inc. v. Tempnology, LLC, 587 U.S. 370 (2019), holding that rejection is a breach, not a rescission, so the licensee keeps the rights the license conferred. For a reviewer, the drafting takeaways are concrete: confirm the agreement expressly acknowledges the customer's § 365(n) rights and does not purport to waive them, and confirm that any source-code escrow is characterized as an "agreement supplementary to" the license, which § 365(n) protects.

There is a crucial limit that reviewers of SaaS deals must internalize: § 365(n) protects the right to continue using licensed intellectual property, not the right to compel services. In a pure SaaS deal, the customer holds no copy and needs the vendor to keep the servers running; if the vendor rejects the agreement in bankruptcy, § 365(n) will not force it to continue hosting, because hosting is a service, not licensed IP. That gap is exactly why continuity planning for hosted software cannot rely on § 365(n) alone and must add operational tools — escrow of the code plus the deployment scripts and data, contractual rights to stand up a mirror environment, and negotiated transition assistance — so the customer can run the software itself if the vendor disappears. The § 365(n) election is a genuine protection for on-premise and code-in-hand deployments and a partial one for hybrids; for SaaS, it is a floor, not a solution.

Worked example. Larkspur runs its entire clinical workflow on Vantage Cloud's hosted platform. Vantage files for Chapter 11 and the debtor-in-possession rejects unprofitable contracts, Larkspur's among them. Larkspur's counsel reaches for § 365(n) — and discovers it buys little, because Larkspur licensed access to a service, not a copy of software it can run. What actually saves Larkspur, if anything does, is Phase-6 foresight: a source-code-and-data escrow with an operational release trigger ("provider ceases to provide the hosted service"), a contractual license to deploy the escrowed build in Larkspur's own cloud, and a data-export right exercisable on termination. Without those, § 365(n) is a statute that protects a right Larkspur never had — the right to use a copy — while the service it depends on goes dark. The lesson generalizes: match the continuity tool to the deployment model, and never assume a bankruptcy statute written for IP licenses rescues a services relationship.

Common Mistakes

  • Spending the review on price and rubber-stamping the risk architecture. A 10% discount negotiated over three weeks is cold comfort against an uncapped exposure the contract failed to carve out. The liability section deserves more attention than the price, not less.
  • Letting an ambiguous license metric slide. The undefined "user" you accept today is the six-figure audit true-up you meet in two years, priced at list. Define the metric so both sides count the same way.
  • Accepting a grant narrower than your real deployment. A grant that omits affiliates and contractors becomes a breach — or, under the Adobe logic, an infringement — during the reorganization or outsourcing you did not anticipate at signing.
  • Treating "improve our services" or "anonymized and aggregated" as boilerplate. That is how customers license their data for the vendor's AI models without ever deciding to. Make model training an explicit, separately negotiated term.
  • Settling for a SOC 2 Type I, a "prompt" breach-notice window, or service credits as the sole outage remedy. Each is the weak version of a protection that exists in a stronger form for the asking.
  • Leaving exit rights to negotiate after the relationship sours. Lock-in is leverage, and it all runs to the vendor once you depend on the system. Negotiate export, transition, and destruction terms before you sign.
  • Letting the liability cap swallow data-security, confidentiality, and IP-indemnity obligations. The carve-outs are the difference between a protection and a decoration.
  • Assuming § 365(n) protects a SaaS relationship. It protects the use of licensed IP, not the delivery of a service. Match the continuity tool to the deployment model.

A Note on Adjacent Deal Types

Not every software transaction fits the license mold this checklist assumes. Custom-development and agile-delivery engagements shift the questions toward acceptance, iteration, and IP ownership of work product, and are better reviewed against the framework in Contracting for Agile Software Development: Structuring Iterative Deals. Where the deal is really a data-sharing or confidentiality arrangement wearing a license label, the enforceability of the confidentiality obligations governs, and the drafting standards in Non-Disclosure Agreements for Technology Deals: Drafting for Enforceability and the clause-by-clause build in Building an Enforceable NDA Clause by Clause: A Practical Checklist apply. Patent-heavy licenses — where the value is a patent portfolio rather than a running program — carry their own doctrinal traps (exhaustion, misuse, post-expiration royalties) mapped in Building a Patent License Term Sheet: A Practical Checklist. And where post-sale control over software-enabled hardware is the issue, the tension between license restrictions and the right to repair is analyzed in The Right to Repair Reckoning: IP Limits on Post-Sale Product Control. Knowing which frame the deal really belongs in is itself part of the first pass.

Primary Authority

Related UpLaw Resources

Related Guides

Related Articles

Related Checklists

Related Toolkits

This checklist is general legal information, not legal advice. Software licensing and technology-transaction law vary by jurisdiction and continue to evolve, and the sample positions described here are illustrative rather than prescriptive. Consult qualified counsel to review any specific agreement.