Drafting Software License Agreements: Key Terms and Negotiation Points

When Northstar Analytics—a fictional company that sells a cloud-based supply-chain forecasting platform—lands a deal with Brightway Logistics, a large enterprise customer, both companies are about to bet a great deal on a single contract. Northstar's revenue and reputation ride on the agreement. Brightway is about to route the data and decisions of its entire logistics operation through software it does not own, cannot see inside, and could not rebuild if it had to. And yet the negotiation, if it goes the way most do, will pour its energy into price and almost none into the terms that actually allocate the risk: what happens when the service goes down, who owns the data, who pays when something infringes a third party's patent, what the customer can do with the software, and how much either side can be made to pay when things go badly wrong.

That imbalance is the problem this article addresses. Software licensing is widely misunderstood. Vendors present standard forms as non-negotiable when there is real flexibility. Customers fixate on a few percentage points of price while overlooking provisions that create orders of magnitude more exposure. And both sides routinely fail to appreciate that different delivery models—software hosted as a cloud service, installed on the customer's own servers, or some hybrid—demand fundamentally different contracts. The result is agreements that fail to protect legitimate interests, create surprise liabilities, and generate disputes that damage relationships both parties had every reason to preserve.

What follows is a working framework for understanding, drafting, and negotiating software license agreements, told through Northstar and Brightway. We start with the legal foundation—why a license is the shape this transaction takes at all—then examine how the deployment model reshapes everything, and work through the license grant and its scope, the often-overlooked but consequential difference between a license covenant and a license condition, service levels, data rights and privacy, open source, warranties and disclaimers, indemnification, limitation of liability, audit rights, escrow and bankruptcy protection, and termination. Throughout, the question is the same: where does the risk sit, and is it sitting with the party best able to carry it? For the companion question of how to protect software as an asset in the first place, our work on the legal protection of software is the place to start, and for a clause-by-clause review tool you can run against any draft, see our software license agreement review checklists.

Why It Is a License at All: The Copyright Foundation

Everything about these agreements flows from one fact: software is protected by copyright. The Copyright Act of 1976, codified at 17 U.S.C. § 101 et seq., protects computer programs as "literary works"—both human-readable source code and machine-executable object code are copyrightable expression—and that protection arises automatically the moment original code is fixed in a tangible medium. No registration, no notice, no ritual is required for the right to exist. (Registration still matters: as we explain in our guide on registering a copyright, timely registration is what unlocks statutory damages and attorneys' fees under 17 U.S.C. §§ 412 and 504, which is why valuable code should be registered, not merely written.)

Because the code is copyrighted, copying it, running it, distributing it, or making derivative works from it are rights that belong exclusively to the owner under 17 U.S.C. § 106—and exercising any of them without permission is infringement. That is the engine of the whole transaction. What a software company sells is not, despite the marketing, "the software." It sells permission—a license, a grant of authority to do things that would otherwise be unlawful.

A license is not an assignment, and the distinction does real work. An assignment transfers ownership; a license leaves ownership exactly where it was and grants the licensee a defined slice of permission. Because Northstar keeps the copyright, it can grant overlapping non-exclusive licenses to a thousand customers at once, attach conditions to how each one uses the platform, and reclaim the permission on the terms it negotiated. The license grant is therefore the beating heart of every software agreement; service levels, warranties, indemnities, and liability caps all exist to support and constrain that one act of permission. Northstar owns the forecasting platform's copyright. What it sells Brightway is conditional permission to use it—nothing more, and the agreement is the instrument that defines the "conditional."

One foundational doctrinal wrinkle is worth flagging at the outset because it changes how the rest of the agreement should be drafted: most software is licensed, not sold. Courts have generally enforced license terms that characterize a transaction as a license rather than a sale of a copy, which keeps the customer from invoking the first-sale doctrine of 17 U.S.C. § 109 to resell or transfer the software. The Ninth Circuit's decision in Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010), set out the now-familiar test: a user is a licensee, not an owner of a copy, where the copyright holder specifies that the user is granted a license, significantly restricts the user's ability to transfer the software, and imposes notable use restrictions. That is why software agreements open, almost ritually, with "licensed, not sold" language—it is not throat-clearing; it is the move that preserves the licensor's downstream control.

How the Deployment Model Reshapes Everything

How software reaches the customer changes what the contract has to do, and the three primary models pull the document in different directions.

Software-as-a-service (SaaS) delivers the software over the internet. The vendor hosts the application on infrastructure it controls and the customer reaches it through a browser or thin client. The customer never holds a runnable copy; it consumes a service. That single architectural fact migrates a mountain of responsibility onto the vendor—infrastructure security, availability, maintenance, capacity, and custody of the customer's data—and pushes the contract's center of gravity toward service levels, security standards, data handling, regulatory processing obligations, and the ability to get the data back when the relationship ends. Practitioner guidance recognizes that the priorities in a SaaS deal differ sharply from traditional licensing: where on-premise licensing fixates on configuration, implementation, and acceptance, the top SaaS concerns are availability, data security, data portability, and continuity if the provider falters. Northstar's platform is SaaS, which is why so much of its deal with Brightway will be about uptime, security, and data rather than the mechanics of a delivered copy.

On-premise software is installed on the customer's own servers. The customer receives a copy, runs it on infrastructure it controls, and shoulders the operational burden. The agreement consequently spends its energy on the license grant itself—what the customer may do with the copy it now holds—and far less on operational matters that have become the customer's problem. The grant, the use restrictions, the audit rights, and the maintenance terms carry the weight here.

Hybrid deployments combine the two—an on-premise component talking to a hosted service, say—and force the agreement to address both the license grant for the installed pieces and the service terms for the hosted ones, with careful coordination so the two halves don't contradict each other. The shift in focus across models is best seen side by side:

A drafter who reaches for an on-premise template to paper a SaaS deal—or the reverse—will produce a document that protects against the wrong risks. Our overview of software licensing agreements walks the model-by-model differences in more depth; here the point is that the deployment model is the first fork in the road, and it determines which of the provisions below actually matter.

The License Grant: Scope, Exclusivity, and the Cost of Ambiguity

The license grant defines the perimeter of permission—what the customer is authorized to do—and getting it precisely right is the single most important act of drafting in the whole agreement. Ambiguity here breeds disputes; an overly narrow grant may not even authorize the customer's intended use; an overly broad one gives away value the vendor meant to sell. A complete grant nails down five dimensions: the rights conveyed (access, use, execute, copy for backup, and so on), the authorized users (named individuals, concurrent seats, or enterprise-wide), the authorized purposes (internal operations, a defined use case, or anything lawful), the authorized territory (named sites, regions, or worldwide), and the term (perpetual, subscription, or fixed). Every one of these is a dial, and the difference between a vendor-favorable grant and a customer-favorable grant is simply how many dials are turned down.

A vendor-favorable grant is narrow on every axis: a "limited, non-exclusive, non-transferable, non-sublicensable license to access and use the Software solely for Customer's internal business operations, solely by the number of Authorized Users specified, and solely during the Subscription Term." Each adjective earns its keep. "Non-transferable" blocks assignment—even in a corporate sale. "Non-sublicensable" blocks extending the software to affiliates or contractors. "Internal business operations" blocks using the platform to serve the customer's own customers (a "service bureau" use the vendor would want to charge separately for). The user cap blocks growth without additional fees. A customer-favorable grant relaxes these: use for "any lawful business purpose," extension to affiliates, authorized contractor access under confidentiality, unlimited or generous user counts, and worldwide reach. The right grant for Northstar and Brightway lives in between and tracks the deal's actual economics—and, critically, every one of these terms is negotiable and should be negotiated against the price, not accepted as immovable.

Exclusivity and the ownership it presupposes

Most software licenses are non-exclusive, and for good reason: the vendor's business model depends on licensing the same code to many customers. But exclusivity sometimes matters—a customer who wants the platform locked away from its direct competitors, or who is paying for a custom build it does not want resold. A customer seeking an exclusive license (whether across the board or only within a defined field of use) has to confirm something many overlook: that the licensor actually has sole ownership or control of the licensed software. If a third party co-owns rights in the code, or if the platform incorporates components the vendor itself licenses from upstream, that third party or co-owner can license the very same software to a competitor for the very same uses—and the customer's "exclusivity" is worth nothing. The exclusivity clause, in other words, is only as good as the vendor's underlying chain of title, which is one more reason the ownership representations and the open-source disclosure (discussed below) belong in the same conversation as the grant. Exclusivity also has a copyright consequence worth knowing: under 17 U.S.C. § 101's definition of a "transfer of copyright ownership," an exclusive license is treated more like a partial assignment and, under § 204(a), must be in a signed writing to be effective—a non-exclusive license need not be.

A worked example: the user count and the affiliate trap

The user-count and affiliate questions are worth walking concretely, because this is exactly where a grant that looked fine at signing quietly becomes a breach. Suppose Northstar's standard grant licenses the platform to "Customer" for a fixed number of named users. Brightway signs, deploys, and a year later acquires a smaller logistics company it wants to fold into the same forecasting system. Under the literal grant, the acquired company is a separate legal entity—not "Customer"—and its employees are not the named users Brightway licensed. Extending the platform to them may breach the agreement and trip Northstar's audit and additional-fee rights. The same trap springs when Brightway hires a third-party logistics contractor to run part of its operation on the platform: a "non-sublicensable" grant limited to Brightway's own internal use may not authorize the contractor's access at all.

None of this means Brightway should refuse the deal. It means Brightway should draft the grant to match how it actually operates—defining "Customer" to include majority-owned affiliates, expressly permitting access by contractors acting on Brightway's behalf under written confidentiality obligations, and choosing a user metric (named users, concurrent users, or a true enterprise license) that accommodates foreseeable growth. Northstar, for its part, will reasonably want each expansion priced, because each one enlarges the value Brightway receives. The negotiation is not whether Brightway can have flexibility; it is pricing that flexibility accurately. And the cost of getting it wrong is not an abstract legal hazard—it is a use the customer assumed was fine surfacing in a vendor audit as a breach and a bill, which is precisely the dispute pattern practitioners see most often when permitted-use language is loose.

Restrictions: tailor them, don't reflexively maximize them

License restrictions define what the customer may not do—typically barring reverse engineering, modification or derivative works, sublicensing or transfer, removal of proprietary notices, "service bureau" use to process third parties' data, and unlawful use. The temptation is to make every restriction maximal, but blanket prohibitions invite negotiation and, worse, can be unenforceable. The reverse-engineering restriction is the classic illustration. The Ninth Circuit held in Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992), and again in Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000), that disassembling object code to study unprotected functional elements and achieve interoperability can be a fair use under 17 U.S.C. § 107. A contract clause purporting to forbid what the copyright law affirmatively allows offers false comfort and may not survive a challenge, which is why careful modern drafting bars reverse engineering "except to the extent that applicable law permits notwithstanding this restriction." A restriction that promises more than the law will back up is a liability dressed as a protection.

Covenant or Condition? The Line That Decides Contract vs. Copyright

Here is a distinction that most price-focused negotiators never see, and that can change a dispute's entire complexion: when a licensee does something the agreement prohibits, is the licensor stuck with an ordinary breach-of-contract claim—or can it sue for copyright infringement, with its statutory damages, fee-shifting, and injunctions?

The answer turns on whether the violated term is a covenant (a contractual promise that sits alongside the license) or a condition (a limit on the scope of the license itself). Cross a covenant and you have broken a promise: the licensor's remedy is contract damages. Cross a condition and you have stepped outside the license entirely—which means you were, in that moment, an infringer, exposed to the far heavier artillery of the Copyright Act.

The Ninth Circuit drew the modern line in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010). MDY sold a bot that automated play in Blizzard's World of Warcraft in violation of the game's terms of use. The court held that not every breach of a license condition gives rise to a copyright claim. To convert a license violation into infringement, the licensor must show a nexus between the condition the licensee violated and the licensor's exclusive rights under § 106—copying, distribution, derivative works, and the rest. Where the breached term merely governs the licensee's conduct without bearing on those exclusive rights, the licensor has a contract claim and only a contract claim. The court reasoned that "[a] copyright holder may grant a nonexclusive license and may simultaneously condition that license," but the remedy depends on whether the condition is tethered to the copyright owner's exclusive rights or is "merely a covenant." (The earlier Sun Microsystems, Inc. v. Microsoft Corp., 188 F.3d 1115 (9th Cir. 1999), had pointed the same way, holding that a licensee's breach yields copyright liability only where the licensee's actions exceed the license's scope.)

Why should a drafter care? Because the choice of words decides which remedy a clause delivers. If Northstar wants its prohibition on, say, exceeding the licensed user count or using the platform to serve third parties to carry the threat of copyright infringement—and the statutory-damages and fee-shifting leverage that comes with it—it should draft that limit as an express condition on the scope of the grant ("Customer's license extends only to use by the Authorized Users and solely for internal operations; any other use is outside the scope of the license granted"), not as a free-standing covenant buried in a list of "Customer shall not" promises. Conversely, Brightway, on the receiving end, should understand that a clause framed as a scope condition turns an ordinary contract dispute into infringement exposure, and may push to recast such terms as covenants. This is invisible to anyone reading only for price, and it is one of the higher-stakes drafting choices in the whole document. Our overview of software licensing agreements returns to the covenant-versus-condition problem in the context of enforcement; for now, the lesson is that how a restriction is phrased can be worth more than the restriction itself.

Service Levels: Turning Marketing Into Obligation

For a SaaS deal, the service-level agreement (SLA) is where a vendor's reliability promises become legally real or remain mere marketing copy. It converts "99.9% uptime" from a sales slide into an enforceable standard with a measurable metric and a defined remedy—which is why it is one of the most consequential parts of Brightway's deal. Availability, the percentage of time the service is operational, is the headline number, and the gap between adjacent tiers is far larger than the decimals suggest:

The jump from 99.9% to 99.99% looks like a single decimal place; it is an order-of-magnitude reduction in permitted downtime. So Brightway should understand exactly what each level buys before negotiating, and should scrutinize the exclusions—scheduled maintenance, "factors outside the vendor's control," customer-caused outages—because vague exclusions are where a vendor quietly reclaims the commitment it appeared to make. When is maintenance "scheduled," and how much notice does it require? What precisely counts as "outside vendor control," and does it sweep in the vendor's own cloud-hosting subcontractor? Those definitions decide whether the availability number means anything at all.

The standard remedy for a missed SLA is the service credit—a credit against future fees that scales with the severity of the shortfall—and its real virtue is that it gives the customer recourse without having to prove damages, which for a transient service interruption is notoriously hard. But Brightway should fight for two things. First, credits meaningful enough to register on Northstar's economics: a token credit creates no incentive to invest in reliability. Second, that credits are not the exclusive remedy for chronic failure—persistent underperformance over a defined window should hand Brightway a termination right, because a customer trapped with an unreliable but credit-paying vendor has no real remedy at all. Sophisticated SLAs reach past availability to response and resolution times keyed to severity, so a critical outage draws a fifteen-minute response while a cosmetic glitch does not. As we'll see when we reach the liability section, the SLA and the limitation-of-liability clause are two halves of one bargain: the service credits often are the customer's only practical remedy for downtime, because the liability clause forecloses everything else.

Data Rights, Privacy, and the Regulatory Layer Underneath

For a SaaS deal, data rights are increasingly the center of gravity, and the questions have sharpened as data became a strategic asset and privacy regulation multiplied. The starting principle should be stated flatly: customer data belongs to the customer, and the vendor gets only the rights it genuinely needs to deliver the service. Implementing that principle takes care. Brightway's ownership clause should reach not just the raw data it inputs but the data derived from it—the analytics, aggregations, models, and insights generated from its information—because without that extension Northstar may concede ownership of the inputs while quietly claiming the derived outputs, which are often the more valuable asset.

The vendor's license to use customer data is where the real fight happens. A narrow license permits use "solely as necessary to provide the Service," expiring when the agreement does. A broad, vendor-favorable license layers on rights to use the data to "improve Vendor's products and services, develop new products and services, and generate aggregated, de-identified benchmarks," and to exploit that aggregated data for any purpose. The broad version is valuable to Northstar and alarming to Brightway, whose supply-chain data is competitively sensitive—the last thing Brightway wants is its data aggregated with rivals' data to improve a product those rivals also buy. This is the exact hazard we develop in our work on trade secrets in the age of remote work and cloud computing: data uploaded to a SaaS platform can include precisely the kind of competitively sensitive material a company would never hand a competitor directly. The usual resolution narrows the improvement right, tightens the definition of "aggregated and de-identified" (with a contractual ban on re-identification), or carves out the customer's most sensitive data categories entirely.

Security provisions should specify the standards the vendor maintains, how they are verified, and what happens after an incident—commonly requiring administrative, technical, and physical safeguards: encryption in transit and at rest, access controls, logging and monitoring, and regular independent assessments, often anchored to a recognized certification such as SOC 2 Type II or ISO/IEC 27001 and benchmarked against a framework like the NIST Cybersecurity Framework. Brightway should confirm that any referenced certification actually covers the service it is buying, since certifications sometimes cover only a slice of a vendor's infrastructure. Breach notification provisions govern the aftermath; a 72-hour notice window—mirroring the GDPR's Article 33 standard and now a common benchmark—with defined content requirements has become a standard customer ask, though vendors push back toward "prompt" or "reasonable" notice. And data portability and transition provisions decide whether Brightway can actually leave: the agreement should guarantee a defined window after termination to export the data in a usable, industry-standard format, with concrete transition assistance, because a customer locked into a proprietary format or facing the loss of extensive configuration is not truly free to switch. The access-to-data fights that erupt when business relationships sour, which we examine in our analysis of data scraping after hiQ v. LinkedIn, are a standing reminder that portability is a provision to win before signing, not after.

Underneath all of this sits a layer of regulatory obligation the contract must absorb rather than ignore. If Brightway's data includes personal information—employee records, contact details, anything identifying individuals—then privacy regimes like the GDPR and state statutes such as the California Consumer Privacy Act impose obligations that flow through to Northstar as the processor of that data. The agreement, or an accompanying data-processing addendum (DPA), should specify the purposes for which Northstar may process personal data, prohibit processing for its own unrelated ends, require Northstar to assist Brightway with data-subject requests and regulatory inquiries, address cross-border-transfer mechanisms (standard contractual clauses and the like) where data moves between jurisdictions, flow those obligations down to any sub-processors, and impose deletion-or-return duties at the end. These are not optional niceties: under several regimes the customer remains legally on the hook for personal data even after handing it to a vendor, so Brightway's own compliance literally depends on Northstar's contractual commitments. A data section that handles ownership and security but says nothing about privacy-law processing leaves a gap that can expose the customer to regulatory liability for the vendor's mishandling of data—which is why, for any deal touching personal information, the DPA belongs in the negotiation from day one.

Intellectual Property Ownership and the Open-Source Minefield

The agreement should cleanly allocate IP ownership—both what exists at the outset and what gets created during the relationship. The standard, generally sensible default is simple: the vendor owns the software and all improvements to it, the customer owns its data, and neither party's pre-existing IP transfers to the other. Complications arrive when custom development or professional services create new IP. Who owns features built specifically for Brightway, or the integrations wiring Northstar's platform into Brightway's systems? A vendor-favorable provision assigns all custom development to the vendor and licenses it back; a customer-favorable one assigns genuinely bespoke deliverables to the customer while preserving the vendor's ownership of its pre-existing tools, methodologies, and general-purpose know-how. Vendors resist broad assignments because they want to reuse customizations across their customer base, and the usual compromise gives the customer ownership of the truly custom work while leaving the vendor its underlying building blocks. (Note the work-made-for-hire wrinkle: under 17 U.S.C. § 101, software developed by an independent contractor is not automatically work made for hire and will not vest in the hiring party absent a signed written assignment—so "Customer owns the deliverables" requires an express assignment clause, not just a recital of intent.)

Modern software is assembled partly from open-source components, and those components carry their own license terms—terms that can reach into and infect the proprietary software combined with them. Permissive licenses (MIT, BSD, Apache 2.0) ask little beyond attribution. But copyleft licenses—the GPL above all—can require that software which incorporates or links to the open-source code be distributed under the same license, including its source-code-disclosure obligation. For a company whose whole business is keeping its source code secret, an undetected GPL component in a shipped product can be a genuine catastrophe, the contract-law equivalent of a structural crack. We map this terrain in detail in open source software and in our practical treatment of open-source licensing landmines in enterprise software development; here the point is what the license agreement should do about it.

A prudent customer obtains a representation that the licensed software contains no open-source components whose terms would (a) require the customer to disclose or license its own proprietary code, (b) prevent it from charging fees for products incorporating the software, or (c) require it to grant patent licenses it does not intend to grant. Sophisticated customers go further and demand an actual software bill of materials—a disclosed list of components and their licenses—so legal review can precede deployment rather than scramble after it. And because the non-infringement warranty and indemnity (below) should expressly reach third-party and open-source components, the open-source provision and the indemnity provision are really one integrated protection: the disclosure tells Brightway what is inside; the warranty and indemnity make Northstar answer if what is inside causes a problem.

Warranties and the UCC's Disclaimer Machinery

These next three provisions—warranties, indemnification, and limitation of liability—allocate the risk of things going wrong, and they are where the most consequential negotiation happens. The saying among technology lawyers is that the legal terms create far more exposure than a few percentage points of price, and these three are why.

Warranties are the vendor's affirmative promises. The core performance warranty is that the software will perform "substantially in accordance with the Documentation"—an objective benchmark (the documentation) softened by a tolerance ("substantially") for trivial deviations—usually paired with a remedy limited to repair, replacement, or refund. Beyond performance, Brightway should secure an authority warranty (that Northstar has the rights to grant the license, which ties back to the exclusivity and chain-of-title concerns above) and, above all, a non-infringement warranty (that the software does not infringe third-party patents, copyrights, trademarks, or trade secrets), which is only meaningful when married to the indemnity discussed next.

Against these express warranties, vendors deploy broad disclaimers of the implied warranties—merchantability and fitness for a particular purpose—and this is where the Uniform Commercial Code does its quiet work. Whether Article 2 even governs a software license is itself contested: courts split on whether licensed software is "goods," and many apply Article 2 by analogy even where they doubt it applies of its own force. (The threshold question of when Article 2 reaches a given transaction is a live one; see Determining Whether UCC Article 2 Governs a Dispute.) But the disclaimer mechanics that drafters borrow come straight from UCC § 2-316, which sets the rules for excluding implied warranties: to disclaim merchantability, the language must mention merchantability and, if written, be conspicuous; to disclaim fitness, the exclusion must be in writing and conspicuous. That statutory "conspicuous" requirement is the entire reason software disclaimers shout in BLOCK CAPITALS—the all-caps block is not stylistic, it is the drafter satisfying § 2-316's conspicuousness standard so a court will enforce the disclaimer. Section 2-316 also blesses the familiar "AS IS" and "WITH ALL FAULTS" formulas as a shorthand way to exclude implied warranties.

The practical takeaway for Brightway is symmetrical to the vendor's: if the implied warranties are being disclaimed (and they almost always are), the express warranties Brightway negotiates have to be substantial enough to compensate for everything being given up. A vendor that disclaims merchantability and fitness and offers only a thin "substantial conformity" warranty has handed the customer very little. And the non-infringement warranty deserves special emphasis precisely because it sits at the intersection of two risks Brightway cannot evaluate on its own: Brightway has no way to know whether Northstar's platform incorporates infringing code, mis-licensed open-source components, or features that read on a competitor's patent—Northstar built it and alone knows what went in. The warranty allocates that informational asymmetry to the party who can actually manage it, and the paired indemnity is what converts the promise into protection. The vendor, for its part, should run a clearance analysis before it ever makes that promise, of the kind we describe in our guide on conducting a freedom-to-operate analysis—because a non-infringement warranty is only as safe as the diligence behind it.

Indemnification: The IP-Infringement Backbone

Indemnification allocates responsibility for third-party claims, and in software the indispensable one is the vendor's indemnity against intellectual-property infringement. Northstar agrees to defend Brightway against claims that the software infringes a third party's IP, to pay the resulting damages and any settlement it approves, and—when a claim arises—to do one of three things: (1) procure the right for Brightway to keep using the software, (2) modify the software to make it non-infringing while preserving functionality, or (3) as a last resort, terminate and refund. That three-step remediation ladder is standard, and its order matters enormously to Brightway: the difference between a vendor that procures a license (Brightway keeps running) and a vendor that simply refunds the prepaid fees (Brightway loses the system its operations now depend on) is the difference between a hiccup and a crisis. Brightway should push to make "modify or procure" the vendor's primary obligations and "terminate and refund" a genuine last resort, ideally with a wind-down period and transition assistance bolted on.

Why does the IP indemnity carry so much weight? Because without it, an infringement suit brought against the software could leave Brightway—a mere user with no ability to fix the code—defending a lawsuit over technology it did not create and cannot change. The warranty-plus-indemnity pairing puts that defense, and that liability, where it belongs: on the party that wrote the code and chose its components. Brightway should also ensure the indemnity survives termination for claims arising during the term, since infringement suits often surface long after deployment.

Vendors will carve out claims arising from (a) the customer's own modifications, (b) combination of the software with non-vendor products, (c) use in violation of the agreement, or (d) failure to install an update that would have cured the infringement. These carve-outs are generally fair—the vendor should not answer for problems the customer caused—but each should be drafted precisely to prevent overreach. A loose "combination" carve-out, for instance, could swallow the indemnity whole, since SaaS platforms are designed to be combined with other systems; Brightway should limit it to combinations that are themselves the cause of the infringement. Vendors will also seek a reciprocal customer indemnity for claims arising from customer data or misuse of the software, which Brightway should narrow to claims actually caused by its own conduct, not anything that merely involves its data.

Limitation of Liability and the Logic of UCC § 2-719

Limitation of liability caps each side's exposure, making risk quantifiable and—just as importantly—insurable. It is among the most heavily negotiated terms in any software deal, and it draws its enforceability framework, again, from the UCC. The standard cap limits each party's total liability to the fees paid in the twelve months preceding the claim, with common variants using total contract value, a multiple of annual fees, or a fixed dollar figure. Alongside the cap sits the consequential-damages exclusion, barring indirect, incidental, special, and punitive damages—lost profits, lost revenue, business interruption. This protects both sides from open-ended exposure, but Brightway should recognize that it strips from recovery precisely its most significant potential losses from a software failure.

The statutory backbone here is UCC § 2-719, which governs contractual modification or limitation of remedies. Section 2-719(1) lets parties agree to substitute remedies and even to make a stated remedy exclusive—which is exactly what a "repair, replace, or refund" warranty remedy does. Section 2-719(3) lets parties limit or exclude consequential damages "unless the limitation or exclusion is unconscionable," and it adds a thumb on the scale: limiting consequential damages for personal injury in consumer goods is prima facie unconscionable, but limiting them for commercial loss is not. That distinction is why a B2B software deal between two sophisticated companies can lawfully exclude all of Brightway's lost-profit exposure, whereas the same exclusion in a consumer product causing injury would be presumptively void.

But § 2-719 carries a famous trap that every drafter should know: subsection (2). If "circumstances cause an exclusive or limited remedy to fail of its essential purpose," the buyer may pursue the Code's ordinary remedies despite the limitation. The classic scenario: the contract limits the buyer to "repair or replacement," but the vendor proves unable to repair or replace the defect after repeated attempts—so the limited remedy delivers nothing, "fails of its essential purpose," and the cap may fall away. Courts divide on whether a failure of the exclusive remedy under § 2-719(2) also voids the separate consequential-damages exclusion under § 2-719(3); some treat the two clauses as independent and enforce the damages exclusion even after the remedy fails, others let the whole limitation collapse together. For Brightway, the lesson is to make sure the warranty's "repair or replace" remedy is backed by a real cure obligation and a fallback (a refund, a termination right) so that it cannot be left holding a remedy that does nothing—and for Northstar, to draft the consequential-damages exclusion as an expressly independent provision that survives even if the repair remedy fails.

The carve-outs: where the cap actually matters

The real battleground is the carve-outs—the categories the parties agree are too important to limit, which sit outside both the cap and the consequential-damages exclusion:

The scope of these carve-outs is fought hard—vendors shrink them, customers expand them—and for Brightway a data-security carve-out matters enormously, because a breach exposing its supply-chain data could generate losses far exceeding one year's fees.

A worked example: when the cap and the carve-outs collide

The abstract clauses sprout teeth the moment a real incident arrives. Suppose Northstar's platform suffers a multi-day outage during Brightway's peak shipping season, and separately, a misconfiguration exposes a slice of Brightway's logistics data to another customer. Two failures, one incident, wildly different outcomes—decided entirely by terms negotiated long before anyone imagined the crisis.

Brightway's losses from the outage—missed shipments, idled trucks, furious downstream customers—are real and large, but they are textbook consequential damages (lost profits, business interruption). The consequential-damages exclusion bars them, so Brightway's recovery for the outage is limited to its SLA service credits, which may amount to a fraction of one month's fees. This is exactly the result the exclusion is designed to produce, and it is why a sophisticated customer never treats the SLA and the liability section as separate negotiations: the service credits are the practical remedy for downtime, because the liability section forecloses everything else. (Unless the chronic-failure termination right kicked in—another reason Brightway wanted it.)

The data exposure lands differently. If Brightway negotiated a data-security carve-out, the misconfiguration may fall outside the cap entirely, exposing Northstar to Brightway's full provable losses—regulatory penalties, breach-notification costs, competitive harm. If Brightway did not secure that carve-out, the identical breach is capped at twelve months' fees no matter how large the damage. Same incident, two halves, two outcomes—decided years earlier at the drafting table. That is the whole argument for treating the liability architecture, not the price, as the most important part of the deal.

Audit Rights: The Vendor's Mirror Image

Most software agreements give the vendor an audit right—the contractual power to inspect the customer's use to confirm it stays within the licensed scope (the right user count, the permitted purposes, no unauthorized affiliates or contractors). For Northstar, the audit right is what gives the license metrics teeth; without it, the carefully drafted user cap is unverifiable and therefore nearly unenforceable. The recurring audit dispute—the one that catches customers flat-footed—is the affiliate-and-contractor scenario sketched earlier: a use Brightway assumed was permitted surfaces in a Northstar audit as overuse, with back-fees and sometimes penalties attached.

Brightway is not powerless against this. A customer should negotiate the audit clause as carefully as the grant: limit audits to reasonable frequency (typically once per year absent suspected breach), require advance written notice, confine the audit to records actually relevant to license compliance, demand confidentiality protection for the customer's information the auditor sees, conduct any on-site audit during business hours with minimal disruption, and—crucially—provide that the customer pays the audit cost only if the audit reveals material underpayment (commonly an overage above 5%), with the vendor bearing the cost otherwise. The remedy for a shortfall should be payment of the true-up fee, not automatic termination or punitive multipliers. Audit rights and the license grant are two ends of the same rope: the grant defines what is permitted, and the audit right is how the vendor checks. Negotiating one without the other leaves a gap that surfaces, predictably, at the worst possible moment.

Source-Code Escrow, SaaS Continuity, and Bankruptcy's § 365(n)

Now the question that keeps a careful customer awake: what happens to Brightway if Northstar fails? A SaaS customer's operations live on the vendor's infrastructure, so the vendor's bankruptcy, acquisition, or simple decision to sunset the product is an existential risk the agreement must confront. The data-portability and transition provisions discussed earlier are the first line of defense. Beyond them lie two more tools, one contractual and one statutory, and they interlock in a way that is easy to get wrong.

Source-code escrow—and the harder problem of SaaS continuity

The traditional tool is source-code escrow. Source code is the human-readable form a programmer writes; a compiler translates it into the object code a machine runs. A vendor virtually never hands customers its source code—source is the "key" a competitor would need to copy, modify, or reverse-engineer the product, and it is typically the vendor's most jealously guarded trade secret. But customers have a legitimate need to reach it in extremis: to maintain or support software the vendor can no longer support. The compromise is escrow. The vendor deposits the source code (and build instructions, dependencies, and documentation) with a neutral escrow agent, who is authorized to release it to the customer only on defined release events—typically the vendor's bankruptcy, a sustained failure to support the product, or its discontinuation. A sophisticated escrow clause does not stop at deposit; it requires periodic verification by the escrow agent that the deposited materials are current and actually buildable, because an escrowed archive that won't compile is a security blanket with no security in it.

Escrow is cleaner for on-premise software than for SaaS, and the reason is architectural. With on-premise software the customer already runs the object code on its own servers; the source code is the only missing piece, so releasing source genuinely restores the customer's ability to maintain the system. With SaaS, the customer holds nothing—not the object code, not the data, not the running environment. Handing a customer raw source code does little good if it cannot stand up the production environment, the databases, the cloud configuration, and the operational scaffolding that made the service run. This is why a distinct market of cloud escrow solutions has emerged, broadly in two flavors. Access solutions place the credentials and keys needed to reach the live, hosted application and its data into escrow, to be released on a trigger so the customer can keep operating the existing environment. Replicate solutions escrow the materials needed to rebuild the production environment—source code plus deployment artifacts, configuration, and dependencies—so the customer (or a substitute host) can stand up its own instance. For Brightway, the right ask depends on how mission-critical the platform is: a non-critical tool may need nothing more than data portability, while a platform its operations depend on may justify a replicate-style cloud-escrow arrangement with verification.

Section 365(n): the statutory backstop drafters must not undermine

Escrow solves the practical problem of getting the materials. It does not, by itself, solve a distinct legal problem: what happens to the license when the vendor files for bankruptcy and its trustee tries to walk away from the contract? Here lies one of the most important—and most overlooked—protections in all of technology licensing, and a cautionary tale about how a single appellate decision reshaped a statute.

Under 11 U.S.C. § 365, a bankruptcy trustee may reject executory contracts the debtor finds burdensome. In Lubrizol Enterprises, Inc. v. Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985), the Fourth Circuit held that a debtor-licensor could reject a technology license, and that rejection stripped the licensee of its right to keep using the licensed technology—leaving the licensee with nothing but a damages claim against an insolvent estate. The decision sent a shudder through every industry built on licensed technology: a licensee could build its entire business on a license, only to lose it overnight if the licensor went bankrupt. Congress responded in 1988 by enacting the Intellectual Property Bankruptcy Protection Act, codified at 11 U.S.C. § 365(n), which gives the licensee of "intellectual property" a choice when the debtor-licensor rejects the license: the licensee may treat the contract as terminated, or it may elect to retain its rights under the license (and any supplementary agreement, such as a related escrow) for the duration of the license term, so long as it keeps paying the royalties. Section 365(n) is, in effect, a statutory shield that lets a licensee hold onto the license the trustee tried to take away.

Two drafting points make this real for Northstar and Brightway. First, a customer should make sure the agreement expressly acknowledges the customer's § 365(n) rights and treats the source-code escrow as a "supplementary agreement" the customer may continue to enforce after rejection—because § 365(n) protects the licensee's retention of rights, and tying the escrow release to that retention strengthens the customer's hand. Second, and more subtly: the statutory definition of "intellectual property" in 11 U.S.C. § 101(35A) lists patents, copyrights, and trade secrets—but conspicuously omits trademarks. For decades that omission left trademark licensees exposed, until the Supreme Court closed the gap in Mission Product Holdings, Inc. v. Tempnology, LLC, 587 U.S. 370 (2019), holding that a debtor-licensor's rejection of a trademark license does not rescind the licensee's rights—rejection is a breach, not a rescission, so the licensee keeps what the license gave it. For a software deal, the upshot is reassuring: the copyrights and trade secrets at the core of the platform fall squarely within § 365(n)'s protection, and any trademark license riding along is now covered by Mission Product. The drafter's job is to make sure the agreement does not inadvertently waive these protections (some vendor forms try) and that the escrow and continuity provisions are structured to work with § 365(n) rather than around it.

The deeper lesson is the same one that runs through this whole article: a customer that has routed its core operations through a third party's software needs a plan for the day that third party can no longer provide it, and the time to build that plan into the agreement is before signing, not in the middle of the vendor's Chapter 11. Treat the exit with the same seriousness as the entry.

Pricing, Renewals, and the Subscription Trap

Two practical concerns sit beneath the legal provisions and deserve their own treatment, because they shape the deal's economics and its resilience.

The first is the subscription-versus-perpetual question, which the shift to SaaS has largely settled but not erased. Traditional on-premise software was often licensed perpetually: the customer paid once and held a lasting right to use that version, buying maintenance and support separately and optionally. SaaS replaced that with the subscription: the customer pays recurring fees for continued access, and when the subscription ends, so does the right to use the software. The trade-offs are real. A subscription converts a capital expense into an operating one and guarantees updates, but the customer never builds an owned asset and stays exposed to price increases at renewal. For Brightway, the recurring model means the negotiation is never truly over—each renewal is a fresh negotiation conducted from a weaker position, because Brightway's operations now depend on the platform. The moment to lock in renewal protections (caps on annual increases, defined renewal pricing, a generous notice window before the auto-renewal deadline) is the initial signing, before that dependence exists. A customer who waits until the first renewal to negotiate price protection has already lost the leverage to get it.

The second concern is the business-continuity architecture we just walked—data portability, escrow, and § 365(n)—which is the answer to the question the subscription model makes unavoidable: the more a customer depends on a vendor it does not control, the more the exit terms matter.

Negotiation Strategy for Both Sides

Understanding the provisions is necessary but not sufficient; favorable terms depend on strategy.

For a customer like Brightway, the guiding principles are four. Prioritize the leverage points. A customer has maximum leverage before signing, so the hard-to-change terms—liability caps, data rights, IP indemnity, exit and continuity—should be won then, even if operational details get filled in later. Negotiate risk, not just price. A 10% discount is cold comfort against a security breach the contract failed to address; the legal terms create more exposure than a few points of fee. Buy verification for sensitive-data deals—audit rights against the vendor's security claims, the right to review SOC 2 reports, penetration-testing assurances. And negotiate the exit before the entry, locking in data portability, transition assistance, escrow, and renewal protection while leverage is highest.

For a vendor like Northstar, the principles mirror those. Standardize where possible, flex where necessary—know which terms are truly load-bearing (IP ownership, scope conditions, payment) and which are genuinely negotiable. Understand the reason behind the customer's pushback, which usually reveals a solution that protects both sides rather than a fight to be won. Price flexibility appropriately, so that accommodations like uncapped data-security liability, custom security commitments, or affiliate access are reflected in the fee. And document negotiated departures cleanly, so that side letters and order forms interact predictably with the base agreement instead of contradicting it. The pitfalls both sides should avoid:

That last row points to a companion document the parties should get right first: before any platform demo, any data sample, any technical deep-dive, the parties exchange confidential information under a nondisclosure agreement, and a weak NDA leaks value before the license is even signed. Our guide on drafting enforceable nondisclosure agreements for technology transactions is the right starting point, because the confidentiality architecture of the NDA and of the license agreement should be consistent rather than contradictory.

Industry-Specific Requirements and Emerging Issues

Certain industries bolt regulatory requirements onto the agreement. Healthcare deals touching protected health information require a HIPAA business-associate agreement (45 C.F.R. Parts 160 and 164) governing how that information is handled, secured, and returned—and the BAA must reach into a cloud vendor's subcontractors. Financial-services deals may need to address Gramm-Leach-Bliley data-protection requirements, SEC recordkeeping rules, and banking-regulator examination rights. Government contracts incorporate Federal Acquisition Regulation provisions, sometimes including unlimited or specially negotiated data rights and cybersecurity requirements (and a customer should beware standard commercial license terms that conflict with federal law and are unenforceable against the government). And international deployments must address data-localization rules and cross-border-transfer mechanisms such as standard contractual clauses—the same transfer-impact terrain that governs any global data flow.

Software licensing also keeps evolving with the technology, and three emerging issues deserve attention. AI and machine-learning components raise sharp new questions about training data and model outputs. Because the IP status of AI outputs remains unsettled—a subject we examine in our work on AI-generated inventions—the agreement should state clearly whether customer data may be used to train the vendor's models (this folds directly into the data-rights fight above) and who owns the models and the outputs. And, as we discuss in copyright infringement claims against generative AI, generative features embedded in a platform raise infringement-liability questions the agreement should answer through warranties and indemnities, not silence. API and integration terms matter more as software operates through interconnected services: API rate limits, versioning, and deprecation timelines can break customers who built dependent integrations, so a customer should negotiate notice periods and backward-compatibility commitments. And usage-based pricing introduces new dynamics as fees scale with consumption; customers should negotiate growth protections, price caps, and—pointedly—audit rights over the vendor's usage measurement itself, since the meter is now the price. For Brightway, whose forecasting volume will only grow, the usage-pricing terms may matter as much as the headline rate.

Frequently Asked Questions

Is a software license a sale of the software? No—and the distinction is foundational. Under copyright law the customer receives a license, a grant of permission, while the vendor keeps ownership. Courts generally enforce "licensed, not sold" terms, which keeps the customer from invoking the first-sale doctrine of 17 U.S.C. § 109 to resell or transfer the software. Vernor v. Autodesk, 621 F.3d 1102 (9th Cir. 2010), supplies the test for when a user is a licensee rather than an owner of a copy.

Why does it matter whether a license term is a "covenant" or a "condition"? Because it decides the remedy. Breach a covenant and the licensor has an ordinary contract claim. Breach a condition on the license's scope—and where that condition is tied to the licensor's exclusive copyright rights—and the licensee was, in that moment, an infringer, exposing it to the Copyright Act's statutory damages and fee-shifting. MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010), requires a nexus between the violated condition and the copyright owner's exclusive rights. Drafters who want a restriction to carry infringement teeth must phrase it as a scope condition, not a free-floating promise.

Can a software vendor really disclaim all the implied warranties? Largely, yes—if it does so correctly. UCC § 2-316 lets a seller exclude the implied warranties of merchantability and fitness, provided the merchantability disclaimer mentions merchantability and (if written) is conspicuous, and the fitness disclaimer is conspicuous and in writing. That conspicuousness requirement is why software disclaimers appear in ALL CAPS. The customer's defense is to negotiate express warranties substantial enough to compensate for the implied ones being given up.

What happens to my software license if the vendor goes bankrupt? You may be protected by 11 U.S.C. § 365(n). If the bankrupt licensor's trustee rejects the license, a licensee of patents, copyrights, or trade secrets may elect to retain its rights under the license for the remaining term by continuing to pay royalties—a statutory shield Congress enacted in 1988 to overrule Lubrizol Enterprises, Inc. v. Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985). For trademark licenses (excluded from § 365(n)'s definition of "intellectual property"), Mission Product Holdings, Inc. v. Tempnology, LLC, 587 U.S. 370 (2019), reaches the same result: rejection is a breach, not a rescission, so the licensee keeps its rights. Pair these protections with a verified source-code or cloud-escrow arrangement, and make sure the agreement does not waive them.

Is source-code escrow worth it for a SaaS deal? Sometimes. Traditional source-code escrow works best for on-premise software, where the customer already runs the object code and only needs the source to maintain it. For SaaS, where the customer holds nothing, raw source code alone may not let it stand the service back up—which is why cloud escrow solutions exist in "access" form (escrowing the credentials to keep the live environment running) and "replicate" form (escrowing the materials to rebuild the production environment). Tie the value of escrow to how mission-critical the platform is, and insist on verification so the escrowed materials actually work.

What is the single most important thing a customer can negotiate? There is no one answer, but the closest is the liability architecture—the cap, the consequential-damages exclusion, and above all the carve-outs (IP indemnity, data security, confidentiality). For most software failures, what the customer can actually recover is decided not by the warranty or the SLA in isolation but by where the liability lines were drawn, and those lines are negotiated long before any dispute. A data-security carve-out, in particular, can be worth more than every price concession combined.

Conclusion: The Deal Both Sides Can Live With

Software license agreements govern relationships that are critical to both sides at once—the vendor's business depends on the licensing revenue, and the customer's operations depend on the software working. Getting them right requires more than contract law; it requires understanding the deployment model, the legitimate interests of both parties, the doctrinal machinery (copyright's exclusive rights, the covenant-condition line, the UCC's disclaimer and remedy rules, bankruptcy's § 365(n)), and the specific risks careful drafting can actually address.

The best agreements are not the ones where a vendor extracts maximum advantage from a customer who did not read the form, nor the ones where a customer wins terms that leave the vendor unable to operate. They are the ones that create clear mutual understanding, allocate each risk to the party best able to manage it, and build sensible frameworks for the problems that will inevitably arise. For Northstar and Brightway, the deal that lasts is the one in which the grant matches how Brightway actually operates, the uptime commitments are real, the data rights are clear, the warranties and indemnities cover what Brightway cannot evaluate on its own, the liability is allocated where each party can carry it, and the exit—escrow, portability, and bankruptcy protection included—is workable. That is the deal both sides can live with long after the signatures dry.

For help drafting or negotiating a software license, SaaS, or technology-transaction agreement, contact our intellectual property and technology practice.

Related Articles

• Software licensing agreements — the model-by-model overview and the enforcement doctrine behind the grant.
• Software license agreement review checklists: a complete toolkit — a clause-by-clause review tool to run against any draft.
• Legal protection of software: copyrights, patents, trade secrets, and contracts — how to protect the asset you are licensing.
• Open source software and open-source licensing landmines in enterprise software development — the copyleft hazards to flush out before deployment.
• Drafting enforceable nondisclosure agreements for technology transactions — the confidentiality architecture that should precede and align with the license.
• Conducting a freedom-to-operate analysis for new products — the clearance work behind a non-infringement warranty.
• Trade secrets in the age of remote work and cloud computing and data scraping after hiQ v. LinkedIn — the data-protection and data-access dimensions.

Selected Authorities

Copyright Act of 1976, 17 U.S.C. §§ 101, 106, 109, 117, 204(a), 412, 504; Uniform Commercial Code §§ 2-316 (warranty disclaimers) and 2-719 (remedy limitations and failure of essential purpose); 11 U.S.C. §§ 101(35A), 365, 365(n) (Intellectual Property Bankruptcy Protection Act of 1988). MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010); Sun Microsystems, Inc. v. Microsoft Corp., 188 F.3d 1115 (9th Cir. 1999); Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010); 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); Lubrizol Enterprises, Inc. v. Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985); Mission Product Holdings, Inc. v. Tempnology, LLC, 587 U.S. 370 (2019). HIPAA (45 C.F.R. Parts 160 and 164); Gramm-Leach-Bliley Act; Federal Acquisition Regulation (FAR); GDPR (incl. Arts. 28, 33); California Consumer Privacy Act; NIST Cybersecurity Framework (https://www.nist.gov/cyberframework); SOC 2 and ISO/IEC 27001.

This article is for general informational purposes only and does not constitute legal advice, nor does it create an attorney-client relationship. Software licensing and technology-transaction law vary by jurisdiction and continue to evolve, and the sample provisions described are illustrative rather than a substitute for counsel. The companies and transaction described are fictional and used for illustration only. Consult a qualified attorney to draft or review a software license agreement for your specific transaction.