Software License Agreement Review: A Complete Toolkit

Technology > Contract Review | Published 18 April 2026 - Updated 8 June 2026 | UpLaw - uplaw.us

A working system for reading a software license the way it will read back to you in a dispute: clause by clause, risk first, with the governing law attached to each judgment call and separate tracks for customers and vendors, SaaS and on-premise.

Keywords: software license agreement review, SaaS contract review, license grant scope, limitation of liability cap, IP indemnification, service level agreement, data rights, clickwrap enforceability, license audit true-up, source code escrow, auto-renewal, Section 365(n), UCC warranty disclaimer, data breach notification, vendor lock-in, enterprise software negotiation.

---

Picture the file that lands on the desk of a general counsel at a mid-sized company on the last week of the vendor's fiscal quarter. It is a master subscription agreement, thirty-eight pages, plus an order form, a data-processing addendum that arrived as a separate PDF, and a link to online "Service Terms" that the agreement incorporates by reference. Sales wants signatures by Friday because the discount lapses at quarter-end. Buried in that stack are three sentences that will govern everything if the relationship ever goes wrong: one caps the vendor's total liability at the fees paid in the trailing month, one grants the vendor a license to use uploaded data "to develop and improve its products," and one lets the vendor audit usage and invoice any excess at "then-current list prices." None of the three is bolded. None announces itself. Each is a live grenade with the pin loosely seated.

Reviewing a software contract well is not a reading-comprehension exercise where every sentence gets equal weight. It is triage. The skill is knowing which words carry the money and the control, what those words are supposed to say, and what to do when they say something worse. That is the job this toolkit is built for. The checklists give you a structure disciplined enough that nothing material slips by; the prose around them supplies the judgment a checkbox cannot, explaining what each provision does, why it exists, whom it protects, and how the market-standard version differs from the version that should stop you cold.

This resource is the operational sibling of the narrative treatment in Software License Agreements: Key Terms and How to Negotiate Them. If you want the long-form theory of why an indemnity is built the way it is, start there or with the clause-anatomy walkthrough in Anatomy of a Software License Agreement: A Comprehensive Guide. If you want to sit down with a live contract and work through it methodically, you are in the right place, and you may want the leaner companion order-of-attack in Reviewing a Software License Agreement: A Practical Checklist. For the wider deal terrain—where licenses sit alongside subscriptions, development agreements, and reseller channels—see The Landscape of Software Transactions: An Overview.

First Principles: You Are Licensing, Not Buying—and That Changes Everything

One structural fact reorganizes how you read the entire document, so fix it in your mind before the checklists begin. Almost no commercial software is sold. It is licensed. That is not a semantic quibble; it is the load-bearing wall of the whole agreement. When you buy a physical object, the first-sale doctrine of copyright law, 17 U.S.C. § 109, lets you resell it, lend it, or destroy it with nobody's blessing. Vendors draft around that outcome on purpose. They want you to remain a licensee rather than an owner, because a licensee is bound by the contract's restrictions and an owner largely is not. The Ninth Circuit endorsed the architecture in Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010), holding that a software user is a licensee rather than an owner when the agreement (1) states that the vendor retains title and grants only a license, (2) significantly restricts the user's ability to transfer the copy, and (3) imposes notable use restrictions. Every restriction you are about to scrutinize borrows its enforceability from that single choice. The conceptual case for why software is licensed rather than sold is developed in How Software Licensing Works: An Overview.

The architecture has a sharp downstream consequence worth internalizing now. Because the grant is a conditional license rather than a sale, using the software beyond the scope of the grant is not merely a breach of contract—it can be copyright infringement. In Adobe Systems Inc. v. One Stop Micro, Inc., 84 F. Supp. 2d 1086 (N.D. Cal. 2000), a reseller authorized to distribute only to "Educational End Users" sold to ordinary customers, and the court held those out-of-scope sales were copyright infringement as a matter of law, not just contract breach. The distinction is not academic. Infringement drags in statutory damages, attorneys' fees, and injunctive relief that a plain breach claim never delivers. That is precisely why a grant narrower than your real deployment is dangerous in a category all its own, and why the license grant—not the liability cap, glamorous as it is—is where a careful review actually begins. (The line between a contractual covenant, whose breach yields only contract remedies, and a condition on the license, whose breach can trip infringement, is one of the most consequential in the field; the map of how copyright, patent, trade secret, and contract each protect code is in How the Law Protects Software: Copyright, Patents, Trade Secrets, and Contract Rights.)

---

Part 1: Before You Read a Word—Setting the Terms of Your Own Review

Seasoned reviewers do something that looks like procrastination: they spend the first half hour not reading the contract. They gather context. The reason is that an identical clause can be a deal-breaker in one transaction and a rounding error in another, and you cannot tell which without knowing the business stakes, the deployment model, and the regulatory environment. A liability cap of one year's fees is a non-event for a $1,800 design tool and a five-alarm problem for the platform that runs your billing. Context tells you where to spend attention you cannot spend everywhere.

Checklist 1.1: Identify the Deployment Model

The single most orienting question is where the software runs and where the data lives, because that dictates which provisions even matter. Three basic models pull your scrutiny in different directions.

• In a SaaS deployment (software as a service), the code runs on the vendor's infrastructure and you reach it over the network; your data usually sits in the vendor's cloud. The contract is a service agreement wearing license clothing, and the provisions that actually protect you govern uptime, data ownership, security, and your ability to extract your data and leave. The license grant itself—typically a thin "right to access and use"—barely matters, because you never hold a copy.
• In an on-premise deployment, the vendor ships software you install and operate on your own servers, and you hold the data. Here the classic grant questions dominate: what you may do with the copy, how many copies, on which machines, and whether you receive the maintenance and updates that keep it alive. Uptime commitments are largely beside the point because the vendor does not run the system—you do.
• A hybrid deployment blends the two (on-premise software that phones a cloud service, or a cloud product with a downloadable agent). It demands that you review both sets of provisions and, above all, confirm they are internally consistent with each other.

Diagnostic question	SaaS	On-Premise	Hybrid
Runs on the vendor's infrastructure?	Yes	No	Yes
Runs on your infrastructure?	No	Yes	Yes
Your data stored by the vendor?	Yes	No	Depends
You receive downloadable software?	No	Yes	Yes
Continuous connectivity required?	Yes	No	Depends

Deployment model for this deal: ☐ SaaS ☐ On-Premise ☐ Hybrid

Once the model is fixed, you know where to aim. In a SaaS review, service levels, data rights, security obligations, and exit terms are the critical path, and the on-premise grant mechanics are nearly vestigial. In an on-premise review, the grant, installation rights, maintenance, update rights, and audit/true-up terms carry the weight, and uptime SLAs are of limited relevance. In a hybrid review, both critical paths apply, and the integration provisions and cross-component consistency become their own critical item—an inconsistency between the cloud terms and the on-premise terms is where the litigation seeds get planted.

Checklist 1.2: Gather the Business Context

The legal terms are inert without the business facts. Before you touch a redline, capture these:

What you need	Captured	Why it drives the review
Total contract value (annual and multi-year)	☐	Calibrates the liability-cap and scrutiny analysis
Business criticality (mission-critical vs. convenience)	☐	Sets the stakes for SLAs, exit, and indemnity
Users, seats, or volume required	☐	Must match the license metric exactly
Data sensitivity	☐	Drives security and breach review
Regulatory footprint (HIPAA, SOX, GDPR, PCI, etc.)	☐	Determines which addenda are mandatory
Integrations with other systems	☐	Affects combination carve-outs in the indemnity
Expected duration and renewal appetite	☐	Shapes renewal and price-protection terms
Alternatives genuinely considered	☐	This is your actual leverage
Signing-timeline pressure	☐	Be candid; urgency is the vendor's ally
Internal stakeholders and their priorities	☐	Legal, IT, security, procurement, finance

Contract value and data sensitivity together tell you how hard to push, so you neither lavish six weeks of negotiation on a trivial utility nor rubber-stamp the system that holds your customers' health records. A rough rule: high revenue-at-risk and high data sensitivity warrant maximum scrutiny and a full pass through every part below; low revenue and low sensitivity warrant a targeted pass hitting the grant, the cap, and the data-return provision and little else. The point is not to review less; it is to review proportionately, so the attention lands where the exposure is.

Checklist 1.3: Map the Regulatory Overlay

Regulated data drags a second contract into the deal—almost always an addendum—and the absence of that addendum is itself a finding. Identify which regimes apply before you assess the compliance language, because each imposes contractual requirements the base agreement rarely satisfies on its own.

Regime	Applies?	What it forces into the contract
HIPAA (health)	☐ Yes ☐ No	Business Associate Agreement; specified PHI handling
SOX (public companies)	☐ Yes ☐ No	Audit rights; retention; access controls
GDPR (EU personal data)	☐ Yes ☐ No	Article 28 DPA; a lawful transfer mechanism (SCCs / DPF)
CCPA/CPRA (California)	☐ Yes ☐ No	"Service provider" terms (Cal. Civ. Code § 1798.140)
PCI-DSS (card data)	☐ Yes ☐ No	Security standards; compliance attestation
GLBA (financial)	☐ Yes ☐ No	Safeguards Rule compliance
FERPA (education records)	☐ Yes ☐ No	"School official" / directory-information terms
FedRAMP (federal)	☐ Yes ☐ No	Authorization to Operate
State comprehensive privacy laws	☐ Yes ☐ No	Varies; roughly twenty states now in force
Voluntary standards	☐ Yes ☐ No	SOC 2 Type II, ISO 27001, and the like

A few of these deserve emphasis as of 2026. If the vendor will touch protected health information, HIPAA requires a Business Associate Agreement carrying the terms specified at 45 C.F.R. § 164.504(e); a cloud vendor that stores or processes PHI is almost always a business associate rather than a mere "conduit" under HHS guidance, and that has only sharpened as analytics and machine-learning features proliferate. The proposed 2024 overhaul of the HIPAA Security Rule would convert several currently "addressable" safeguards—encryption and multi-factor authentication among them—into mandatory ones, and any final rule will flow straight into BAA drafting; the mechanics live in HIPAA in the Cloud: Business Associates, BAAs, and Protecting ePHI. For EU personal data, GDPR Article 28 prescribes the content of the data-processing agreement, and cross-border transfers need a lawful mechanism—Standard Contractual Clauses or the EU–U.S. Data Privacy Framework—after Schrems II invalidated the prior arrangement; the post-Schrems II playbook is Moving Personal Data Out of the EU After Schrems II: SCCs and Transfer Impact Assessments. California's CCPA, as amended by the CPRA, demands specific "service provider" contract terms before a vendor escapes being treated as a third party to whom you "sell" data. And the state patchwork has exploded past twenty comprehensive statutes, which is why a mature program handles this with standardized addenda rather than bespoke drafting; see Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork and the operational sequence in Standing Up a Privacy Compliance Program: A Practical Checklist.

A threshold formation question hides in this same corner and deserves one paragraph before we move on. Is the contract even enforceable as written? For a negotiated enterprise agreement signed by both sides, yes—that is not seriously in doubt. But a great deal of software rides in on clickwrap ("I agree" buttons) and browsewrap (terms hyperlinked at the foot of a page). Courts enforce clickwrap as a matter of routine—ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), is the foundational decision—because clicking manifests assent. Browsewrap is a different animal: courts refuse to enforce terms the user had no reasonable notice of, as Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), and Nguyen v. Barnes & Noble, Inc., 763 F.3d 1171 (9th Cir. 2014), explain. Restatement (Second) of Contracts § 211, on standardized agreements, supplies the background principle that a party is bound by terms it had reason to know were part of the bargain. If your "agreement" is really a clickwrap order stacked on top of online terms the vendor can rewrite at will, that is a structural defect the checklists below are designed to surface—and one you should resolve by insisting the negotiated master agreement, not the shifting webpage, controls.

---

Part 2: The License Grant—The Clause That Defines What You Actually Got

The grant is the operative heart of the agreement. Everything else—warranties, support, indemnity, the cap—exists to protect or qualify the rights this clause confers. Read it the way a litigator would who will one day have to argue, on a deposition record, that a specific use was or was not authorized. A good grant answers four questions cleanly: what may you do, who may do it, where, and for what purpose. Vague answers are not generosity; they are deferred disputes—and, as Adobe teaches, sometimes deferred infringement claims.

Checklist 2.1: Scope of the Rights Granted

For each element, pin down what the agreement actually provides and whether it matches your real-world need. The most common source of post-signing pain, by a wide margin, is a grant narrower than the customer's actual deployment.

Right	The agreement grants	Adequate?
What you may do
Access / use	☐ Yes ☐ No ☐ Unclear	☐
Copy / install	☐ Yes ☐ No ☐ Unclear	☐
Modify / configure	☐ Yes ☐ No ☐ Unclear	☐
Create derivative works	☐ Yes ☐ No ☐ Unclear	☐
Who may use it
Named users only	☐ Yes ☐ No	☐
Concurrent users	☐ Yes ☐ No	☐
Enterprise-wide	☐ Yes ☐ No	☐
Affiliates included	☐ Yes ☐ No	☐
Contractors permitted	☐ Yes ☐ No	☐
Where
Named sites only	☐ Yes ☐ No	☐
Geographic limits	☐ Yes ☐ No	☐
Worldwide	☐ Yes ☐ No	☐
For what purpose
Internal use only	☐ Yes ☐ No	☐
Any business purpose	☐ Yes ☐ No	☐
Service-bureau / hosting for others	☐ Yes ☐ No	☐

Two rows quietly generate most of the trouble. The affiliates question is the corporate-structure trap: if "Customer" is defined as one legal entity, then the parent's other subsidiaries technically hold no license, and a routine internal reorganization can put you in breach without anyone touching the keyboard. This is not a hypothetical fear. In SQL Solutions, Inc. v. Oracle Corp., 1991 WL 626458 (N.D. Cal. Dec. 18, 1991), a licensee's corporate restructuring was held to be a "transfer" of the license that violated the anti-assignment clause—handing the licensor a lawful basis to terminate—even though the same people kept running the same software for the same business. The fix is a definition of "Customer" (or an "Affiliate" definition) that sweeps in entities under common control, paired with a transfer clause that expressly blesses internal reorganizations. If your organization runs multiple entities, the structural reasons this bites are laid out in Running Multiple Businesses Under One Structure: A Deep Dive into Holding, Operating, and Parent Companies. The contractors question is the outsourcing trap: if the grant runs only to "employees," then the managed-services firm or offshore team that actually operates your systems is using the software without authorization. A modern grant should reach contractors acting on the customer's behalf and for the customer's benefit.

Worked example (hypothetical). Suppose Aster Retail Group signs a per-seat license as a single Delaware entity. Two years later it forms Aster Labs, a wholly owned subsidiary, and moves twelve analysts there to work on the same merchandising platform. Nobody bought a new seat, nobody copied anything, and the twelve people do the same work at the same desks. Under a grant defined to a single entity, Aster Labs is now using unlicensed software, and under the Adobe logic that use may be characterized as infringement, not just breach—exposing Aster to statutory damages and fees over an org-chart change its own lawyers waved through at signing. One defined term, negotiated up front, would have closed the gap.

The license metric itself—named users, concurrent users, seats, cores, instances, transactions, or "tier"—deserves standalone scrutiny, because it is where audits are born. Confirm the metric is defined precisely enough that you and the vendor will count the same way two years from now. "User" should specify whether it counts unique individuals, provisioned accounts, or simultaneous sessions, and whether read-only, API, and service-account access count. The risk of an ambiguous metric is not merely a pricing squabble: it is an open invitation to the true-up invoice in Checklist 2.4 and, where usage genuinely exceeds the grant, an infringement exposure under Adobe. Define the metric once, precisely, and you close both doors at the same time.

Checklist 2.2: Restrictions on the Grant

Restrictions are the grant's mirror image. They are generally enforceable, and breaching one can terminate the license outright—so a restriction you cannot live with is not a footnote, it is a deal term. Identify each and assess its real-world bite.

Restriction	Present?	Acceptable?	Priority
No reverse engineering	☐	☐	☐ High ☐ Med ☐ Low
No decompilation	☐	☐	☐ High ☐ Med ☐ Low
No modification	☐	☐	☐ High ☐ Med ☐ Low
No sublicensing	☐	☐	☐ High ☐ Med ☐ Low
No assignment / transfer	☐	☐	☐ High ☐ Med ☐ Low
No service-bureau use	☐	☐	☐ High ☐ Med ☐ Low
No benchmarking / publishing metrics	☐	☐	☐ High ☐ Med ☐ Low
No competitive / build-a-clone use	☐	☐	☐ High ☐ Med ☐ Low
No removal of proprietary notices	☐	☐	☐ High ☐ Med ☐ Low
Field-of-use limits (industry, geography)	☐	☐	☐ High ☐ Med ☐ Low

A word on the reverse-engineering and decompilation bars, which reviewers too often wave through as boilerplate. For an ordinary commercial customer they are usually fine, but they collide with two bodies of law worth knowing. First, U.S. copyright fair use has long protected reverse engineering for interoperability in some circumstances—Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000)—yet a contract can validly waive that freedom, and courts generally enforce the waiver. Second, EU law runs the other direction: the Software Directive (Directive 2009/24/EC, art. 6) guarantees a limited, non-waivable decompilation right for interoperability, so a flat global ban may be unenforceable as to European entities. If interoperability sits anywhere on your roadmap, do not surrender it casually.

The no-benchmarking and no-competitive-use clauses are the vendor's reputation and trade-secret shields; they stop you from publishing "Product X is slower than Product Y" or building a rival tool from what you learned. They are common and frequently acceptable, but a blanket bar on any public statement about performance can snag your own procurement or marketing disclosures, so read the scope. The no-service-bureau / no-hosting-for-others restriction is the sleeper killer for a company that is itself a service provider: if your business model uses the software to deliver services to your clients, this row can be fatal, and it is the one most often missed at companies that most need to catch it. Translate every restriction into a concrete operational consequence—"no affiliate use" means a separate license per legal entity; "no assignment" means M&A friction; "no service bureau" means you cannot serve your own clients with the tool—because the operational consequence is how you set the negotiation priority.

Checklist 2.3: Grant Red Flags

None of the following is automatically fatal, but each shifts real control to the vendor or plants a future dispute. Slow down and escalate when you see them.

• [ ] A grant made "subject to" other terms that can silently switch off the license
• [ ] Vague purpose limits ("for Customer's business"—which business, exactly?)
• [ ] "No commercial use" with no definition of commercial use
• [ ] The vendor may modify the license scope, feature set, or terms unilaterally
• [ ] The license is tied to specific hardware or infrastructure you may replace
• [ ] Restrictions that conflict with your actual, intended deployment
• [ ] An ambiguous user-counting methodology (a standing audit risk)
• [ ] Silence on test, staging, development, and disaster-recovery environments
• [ ] No backup-copy right (on-premise)
• [ ] No business-continuity / DR use right

The unilateral-modification flag is the one to watch hardest in cloud deals. A clause that lets the vendor change the terms—or the features, or the privacy policy that governs your data—by editing a webpage means you never really agreed to a fixed contract at all; you agreed to whatever the vendor posts next. Courts have grown skeptical of "change-at-will" provisions, and the Specht/Nguyen notice principles cut against enforcing amended online terms the customer had no meaningful chance to see or reject. Insist that material terms change only by signed amendment, or at least with advance notice and a right to terminate on the change.

Checklist 2.4: Audit and True-Up Rights

Nearly every commercial license—and certainly every per-seat, per-core, or per-instance license—reserves the vendor's right to audit your usage and bill the shortfall. This is one of the quietest and most consequential provisions in the entire document, because it is where the vendor converts the metric ambiguity you let slide into a six- or seven-figure invoice. The major enterprise vendors run sophisticated software-asset-management practices, and an audit notice is, functionally, the opening move in a negotiation you did not schedule. Review the audit clause as carefully as the grant it polices.

Audit element	Present?	Customer-favorable?	Target
Trigger and notice
Advance written notice	☐	☐	≥ 30 days
Frequency capped	☐	☐	Once / 12 months
Business hours only	☐	☐	Minimize disruption
Scope and method
Limited to the licensed software	☐	☐	Not your whole estate
Self-certification option	☐	☐	Strongly preferred
Vendor access limited	☐	☐	Read-only, supervised
Audit data kept confidential	☐	☐	Your usage is your CI
No vendor scripts / deep-scan agents	☐	☐	Watch install-and-scan tools
Consequences
Overage priced at contract rate	☐	☐	NOT "then-current list"
Cure / grace period before penalty	☐	☐	Time to remediate
Vendor bears audit cost	☐	☐	Unless overage exceeds a threshold
No interest / penalty stacking	☐	☐
Good-faith dispute ≠ termination trigger	☐	☐	Critical

Three negotiation points carry most of the value here. First, fix the pricing of any overage to your negotiated contract rate rather than the vendor's "then-current list price"—the single most expensive default in any audit clause, because it converts an honest counting disagreement into a list-price windfall that can run triple what you actually agreed to pay. Second, secure a self-certification path so that, for routine audits, you report your own counts under penalty rather than handing the vendor's auditors the run of your network; reserve on-site audits for cases of reasonable, articulated suspicion. Third—the one customers forget—make explicit that a good-faith dispute over usage is not, by itself, a material breach that lets the vendor suspend or terminate. Without that carve-out, the vendor can hold a mission-critical system hostage to an audit finding you reasonably contest. The defensive posture starts long before any notice arrives: keep your own records of deployments, environments, and user counts, and reconcile them against the metric quarterly, so that when the notice lands you are the party holding the better evidence. For the mechanics of scoping any contractual audit right, the broader treatment in The Landscape of Software Transactions: An Overview is a useful companion.

---

Part 3: The Service Behind the License—Uptime, Support, and Continuity

If the software runs on the vendor's infrastructure, the contract is really a promise to keep a service running, and the clauses that enforce that promise are the service-level agreement and the support terms. A beautifully drafted grant is cold comfort when the service is dark for two days a month and your only "remedy" is a five-percent credit on next quarter's bill.

Checklist 3.1: The Service Level Agreement

An SLA has three moving parts: a commitment (the uptime number), a set of exclusions (the situations that do not count against the vendor), and a remedy (what you get when the vendor misses). Vendors love to haggle over the headline uptime figure while quietly drafting exclusions broad enough to swallow it whole. A "99.9%" promise with unlimited "scheduled maintenance" excluded and the vendor's sole discretion to define "maintenance" is not a 99.9% promise; it is a marketing number.

SLA element	Specified?	Adequate?	Note
Availability
Uptime percentage committed	☐	☐	Target: ____%
Calculation method defined	☐	☐	How is "downtime" measured?
Measurement window	☐	☐	Shorter favors the customer
Exclusions
Scheduled maintenance	☐	☐	Capped hours? Off-peak? Notice?
Customer-caused downtime	☐	☐	Fairly defined?
Force majeure	☐	☐	Scope limited?
Third-party failures	☐	☐	Does the vendor control the third party?
Remedies
Service credits specified	☐	☐	Meaningful amount?
Credit mechanism clear	☐	☐	Automatic or claim-based?
Credit cap	☐	☐	Acceptable?
Chronic-failure termination right	☐	☐	The remedy that actually matters
Credits not the sole remedy for material breach	☐	☐	Preserve other remedies

Translate the percentage into wall-clock time, because percentages flatter the vendor. The gap between 99.9% and 99.99% sounds trivial and is not: it is the difference between roughly nine hours of downtime a year and under an hour.

Committed uptime	Monthly downtime	Annual downtime	Read
99.0%	~7.3 hours	~3.65 days	Basic
99.5%	~3.6 hours	~1.83 days	Standard
99.9%	~43.8 minutes	~8.76 hours	Good
99.95%	~21.9 minutes	~4.38 hours	Strong
99.99%	~4.4 minutes	~52.6 minutes	Excellent

Two negotiation points carry most of the value. First, fight for the termination-for-chronic-failure right—the ability to walk if the vendor misses the SLA in, say, three consecutive months or any four months in a rolling year. Service credits are almost always trivial next to the cost of an outage; the right to leave is the discipline that actually changes vendor behavior. Second, ensure credits are not your sole remedy for an outage that rises to a material breach. A vendor that can torch your operations all year and owe nothing beyond capped credits has effectively purchased an option to underperform, priced at a rounding error.

Checklist 3.2: Support, Maintenance, and Version Life

Support is where the relationship lives day to day, and "support is included" can mean a 24/7 hotline with a one-hour response to Sev-1 issues or an inbox someone checks between meetings in a single time zone. The substance sits in the severity definitions and the response and resolution targets attached to them.

Support element	Specified?	Adequate?	Note
Hours (24/7 vs. business)	☐	☐	Which time zone?
Channels (phone, email, chat, portal)	☐	☐
Severity definitions	☐	☐	Who classifies severity?
Response-time commitments by severity	☐	☐	"Response" ≠ "resolution"
Resolution-time targets	☐	☐	Or just "commercially reasonable efforts"?
Escalation path	☐	☐
Named / dedicated contact	☐	☐
Updates and patches included	☐	☐
New versions / features included	☐	☐	Or "new editions" sold separately?
Training included	☐	☐

Press hard on the difference between a response commitment and a resolution commitment. Many SLAs promise to acknowledge a critical issue within an hour and say nothing binding about fixing it. Acknowledgment is cheap; resolution is the thing you actually need. Build the severity matrix from the contract and flag every cell the vendor left as "commercially reasonable efforts," which is polite language for "no commitment": fill in, for Critical/High/Medium/Low, the definition, the response target, and the resolution target, and stare at the blanks.

For on-premise deployments, the parallel concern is version support and end-of-life: confirm how long the vendor will support the version you are licensing, whether security patches are bundled or sold as a separate maintenance line, and what happens when the vendor declares your version end-of-life. Software that no longer receives patches is a security liability, a theme that runs through Open Source Software Licenses, Compliance, and Risk: A Comprehensive Guide and, in the incident-response context, Protecting Trade Secrets During a Data Breach: Building IP Into Incident Response.

Checklist 3.3: Source-Code Escrow for Critical On-Premise Systems

One on-premise safeguard belongs here even though it is not technically "support": source-code escrow. Because the vendor delivers object code, you depend on the vendor's continued existence to maintain mission-critical software. An escrow agreement deposits the source—plus build instructions, tools, and documentation—with a neutral agent and releases it to you on defined triggers, typically vendor abandonment of the product, sustained failure to support, or insolvency. Escrow is worth negotiating for genuinely critical systems, but two practical caveats separate a useful escrow from a decorative one.

First, the release conditions must be realistic and the deposit must be verified and kept current. The escrow agent's verification testing should confirm that a programmer of ordinary skill could actually build and maintain the software from the deposit—not merely that some files exist. Practical Law's treatment of cloud and traditional escrow solutions stresses exactly this: the items that must be deposited to let a customer rebuild or continue accessing a production environment should be fixed during a technical scoping phase and confirmed through verification services, because a modern SaaS or cloud application often cannot be reconstituted from source code alone. A one-time dump that no one updates is worse than nothing; it breeds false comfort. Second, beware a release condition triggered solely by the licensor's bankruptcy: under Bankruptcy Code § 365(e)(1), a court may treat such a condition as an unenforceable ipso facto clause and refuse to compel release. The drafting fix is to tie release to a cluster of operational triggers—failure to support, abandonment, repeated breach—rather than bankruptcy alone, and to reinforce the escrow with the § 365(n) protections discussed in Part 9. For SaaS, where there is no copy in your possession, the escrow analog is a rigorous data-portability and post-termination access regime, treated in Checklist 4.4.

---

Part 4: Data—Ownership, Security, Breach, and Exit

For any hosted solution, the data provisions are the contract. Your data is frequently the most valuable thing you bring to the relationship, and the vendor's incentives run toward extracting value from it and minimizing its obligations to protect it. These four checklists separate what contracts routinely blur together: who owns the data, what the vendor may do with it, how it is secured, and what happens when it is breached or when you leave.

Checklist 4.1: Data Ownership and the Vendor's License to Your Data

The bedrock principle is simple and should be non-negotiable: the customer owns the customer's data, and the vendor receives only a narrow license to use it for the purpose of providing the service. Vendors carve out value in the drafting around that principle—especially through "improve our products and services" and "aggregated and anonymized data" language that can quietly license your data for the vendor's machine-learning models and competitive analytics.

Data-rights element	Addressed?	Customer-favorable?	Note
Ownership
Customer owns Customer Data	☐	☐	Essential
Ownership reaches derived data	☐	☐	Often contested
Vendor acquires no rights except the license	☐	☐
Vendor's license to the data
Limited to providing the service	☐	☐	Watch "and improving"
No use for the vendor's other products	☐	☐
No use to train AI models	☐	☐	The 2026 flashpoint
No aggregation with competitor data	☐	☐
No sale or third-party sharing	☐	☐
License ends with the agreement	☐	☐
Analytics / aggregation
Vendor's aggregated-data use disclosed	☐	☐
Anonymization method specified	☐	☐	True de-identification?
Customer opt-out available	☐	☐

The "anonymized and aggregated" carve-out deserves real attention now, because regulators and courts have grown skeptical that "anonymized" data is truly anonymous. Re-identification is often trivial, and several statutes—the CPRA prominently—impose specific requirements before data counts as "deidentified," including a contractual promise not to re-identify it. The newest front is AI training. Vendors increasingly want rights to train models on your data, and a vague "improve our services" clause is exactly the hook they will later cite for it. If the vendor genuinely wants those rights, that is a concession with real value—do not give it away inside a definition. Insist on an explicit, standalone provision that addresses model training, carries an opt-out, and confirms whether any model trained on your data could surface your confidential information to other customers. The data-minimization principle—an FTC enforcement priority and a statutory duty under newer state laws—also counsels against letting the vendor retain and repurpose more data than the service requires; the program-level treatment is Data Minimization and Storage Limitation: Curbing the Over-Retention of Personal Data.

It helps to place the agreement's posture on a spectrum. At the customer-favorable end, the customer owns all data including derivatives and the vendor makes no independent use. One step in, the customer owns input data and the vendor may use anonymized aggregates. Further toward the vendor, the customer owns raw data but the vendor owns the analytics and derivatives. At the far end, the vendor holds broad rights to use, share, and sell analytics and insights—the posture to resist. Knowing where a given contract falls on that line tells you, in one glance, how much of the negotiation belongs here.

Checklist 4.2: Data Security

A vendor's security promises split into three buckets: technical safeguards (what the systems do), administrative safeguards (what the people do), and verification (how you confirm any of it is real). The most common failure is a contract full of aspirational language—"industry-standard measures," "commercially reasonable safeguards"—with no specific, auditable commitment behind it. Specificity is your ally, because a breach plaintiff and a regulator will both ask, after the fact, what the contract actually required.

Security element	Present?	Adequate?	Standard
Technical
Encryption in transit	☐	☐	TLS 1.2+
Encryption at rest	☐	☐	AES-256
Access controls	☐	☐	Least privilege
Multi-factor authentication	☐	☐
Network security measures	☐	☐
Administrative
Background checks	☐	☐
Security training	☐	☐
Need-to-know access	☐	☐
Verification
SOC 2 Type II report	☐	☐	Type II, not Type I
ISO 27001 certification	☐	☐
Penetration testing	☐	☐	Frequency?
Reports available to customer	☐	☐	On request, annually
Customer audit rights	☐	☐	Often resisted
Sector requirements (HIPAA / PCI / FedRAMP)	☐	☐	As applicable

Insist on a SOC 2 Type II report rather than Type I. A Type I report describes the controls a vendor says it has at a single point in time; a Type II report reflects an auditor's testing of whether those controls actually operated effectively over a period of months. The difference is design versus reality, and only reality helps you after an incident. Where direct customer audit rights are resisted—and most vendors resist them—a workable compromise is the vendor's commitment to maintain a recognized certification, deliver the audit report annually, remediate material findings, and grant an audit right that springs to life only after a security incident.

Checklist 4.3: Data-Breach Provisions

When—not if—a security incident occurs, this clause governs how fast you learn about it, what the vendor must do, and who pays. It is also where regulatory obligations bite hardest: you cannot meet your statutory notification deadlines (often 72 hours under GDPR, and increasingly tight under state and sector laws) if your vendor is contractually free to sit on the news for thirty days.

Breach element	Present?	Customer-favorable?	Target
"Security incident" defined	☐	☐	Breadth matters
Notification timeline	☐	☐	≤ 72 hours of discovery
Notification content specified	☐	☐
Investigation obligation	☐	☐
Remediation obligation	☐	☐
Cooperation with the customer	☐	☐
Cost allocation	☐	☐	Who pays notice, forensics?
Regulatory-notification support	☐	☐
Credit monitoring for affected individuals	☐	☐
Breach costs carved out of the cap	☐	☐	Critical

Two provisions determine whether this clause is worth anything: the notification timeline—push for "without undue delay and in any event within 72 hours of discovery"—and whether breach-related costs are carved out of the liability cap. If the cap swallows breach liability, then a vendor whose negligence exposes a million customer records owes you, at most, a refund of last year's fees. We return to that interaction in Part 8, and it is the hinge of the worked example there. For the broader response playbook when an incident hits, see Protecting Trade Secrets During a Data Breach: Building IP Into Incident Response and the before-during-after sequence in When a Breach Hits Your Crown Jewels: A Trade Secret Incident-Response Checklist.

Checklist 4.4: Data Portability and Exit

The most underappreciated risk in any SaaS deal is lock-in: the day you want to leave, the vendor holds your data hostage by making export slow, expensive, or technically impossible. Exit rights are the antidote, and they must be negotiated before you sign—while you still have leverage—not after the relationship has curdled.

Exit element	Present?	Adequate?	Note
Export functionality	☐	☐	Self-service preferred
Standard, documented format	☐	☐	Not a proprietary blob
Transition period defined	☐	☐	Duration: ____ days
Post-termination access window	☐	☐	30–90 days
Transition assistance available	☐	☐
Assistance rates capped	☐	☐
Destruction timeline	☐	☐
Destruction certificate	☐	☐	Written
Exceptions stated (backups, legal holds)	☐	☐

Two specifics make or break exit rights. The data must be returnable in a standard, usable format—CSV, JSON, a documented API export—because a dump in an undocumented proprietary structure is functionally useless. And you need a post-termination access window, typically 30 to 90 days, during which you can still retrieve data after the contract ends; without it, a vendor can delete your data the instant the term expires, which is the most avoidable disaster in the entire agreement.

---

Part 5: Intellectual Property—the Software, the Customizations, and the Feedback

IP provisions in a standard-product license are usually short and uncontroversial: the vendor owns the software, you own your data, and neither side gets implied rights in the other's pre-existing IP. The complications cluster around custom development, feedback, and open-source components, each of which can transfer rights you did not mean to give.

Checklist 5.1: IP Ownership

IP element	Addressed?	Acceptable?	Note
Vendor owns the software and its IP	☐	☐	Standard
Customer owns Customer Data	☐	☐	Essential
Pre-existing IP stays with its owner	☐	☐	Standard
Custom-development ownership specified	☐	☐	See below
Feedback / suggestions ownership	☐	☐	Vendor usually takes it
No implied licenses	☐	☐

Two rows reward attention. Feedback clauses routinely assign to the vendor, royalty-free and perpetually, any suggestions you make about the product. That is fine for casual bug reports and problematic if your team is contributing genuinely valuable ideas; cap the clause to feedback "voluntarily provided" and confirm it does not reach your confidential information or your own IP. Custom-development ownership is the genuinely hard question, and it turns on who paid, whether the work is reusable, and whether you need exclusivity. Run the analysis in this order: did the customer pay specifically for the custom work? If not, the vendor typically owns it as a standard product feature. If yes, is the work specific to the customer's business and not reusable? If it is customer-specific, the customer should own it (with a license-back to the vendor for any product-level reuse). If the work is reusable across the vendor's book of business, negotiate one of three outcomes: customer ownership plus a vendor license-back; vendor ownership plus a favorable exclusive license to the customer; or, least attractive, joint ownership.

Treat joint ownership as a last resort, because under U.S. copyright law each joint owner may independently license the work to anyone—including your competitors—subject only to a duty to account for profits. That is rarely what a customer paying for bespoke development actually wants. Where the deliverable's boundaries are vague, litigation follows: in Automated Solutions Corp. v. Paragon Data Systems, Inc., 856 N.E.2d 1008 (Ohio Ct. App. 2006), parties to a software development and ownership agreement fought for years over who owned the code and whether a termination condition had been met—a cautionary tale for any deal that leaves ownership of jointly developed work imprecise. For development-heavy engagements where the whole point is building something new, the ownership and assignment mechanics outrun what a license review can capture; see The Landscape of Software Transactions: An Overview and, for the iterative-delivery context that muddies "what was the deliverable," Contracting for Agile Software Development: Structuring Iterative Deals. If protecting the resulting code as a registered asset matters, the deposit-and-redaction mechanics are in Copyright Registration for Software: A Practical Checklist.

Checklist 5.2: Open-Source Components

Nearly all modern software incorporates open-source components, and that is usually fine—but open-source licenses carry obligations, and copyleft licenses (the GPL family) can, in some configurations, require disclosure of source code. A customer needs assurance that the vendor's open-source usage will not contaminate the customer's own proprietary code or impose surprise compliance duties.

Open-source element	Addressed?	Adequate?	Note
Disclosure / SBOM on request	☐	☐
Component list available	☐	☐
No copyleft reaching customer code	☐	☐	Especially code you redistribute
Vendor bears compliance responsibility	☐	☐
Indemnity covers open-source claims	☐	☐

Open-source licenses are real, enforceable instruments—conditions on a copyright license—as the Federal Circuit confirmed in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), so "it's just open source, it doesn't matter" is exactly backwards. Jacobsen held that violating the conditions of an open-source license (there, the Artistic License) is not merely breach of contract but can be copyright infringement, which means the same statutory-damages and injunction stakes we saw in Adobe attach to a vendor's open-source missteps too. The practical safeguards are a software bill of materials on request, a vendor warranty that its open-source use does not subject the customer to copyleft obligations, and indemnity coverage for open-source compliance claims. For where the landmines actually sit, see Open Source Licensing Traps in Enterprise Software: Mapping the Hidden Risks, the program-building sequence in The Open Source Compliance Playbook: A Complete Collection of Working Checklists, and the combined IP-to-compliance roadmap in Software and Open Source Licensing: An IP-to-Compliance Toolkit.

---

Part 6: Warranties and Disclaimers—the Promise and the Take-Back

Warranties are affirmative promises about the software's quality and provenance; disclaimers are the vendor's attempt to negate every promise the law would otherwise imply. The two clauses are engineered to be in tension, and your net warranty position is the difference between them. A contract with a generous express-warranty section followed by a sweeping disclaimer can leave you with less than you thought—so always read them together, not in sequence.

Checklist 6.1: Express Warranties

Warranty	Present?	Meaningful?	Duration
Software performs per documentation	☐	☐
Service meets the SLA	☐	☐
Functionality as described in the SOW	☐	☐
Vendor has authority to grant the license	☐	☐
No conflict with third-party obligations	☐	☐
Compliance with applicable law	☐	☐
Non-infringement	☐	☐	Anchors the IP indemnity
No trade-secret misappropriation	☐	☐
Security measures as described	☐	☐
No known material vulnerabilities	☐	☐
Virus / malware-free	☐	☐

The bedrock express warranty is that the software will perform materially in accordance with its documentation for a defined period. Notice what that does: it makes the documentation a contract term. So the documentation should be specific, and you should keep a copy as of signing, because a vendor that can rewrite the docs can rewrite the warranty. The non-infringement warranty is the foundation for the IP indemnity in Part 7 and should not be quietly disclaimed—watch for it migrating onto the disclaimer list, discussed below.

Checklist 6.2: Warranty Remedies

A warranty without a remedy is decorative. The remedy clause defines what you actually get when the software fails to keep its promise.

Remedy element	Present?	Acceptable?	Note
Repair / correction	☐	☐
Replacement with conforming software	☐	☐
Refund at the vendor's election	☐	☐
Refund at the customer's election	☐	☐	Better
Remedies are non-exclusive	☐	☐
Time to remedy specified	☐	☐

Most warranties offer "repair, replace, or refund" at the vendor's election, which is standard. Your point of leverage is the fallback: if the vendor cannot repair or replace within a reasonable time, you should be able to terminate and recover a refund—and that refund should not shrink to a trivial pro-rata sliver. Watch, too, for a remedy styled as "sole and exclusive," which forecloses every other remedy the law might supply. The UCC permits such limited remedies but provides, in § 2-719(2), that if the limited remedy "fail[s] of its essential purpose," the buyer may resort to the Code's other remedies. That doctrine is your safety valve when an "exclusive" repair remedy degrades into a perpetual loop of patches that never actually fix the defect—the software equivalent of a mechanic who keeps your car for months and never makes it run.

Checklist 6.3: Disclaimers

Disclaimer element	Present?	Enforceable?	Note
Conspicuous (caps / bold)	☐	☐	Required for enforceability
Merchantability disclaimed	☐	☐	Standard
Fitness for a particular purpose disclaimed	☐	☐	Standard
Non-infringement disclaimed	☐	☐	Resist
Uninterrupted operation disclaimed	☐	☐	Standard
Error-free operation disclaimed	☐	☐	Standard
Express warranties preserved	☐	☐	Check for conflict

Here the law hands you a lever. To the extent software is treated as goods under UCC Article 2—and the question is genuinely unsettled, because software is intangible and courts split on whether Article 2 governs, a question the failed Uniform Computer Information Transactions Act (UCITA) tried and failed to resolve, ending up adopted in only a couple of states—the Code requires that disclaimers of the implied warranties of merchantability and fitness for a particular purpose be conspicuous, UCC §§ 2-316, 1-201(b)(10). That is why these disclaimers appear in ALL CAPS or bold: not because lawyers enjoy shouting, but because a buried, ordinary-type disclaimer can be held unenforceable. When you see a merchantability or fitness disclaimer set in plain type, flag it—it may not survive a challenge, and it also signals careless drafting worth a second look elsewhere. And resist letting the non-infringement warranty land on the disclaimer list, because disclaiming it tends to hollow out the IP indemnity you are about to negotiate.

---

Part 7: Indemnification—Who Defends and Pays When a Third Party Sues

An indemnity is a promise to step in and handle—defend, and pay for—certain third-party claims. The marquee indemnity in a software deal is the vendor's promise to protect you if the software is accused of infringing someone else's IP, because that is a risk you cannot evaluate (you did not write the code and cannot know what patents it might trip) and the vendor can. A strong IP indemnity is among the most valuable protections a customer can win.

Checklist 7.1: The Vendor's IP Indemnity

Element	Present?	Adequate?	Note
Coverage
Patent infringement	☐	☐
Copyright infringement	☐	☐
Trademark infringement	☐	☐
Trade-secret misappropriation	☐	☐
Open-source compliance claims	☐	☐	See Part 5.2
Vendor obligations
Defense (vendor controls and funds)	☐	☐
Indemnity (pays judgments / settlements)	☐	☐
Hold harmless	☐	☐
Settlement with the customer's consent	☐	☐	No admissions binding the customer
Carve-outs
Customer-modification	☐	☐	Reasonable if narrow
Combination	☐	☐	Review scope closely
Misuse	☐	☐	Reasonable if narrow
Failure to use updates	☐	☐	Review scope
Remediation options
Procure the right to continue use	☐	☐
Modify to be non-infringing	☐	☐	Without losing function
Terminate and refund	☐	☐	Refund must be substantial

The carve-outs are where vendors quietly recover what the indemnity gives. Each is reasonable in principle—the vendor should not have to defend infringement you caused by hacking up the code, misusing it, or combining it with something the vendor warned against—but each is also a place to smuggle in an exception broad enough to gut the protection. The test is causation and fault. A modification carve-out is fair when the infringement was caused by the customer's modification and unfair when the vendor required or supplied the modification. A combination carve-out is fair when the customer chose the combination on its own and unfair when the combination was the vendor's design or instruction. A "failure to use updates" carve-out is fair when the update was available, practical, and free and unfair when the "update" demands a major migration or new fees. A "use outside scope" carve-out is fair when there was a clear license violation and unfair when the scope was ambiguous—which loops back to why Part 2 insists on a precise metric.

Note the remediation options at the bottom. When the software is found to infringe, vendors typically reserve the right to (1) procure a license so you can keep using it, (2) modify it to be non-infringing, or (3) terminate and refund. The trap is option (3) with a nominal refund: a vendor that can yank a mission-critical system and hand back a fraction of last year's fees has drafted an indemnity that protects the vendor, not you. Insist that any modification preserve materially equivalent functionality and that any termination refund be substantial rather than a token.

Checklist 7.2: The Customer's Indemnity

Indemnities run both ways. The customer typically indemnifies the vendor for claims arising from the customer's data and the customer's misuse, which is fair. The line to hold is that the customer should never indemnify the vendor for the vendor's own handling of the customer's data; that flips the risk allocation backwards.

Customer indemnity	Present?	Acceptable?	Note
Customer-data claims	☐	☐	Standard
Customer's illegal use	☐	☐	Standard
Customer's breach	☐	☐	Review scope
Third-party claims re customer's use	☐	☐	May be overbroad—narrow it
Vendor's handling of Customer Data	☐	☐	Should NOT be a customer obligation

---

Part 8: Limitation of Liability—the Clause That Caps the Whole Deal

If you read one provision in a software contract with total attention, read this one. The limitation-of-liability clause does two things: it sets a dollar cap on total liability, and it excludes entire categories of damages—most importantly consequential damages, which is where the real money in a failure usually lives. Together they fix the maximum financial consequence to the vendor of breaking its promises, and therefore how seriously the vendor will treat those promises.

Checklist 8.1: The Liability Cap

Element	Specified?	Adequate?	Note
Structure
Cap amount specified	☐	☐	Amount: $______
Tied to fees paid	☐	☐	Multiple: ___x
Cap period (trailing 12 months vs. total)	☐	☐	"Trailing 12 months" common
Per-claim vs. aggregate	☐	☐
Applies to
Both parties (mutual)	☐	☐
All claims under the agreement	☐	☐
Carve-outs from the cap
Indemnification	☐	☐	Carve out or super-cap
Confidentiality breach	☐	☐	Carve out
Data-security breach	☐	☐	Carve out
Gross negligence / willful misconduct	☐	☐	Carve out
Vendor IP infringement	☐	☐	Carve out
Payment obligations	☐	☐	Standard (favors vendor)

A cap is only meaningful in light of two things: its size relative to the deal, and what is carved out of it. On size, the common market convention is a cap equal to fees paid in the trailing twelve months, with customers pushing for two to three times annual fees on important systems. But the carve-outs matter more than the headline. A 1x cap with the right carve-outs is far better than a 3x cap that swallows everything. The categories that belong outside the cap—because a small cap on them would be absurd—are IP indemnification, breach of confidentiality, data-security breaches, and the vendor's gross negligence or willful misconduct. Carving these out, or at minimum giving them a much higher "super-cap," is the single most important move in the entire limitation-of-liability negotiation. Reduce it to one worksheet: total annual value, cap amount, cap as a multiple of annual fees, and a yes/no on whether the critical liabilities are carved out—and treat a "no" on the carve-outs as making the cap inadequate regardless of the number in front of it.

A word on enforceability, because customers sometimes assume an outrageously low cap simply won't hold up in court. It usually will. Courts generally do enforce negotiated limitation-of-liability clauses between sophisticated commercial parties—freedom of contract is the rule, and the UCC expressly permits limiting consequential damages unless the limitation is unconscionable, § 2-719(3). Two safety valves exist, and neither is a plan you want to rely on. A limitation may be struck as unconscionable (limiting consequential damages for personal injury in consumer goods is presumptively unconscionable, though that rarely touches enterprise software), and most jurisdictions will not enforce a cap as applied to a party's own gross negligence, fraud, or willful misconduct as a matter of public policy. There is also a subtle interaction with Part 6: where a contract pairs an "exclusive remedy" with a damages cap, many courts treat the two clauses as independent, so a remedy's failure of its essential purpose under § 2-719(2) does not automatically dissolve the consequential-damages exclusion under § 2-719(3). The lesson points the same direction every time: you cannot count on a court to rescue you from a bad cap, so negotiate the carve-outs up front.

Checklist 8.2: The Consequential-Damages Exclusion

Element	Present?	Acceptable?	Note
Consequential damages excluded	☐	☐	Standard, mutual
Incidental damages excluded	☐	☐	Standard
Indirect / special damages excluded	☐	☐	Standard
Punitive damages excluded	☐	☐	Standard
Lost profits / revenue excluded	☐	☐	Standard
Lost data excluded	☐	☐	Consider carving out
Business interruption excluded	☐	☐	Standard
Exclusion is mutual	☐	☐	Should be
"Even if advised of the possibility" language	☐	☐	Standard

The consequential-damages waiver is so common that reviewers skim it, but understand precisely what you are surrendering. Consequential damages are the downstream harms that flow from a breach—lost profits, lost business, the cost of working around an outage—and they are usually the largest dollar exposure when software fails. Excluding them is market-standard and reasonable when mutual. The item to scrutinize is lost data: for a system whose entire job is holding your data, an exclusion of "lost data" can leave you with no recovery for the very harm the service exists to prevent, so consider carving data loss out of the exclusion and pairing it with a contractual backup obligation. In plain terms, an exclusion of lost profits means you cannot recover the revenue you would have earned but for the failure; an exclusion of business interruption means you eat the cost of workarounds during outages; an exclusion of lost data means the value of unrecoverable data is on you. The proper way to think about caps and exclusions together is that they set the ceiling on the vendor's accountability, and everything you negotiated in Parts 3 through 7 is only worth as much as that ceiling allows. For how courts actually compute the damages these clauses fence off—expectation, reliance, foreseeability under Hadley v. Baxendale—see Contract Damages: How Courts Make the Injured Party Whole.

A Worked Example: Where the Clauses Collide

The following is a hypothetical illustration, not a description of any real company, vendor, or contract.

Suppose Harbor Point Clinics, a regional network of urgent-care centers, licenses a SaaS patient-intake and records platform from a vendor called Fernwood Software for $500,000 per year. The contract carries a 99.9% uptime SLA (remedy: service credits capped at 10% of monthly fees), a liability cap of "fees paid in the trailing twelve months," a mutual consequential-damages waiver, and a security clause promising "commercially reasonable, industry-standard safeguards." There is no Business Associate Agreement, no breach-notification deadline, and no carve-out of data-security claims from the cap. Everyone was in a hurry; the order form had a quarter-end discount.

Twenty months in, a misconfigured storage bucket exposes the records of 220,000 patients. Fernwood detects the exposure but, bound by no contractual deadline, notifies Harbor Point nineteen days later—well past the point where Harbor Point could satisfy its own HIPAA and state-law notification obligations. Harbor Point now faces regulatory penalties, the cost of notifying and providing credit monitoring to 220,000 people, and a putative class action.

Walk the clauses and watch them fail one by one. The SLA is irrelevant; this was not downtime. The "commercially reasonable, industry-standard safeguards" language is too vague to anchor a clean breach-of-warranty claim, because nobody wrote down what the standard actually required. The consequential-damages waiver knocks out Harbor Point's lost business and reputational harm. And the liability cap—$500,000—limits Fernwood's total exposure to roughly two dollars and twenty-seven cents per exposed patient, a figure dwarfed by Harbor Point's own out-of-pocket costs before a single class member is compensated. Worse, with no BAA in place, Harbor Point was itself out of HIPAA compliance from day one, compounding its regulatory exposure. The lesson is not subtle. The three provisions Harbor Point skipped—a data-security carve-out from the cap, a 72-hour notification deadline, and a mandatory BAA—were the only terms that would have made the security promise worth anything. Every one was available to negotiate at signing, when Harbor Point had leverage and a quarter-end deadline working in its favor, and every one was worthless to ask for after the breach.

---

Part 9: Term and Termination—How Long You Are In, and How You Get Out

The term-and-termination provisions govern the life cycle of the relationship: how long it runs, how it renews, when each side can end it, and—critically—what happens to your data and access when it ends. The auto-renewal and notice mechanics here are responsible for more inadvertent multi-year commitments than any other clause in software contracting.

Checklist 9.1: Term and Renewal

Element	Specified?	Acceptable?	Note
Initial term length	☐	☐	Length: ______
Start date clear	☐	☐	Order date vs. effective date
Auto-renewal provision	☐	☐
Renewal term length	☐	☐
Non-renewal notice period	☐	☐	Days: ______
Renewal price-increase cap	☐	☐	Cap: ____%
Termination for convenience	☐	☐
Convenience notice period	☐	☐
Termination fee / refund policy	☐	☐

The classic trap is the evergreen auto-renewal paired with a long notice window and an uncapped price increase: the contract renews automatically for another year unless you give notice ninety days before the term ends, and on renewal the vendor may raise the price by any amount. Miss the notice date and you are locked in for another year at whatever number the vendor names. A related trap lurks in option clauses generally, because courts hold parties to renewal and option deadlines strictly. In Facetime Communications, Inc. v. Reuters Ltd., 2008 WL 2853389 (S.D.N.Y. July 22, 2008), a licensee that missed its option-exercise deadline by a matter of days lost its right to continue using the software, and the court declined to bail it out on equitable grounds. The defenses are three: a cap on renewal price increases (for example, the lesser of five percent or CPI), a manageable notice period, and a calendaring discipline so the notice date never sneaks up on you—set reminders at ninety days, thirty days, and on the deadline itself, and record the last date to give notice the day you sign. Note, too, that many U.S. states now regulate auto-renewal disclosures, and California's amended Automatic Renewal Law (effective 2025) tightened cancellation and notice requirements—useful background wherever your contracts touch consumer-facing renewals.

Checklist 9.2: Termination Rights and the Bankruptcy Problem

Termination right	Available?	Conditions	Note
Material breach by the other party	☐	Cure: ___ days	Usually 30 days
Bankruptcy / insolvency	☐		See § 365(n) below
Chronic SLA failure	☐	Threshold: ___	The remedy that matters
Change of control	☐
Convenience—by customer	☐	Notice: ___ days
Convenience—by vendor	☐	Notice: ___ days	A vendor convenience right is dangerous
Automatic on non-renewal	☐
Automatic on regulatory prohibition	☐

The bankruptcy angle is subtle and worth getting right, because what happens if the vendor goes under can determine whether your business keeps running. For on-premise software, Bankruptcy Code § 365(n) gives an intellectual-property licensee the option, if the debtor-licensor rejects the license, to retain its rights under the license for the balance of the term. Congress enacted § 365(n) precisely to overturn the harsh result in Lubrizol Enterprises, Inc. v. Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985), where a rejected IP license simply evaporated and the licensee was left with a damages claim against an insolvent estate. The doctrine has since moved further in the licensee's favor: in Mission Product Holdings, Inc. v. Tempnology, LLC, 139 S. Ct. 1652 (2019), the Supreme Court resolved a long-running circuit split—between the Lubrizol rescission approach and the Seventh Circuit's contrary reasoning in Sunbeam Products, Inc. v. Chicago American Manufacturing, LLC, 686 F.3d 372 (7th Cir. 2012)—by holding that a debtor-licensor's rejection of a license operates as a breach, not a rescission, so the licensee's rights survive. Mission Product addressed a trademark license (a category § 365(n) does not expressly cover), which makes it especially significant for software deals that bundle trademark rights with the code.

Two practical moves follow. First, reinforce § 365(n) with an express acknowledgment in the contract and, for critical systems, with the source-code escrow discussed in Part 3—remembering the ipso facto limitation of § 365(e)(1), which is why escrow release should never hinge on bankruptcy alone. Second, watch for a vendor right to terminate for convenience: a vendor that can walk away on short notice can strand you mid-deployment, so this should be heavily restricted or removed outright. And because the right to terminate for the other side's breach is itself a frequent battleground—recall that in Automated Solutions the very existence of a triggering breach was the contested question—define your cure periods and triggering events with real precision. The bankruptcy-side mechanics, executory-contract analysis, and non-debtor-licensee protections are developed at length in Practical Law's IP-and-bankruptcy materials; the strategic upshot for a reviewer is to treat § 365(n) as a floor to be reinforced, not a complete answer.

Checklist 9.3: What Survives Termination

What survives termination is as important as termination itself. The clauses that protect you—confidentiality, indemnification, the liability cap—must be drafted to survive the agreement's end, and your data must come home.

Post-termination element	Addressed?	Adequate?	Note
Customer-data return / export	☐	☐	Tie to Part 4.4
Transition period	☐	☐	Length: ___ days
Continued access during transition	☐	☐
Transition assistance	☐	☐
Data-destruction timeline	☐	☐
Destruction certificate	☐	☐
Survival of confidentiality	☐	☐
Survival of indemnification	☐	☐
Survival of the liability cap	☐	☐
Accrued rights preserved	☐	☐

---

Part 10: The Boilerplate That Bites—Assignment, Confidentiality, and Dispute Resolution

"Boilerplate" is a dangerous word, because it implies these clauses are interchangeable filler. They are not. The assignment clause can block your merger, the confidentiality clause governs your most sensitive information, and the dispute-resolution clause decides whether a fight happens in your backyard or the vendor's, in court or in arbitration.

Checklist 10.1: Assignment and Change of Control

Element	Addressed?	Acceptable?	Note
Customer assignment rights	☐	☐
Affiliate assignment permitted	☐	☐
M&A assignment permitted	☐	☐	Critical
Consent standard ("not unreasonably withheld")	☐	☐
Vendor assignment rights	☐	☐
Change-of-control definition	☐	☐
Change-of-control termination right	☐	☐

The anti-assignment clause is an M&A landmine with real case law behind it. If the contract bars assignment without the vendor's consent and—expressly or by operation of law—treats a change of control as an "assignment," then an acquirer of your company technically needs the vendor's permission to keep using software your business depends on, handing the vendor a veto and a re-pricing opportunity at your most vulnerable moment. SQL Solutions v. Oracle (Part 2.1) is the cautionary tale: a corporate restructuring was treated as a prohibited transfer that justified termination, because copyright licenses are presumptively non-assignable and the agreement said nothing to the contrary. Negotiate an express carve-out permitting assignment to an affiliate or to a successor in a merger or sale of substantially all assets without consent, and confirm the carve-out reaches internal reorganizations, not just third-party acquisitions. This is the same trap the Aster Retail hypothetical illustrated from the grant side; the assignment clause is where it detonates during a deal.

Checklist 10.2: Confidentiality

Element	Addressed?	Adequate?	Note
Confidential information defined	☐	☐
Standard exceptions included	☐	☐	Public, independently developed, etc.
Use limitations	☐	☐
Disclosure limitations	☐	☐
Compelled disclosure permitted with notice	☐	☐	Where lawful
Return / destruction at termination	☐	☐
Survival period	☐	☐
Trade secrets protected indefinitely	☐	☐	No fixed time limit

The subtlety most often missed: confidentiality obligations usually expire after a term of years—three to five is typical—but trade secrets should be protected for as long as they remain trade secrets, which is to say indefinitely. A flat five-year confidentiality term can inadvertently strip protection from genuine trade secrets, which is why well-drafted clauses carve trade secrets out of the time limit. For the drafting mechanics, see Non-Disclosure Agreements for Technology Deals: Drafting for Enforceability; for the substantive protection of secrets and the reasonable-measures standard that keeps them protectable, see Building Trade Secret Protection from the Ground Up: A Comprehensive Guide and the life-cycle roadmap in Trade Secret Protection Toolkit: Building and Defending a Confidentiality Program.

Checklist 10.3: Dispute Resolution

Element	Specified?	Preferred?	Note
Governing law	☐	☐	State: ______
Exclusive jurisdiction / venue	☐	☐	Location: ______
Mandatory arbitration	☐	☐
Arbitration rules	☐	☐	AAA, JAMS
Mediation first	☐	☐
Injunctive relief preserved	☐	☐	For IP / confidentiality
Prevailing-party fees	☐	☐
Class-action waiver	☐	☐
Jury-trial waiver	☐	☐

Two practical points close out the boilerplate. First, venue and governing law are not neutral: a clause requiring you to litigate in the vendor's home state under the vendor's law raises the cost and friction of ever holding the vendor accountable, which is precisely why the vendor put it there. Second, the arbitration choice is genuinely double-edged. Arbitration can be faster, cheaper, and confidential, but judicial review of an award is famously narrow under the Federal Arbitration Act, 9 U.S.C. § 10, so a bad award is effectively final. Decide deliberately rather than accepting the vendor's default; the trade-offs, the vacatur grounds, and the drafting choices are mapped in Arbitration in Practice: A Comprehensive Guide to Alternative Dispute Resolution and the clause-drafting toolkit in Arbitration and ADR: A Toolkit for Choosing a Forum, Drafting Clauses, and Running a Case. Whatever forum you choose, always preserve the right to seek injunctive relief in court for IP and confidentiality breaches, because those harms are often irreparable and cannot wait for an arbitrator to be appointed.

---

Part 11: Role-Specific Negotiation Priorities

The same contract reads differently depending on which chair you sit in. These lists translate the review above into a negotiation plan, sorted by how hard to fight for each item.

Checklist 11.1: The Customer's Priorities

Must-have (do not sign without):

• [ ] Clear customer ownership of customer data
• [ ] A meaningful liability cap (at least 1x annual fees) with the critical carve-outs
• [ ] Vendor IP indemnification
• [ ] Data portability and a post-termination access window
• [ ] An SLA with credits and a chronic-failure termination right (SaaS)
• [ ] Reasonable termination rights and a § 365(n) acknowledgment (on-premise)
• [ ] A precise license metric and an audit clause priced at contract, not list, rates

Should-have (negotiate hard):

• [ ] Carve-outs from the cap for IP, confidentiality, security, and willful misconduct
• [ ] Breach notification within 72 hours
• [ ] A SOC 2 Type II commitment or audit rights for security
• [ ] A cap on renewal price increases; no unilateral term changes
• [ ] Assignment rights for M&A and affiliate use
• [ ] An explicit limit—or ban—on using your data to train AI models

Nice-to-have (if leverage permits):

• [ ] Customer ownership of custom development
• [ ] Termination for convenience
• [ ] Most-favored-customer pricing
• [ ] Enterprise-wide or unlimited-user licensing
• [ ] Extended support hours and benchmarking rights

Checklist 11.2: The Vendor's Priorities

Protect:

• [ ] Ownership of the software and all IP in it
• [ ] The liability cap and the consequential-damages waiver
• [ ] Conspicuous, enforceable warranty disclaimers
• [ ] Payment obligations (carved out of the cap in the vendor's favor)
• [ ] License scope, restrictions, and audit rights
• [ ] SLA remedy limits (credits as the primary remedy)

Flexible, with appropriate pricing:

• [ ] The cap amount (raise it for a premium)
• [ ] Additional cap carve-outs
• [ ] Enhanced SLA and security commitments
• [ ] Broader use rights (affiliates, contractors, geography)
• [ ] Termination for convenience

Avoid agreeing to:

• [ ] Uncapped liability
• [ ] Unlimited or uncapped indemnification
• [ ] Customer ownership of all customizations and improvements
• [ ] Unrestricted benchmarking and publication rights
• [ ] Perpetual, irrevocable licenses with no payment hook
• [ ] Most-favored-customer clauses without clear limits

---

Part 12: The Final Pre-Signature Pass

The last pass is mechanical but indispensable. More deals are damaged by a missing exhibit or an inconsistent order form than by any subtle doctrinal nuance.

Completeness:

• [ ] All schedules and exhibits attached
• [ ] Order-form details match the master terms
• [ ] Any SOW is consistent with the master agreement
• [ ] Pricing and payment terms complete
• [ ] All blanks filled in
• [ ] Defined terms used consistently
• [ ] Cross-references point to the right sections
• [ ] Signature blocks name the correct legal entities
• [ ] Effective date specified

Risk assessment (rate High / Medium / Low, and confirm mitigation): data security, business continuity, vendor lock-in, cost escalation, audit/true-up exposure, IP exposure, liability exposure, regulatory compliance, and exit difficulty. Any "High" without mitigation is a conversation to have before, not after, signing.

Approval and execution:

• [ ] Business owner approved
• [ ] Legal approved
• [ ] IT / Security reviewed (if applicable)
• [ ] Procurement and Finance reviewed (if applicable)
• [ ] Signature authority confirmed
• [ ] Countersigned copy received and filed
• [ ] Contract-management system updated
• [ ] Renewal and notice dates calendared
• [ ] Ongoing-obligation owners notified

---

Quick Reference: Red Flags That Should Stop You

Each of the following is a place where the contract quietly shifts meaningful risk or control to the other side. See one, and slow down.

Red flag	Why it matters
"Vendor may modify these terms at any time"	Your deal can change unilaterally; assent may be illusory
"Customer data may be used for any purpose"	Your data is no longer yours
"…to improve our products and services" (undefined)	A hook for AI training and analytics on your data
"Liability limited to fees paid in the prior month"	Effectively no protection
"Vendor's sole obligation is a refund"	No meaningful remedy for a failure
"Customer indemnifies Vendor for all claims"	Backwards risk allocation
"No assignment without Vendor consent" (no exceptions)	M&A and reorganization trap (SQL Solutions v. Oracle)
Overage billed at "then-current list price"	Audit findings become a list-price windfall
Auto-renewal + uncapped increase + long notice window	Cost-escalation and lock-in trap
"As-is," with no express warranties	No performance commitment to enforce
No data-return provision	Hostage-data risk
A merchantability disclaimer in plain type	May be unenforceable—and flags careless drafting
Exclusive arbitration in the vendor's hometown	A structural dispute-resolution disadvantage

---

Key Takeaways

Reviewing a software license is a discipline, not a talent. The document is long, but the risk is concentrated in a handful of provisions, and a systematic pass finds them every time. A few principles carry the whole toolkit.

You are licensing, not buying—and exceeding the license can be infringement. Every restriction draws its force from the license-versus-sale architecture blessed in Vernor v. Autodesk, and Adobe v. One Stop Micro shows that stepping outside the grant can be copyright infringement, not just breach. Read the grant as the answer to what, who, where, and for what purpose, and make each answer match your real deployment.

Context sets the stakes. A clause that is fine in a trivial tool is intolerable in a mission-critical system. Identify the deployment model, the business criticality, and the regulatory overlay before you redline a word, so your attention lands where the exposure is.

The liability clause is the master valve. The dollar cap and the consequential-damages exclusion together fix the maximum consequence of the vendor's broken promises. The carve-outs—IP, confidentiality, data security, willful misconduct—matter more than the headline number, as the Harbor Point hypothetical in Part 8 makes painfully plain.

Your data and your exit are the SaaS battleground. Own your data, narrow the vendor's license to it (watch the "improve our services" and AI-training language), demand fast breach notice that survives the cap, and lock in portability and a post-termination access window before you sign, while you still have leverage.

The audit clause is the sleeper. A precise license metric and a fair audit clause—priced at contract rates, with a self-certification path and a good-faith-dispute carve-out—prevent the true-up invoice that ambushes unprepared customers.

Every term is negotiable. "Standard" means "our opening position," not "the law of nature." Document why you accepted what you accepted; the version of you staring at this contract during a future dispute will be grateful.

Used together, the checklists supply the system and your judgment supplies the attention. That combination turns a thirty-eight-page firehose into an orderly, defensible review—the kind that catches the one-month liability cap, the buried data-use clause, and the list-price audit trap before any of them becomes your problem.

---

Frequently Asked Questions

Is a software license the same as buying the software? Almost never. Commercial software is licensed, not sold, which keeps you a licensee rather than an owner and makes the contract's restrictions enforceable. Courts uphold this structure—Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010)—where the vendor retains title, restricts transfer, and imposes use restrictions. The practical consequence is that the copyright first-sale doctrine, 17 U.S.C. § 109, which would let you resell a purchased copy, does not apply.

Can using software beyond the license be copyright infringement, not just breach of contract? Yes, and the distinction is expensive. When the grant is structured as a conditional license, using the software outside its scope can be copyright infringement, exposing you to statutory damages, attorneys' fees, and injunctions rather than ordinary contract damages. In Adobe Systems Inc. v. One Stop Micro, Inc., 84 F. Supp. 2d 1086 (N.D. Cal. 2000), out-of-scope sales were held to be infringement as a matter of law. That is why a license narrower than your actual use is a genuine risk, not a paperwork nuisance—and why an ambiguous user metric can quietly convert an over-deployment into an infringement claim.

Are clickwrap and browsewrap agreements enforceable? Clickwrap—where you click "I agree"—is routinely enforced because clicking manifests assent (ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996)). Browsewrap—terms merely linked on a page—is enforceable only if the user had reasonable notice, which often fails (Specht v. Netscape, 306 F.3d 17 (2d Cir. 2002); Nguyen v. Barnes & Noble, 763 F.3d 1171 (9th Cir. 2014)). For a negotiated enterprise agreement signed by both sides, enforceability is not in doubt; the problem arises with online terms layered onto orders and subject to unilateral change.

What is the single most important clause to negotiate as a customer? The limitation of liability—specifically, its carve-outs. The cap and the consequential-damages exclusion set the ceiling on what the vendor can owe you if everything goes wrong. A modest cap with the right carve-outs (IP indemnity, confidentiality, data security, and gross negligence or willful misconduct sitting outside the cap) protects you far better than a large cap that swallows every claim.

Why does the warranty disclaimer have to be in ALL CAPS? To the extent software is treated as goods under UCC Article 2, the Code requires that disclaimers of the implied warranties of merchantability and fitness for a particular purpose be conspicuous (UCC §§ 2-316, 1-201(b)(10)). All-caps or bold text is how drafters meet that requirement. A disclaimer buried in ordinary type may be unenforceable—so a plain-type disclaimer is both a legal vulnerability for the vendor and a signal of careless drafting worth investigating elsewhere in the document.

How big should a liability cap be? There is no universal answer, but the common market convention is a cap equal to fees paid in the trailing twelve months, with customers negotiating two to three times annual fees for important systems. More important than the multiple is what sits outside it: IP indemnification, breach of confidentiality, data-security incidents, and the vendor's gross negligence or willful misconduct should be carved out or given a much higher super-cap.

What protects me if my software vendor goes bankrupt? For on-premise software, Bankruptcy Code § 365(n) lets an IP licensee retain its license rights for the term even if the bankrupt vendor rejects the contract—a protection Congress added after Lubrizol Enterprises v. Richmond Metal Finishers, 756 F.2d 1043 (4th Cir. 1985). The Supreme Court reinforced the pro-licensee direction in Mission Product Holdings, Inc. v. Tempnology, LLC, 139 S. Ct. 1652 (2019), holding that rejection is a breach, not a rescission, so the licensee's rights survive. Reinforce these protections with an express acknowledgment in the agreement and, for mission-critical software, a verified, regularly updated source-code escrow—but tie release to operational triggers (failure to support, abandonment) rather than bankruptcy alone, because a release triggered solely by bankruptcy may be an unenforceable ipso facto clause under § 365(e)(1). For SaaS, the analog is rigorous data portability and a post-termination access window, because there is no copy in your possession to fall back on.

What is a software license audit, and how do I avoid a surprise true-up bill? Most commercial licenses let the vendor audit your usage against the license metric and bill any overage. The defenses are to define the metric precisely, fix overage pricing to your contract rate rather than "then-current list price," secure a self-certification option in place of on-site audits, ensure a good-faith usage dispute cannot trigger termination, and keep your own deployment and user-count records so you arrive at the audit holding the better evidence. See Checklist 2.4.

Do I need a separate data-processing addendum or a BAA? Often, yes. If the vendor processes EU personal data, GDPR Article 28 requires a data-processing agreement; if it handles protected health information, HIPAA requires a Business Associate Agreement with the terms at 45 C.F.R. § 164.504(e); and California's CCPA/CPRA requires specific "service provider" terms (Cal. Civ. Code § 1798.140). The base agreement rarely satisfies these on its own, and the absence of the required addendum is itself a red flag. See Building a Privacy Compliance Program and HIPAA in the Cloud.

How do I avoid getting locked into an automatic renewal? Read the renewal clause first, not last. Watch for an evergreen auto-renewal paired with a long non-renewal notice window and an uncapped price increase. Courts enforce renewal and option deadlines strictly (Facetime Communications v. Reuters, 2008 WL 2853389 (S.D.N.Y. 2008)), so calendar the notice deadline with reminders at ninety days, thirty days, and the deadline itself, and negotiate a cap on renewal increases and a workable notice period. Many states also regulate auto-renewal disclosures, and California tightened its Automatic Renewal Law in 2025.

---

Related UpLaw Resources

Related Guides

• Anatomy of a Software License Agreement: A Comprehensive Guide
• HIPAA in the Cloud: Business Associates, BAAs, and Protecting ePHI
• Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork
• Data Minimization and Storage Limitation: Curbing the Over-Retention of Personal Data
• Contract Damages: How Courts Make the Injured Party Whole

Related Articles

• Software License Agreements: Key Terms and How to Negotiate Them
• How Software Licensing Works: An Overview
• The Landscape of Software Transactions: An Overview
• How the Law Protects Software: Copyright, Patents, Trade Secrets, and Contract Rights
• Contracting for Agile Software Development: Structuring Iterative Deals
• Open Source Licensing Traps in Enterprise Software: Mapping the Hidden Risks
• Open Source Software Licenses, Compliance, and Risk: A Comprehensive Guide
• Non-Disclosure Agreements for Technology Deals: Drafting for Enforceability
• Building Trade Secret Protection from the Ground Up: A Comprehensive Guide
• Protecting Trade Secrets During a Data Breach: Building IP Into Incident Response
• Running Multiple Businesses Under One Structure: A Deep Dive into Holding, Operating, and Parent Companies
• Moving Personal Data Out of the EU After Schrems II: SCCs and Transfer Impact Assessments
• Arbitration in Practice: A Comprehensive Guide to Alternative Dispute Resolution

Related Checklists

• Reviewing a Software License Agreement: A Practical Checklist
• The Open Source Compliance Playbook: A Complete Collection of Working Checklists
• Copyright Registration for Software: A Practical Checklist
• When a Breach Hits Your Crown Jewels: A Trade Secret Incident-Response Checklist
• Standing Up a Privacy Compliance Program: A Practical Checklist

Related Toolkits

• Software and Open Source Licensing: An IP-to-Compliance Toolkit
• Trade Secret Protection Toolkit: Building and Defending a Confidentiality Program
• Arbitration and ADR: A Toolkit for Choosing a Forum, Drafting Clauses, and Running a Case

---

This article provides general information, not legal advice, and does not create an attorney-client relationship. Software contracts are governed by law that varies by jurisdiction and continues to evolve; consult qualified counsel about your specific agreement and circumstances.