Here is a fact that surprises almost everyone the first time they hear it: when you "buy" software, you almost never buy anything at all. You buy permission. The shrink-wrapped box, the App Store download, the enterprise system your company runs payroll on, the spreadsheet on your laptop, the cloud platform your startup is built on top of—in the overwhelming majority of cases, you do not own a single one of them. You own a license. Someone else still owns the software, and you have been granted a carefully bounded right to use it, on their terms, for as long as they say.

That one design decision—license instead of sale—is the secret engine of the entire software economy. It is why a video game costs the same whether one person or ten thousand could theoretically run a copy. It is why a vendor can charge you again next year for software you "already have." It is why reselling your old copy of an expensive design program can land you in federal court. And it is why software contracts read the way they do: dense, lopsided, and full of words like "grant," "scope," "field of use," "indemnify," and "limitation of liability" that quietly decide who wins when something goes wrong.

This guide is a tour of that machinery. We will start with the foundational question—license or sale?—and the copyright doctrine that makes it matter. We will dissect the license grant itself, the part that almost everyone skips and almost everyone should read. We will compare the major commercial models, from the old perpetual license to the modern subscription and the cloud-native software-as-a-service (SaaS) arrangement. We will work through how courts decide whether the "I Agree" button you clicked actually formed a contract—the surprisingly rich law of clickwrap and browsewrap. And we will walk the heavily negotiated risk clauses that buyers ignore at their peril: warranties, intellectual-property indemnities, limitations of liability, maintenance and service levels, source-code escrow, audit rights, assignment, and the data and privacy terms that have become the new battleground.

The aim is to make you fluent. Whether you are a founder about to sign your first enterprise contract, a developer drafting your own end-user license agreement (EULA), in-house counsel triaging a stack of vendor paper, or simply a curious person who has clicked "I Agree" ten thousand times without reading a word, by the end you will understand what these documents are doing and why. For the companion deep-dives—a clause-by-clause drafting playbook and a reviewer's checklist—see our pieces on drafting software license agreements and key negotiation points and the software license agreement review checklist toolkit. This article is the conceptual map; those are the field manuals.

Why Software Is Licensed and Not Sold

To understand software licensing, you first have to understand a piece of copyright law called the first-sale doctrine. It is the reason the entire industry chose licensing over selling, and it explains a remarkable amount about how your software behaves.

Copyright, the bundle of rights, and the "exhaustion" trap

When someone writes original software, copyright protection attaches automatically the moment the code is fixed in a tangible form—saved to a disk, committed to a repository, typed into an editor. (Software is treated as a "literary work" under the Copyright Act; for the mechanics of protecting and registering it, see our guides on the copyright registration of computer programs and the broader legal protection of software through copyrights, patents, trade secrets, and contracts.) Copyright gives the owner a bundle of exclusive rights under 17 U.S.C. § 106: the right to reproduce the work, to distribute copies, to make derivative works, to perform it, and to display it publicly.

But that bundle has a built-in escape valve. The first-sale doctrine, codified at 17 U.S.C. § 109(a), says that once the copyright owner sells a particular copy of a work, the owner's distribution right in that copy is "exhausted." The buyer can then resell, lend, or give away that specific copy without permission. This is why used-bookstores, libraries, and the secondary market in vinyl records are all perfectly legal. You bought the copy; it's yours to pass along.

Now imagine that doctrine applied with full force to software. A company spends millions developing an enterprise platform and sells a copy for $50,000. Under first sale, the buyer could turn around and resell that copy on the open market. A robust secondary market would form. Prices would collapse. The developer's revenue would crater. From the vendor's perspective, first sale is a threat to be neutralized.

The neutralizing move is elegant: don't sell the copy—license it. If the transaction is a license rather than a sale, then no "sale" has occurred, the distribution right is never exhausted, and the first-sale doctrine never kicks in. The user holds only the rights the license grants and nothing more. That is the foundational reason your software agreement insists, sometimes in bold capital letters, that the software is "licensed, not sold." It is not lawyer boilerplate. It is the load-bearing wall of the whole structure.

Vernor v. Autodesk: when does a "license" really count as one?

For years there was real uncertainty about whether courts would honor the "license, not sale" label or look past it to the economic reality. The leading answer in the United States came from the Ninth Circuit in Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010).

The facts are a tidy little drama. Autodesk makes AutoCAD, expensive professional design software distributed under a detailed license that called the transaction a license, prohibited transfer of the copies without consent, and imposed significant use restrictions. An architecture firm had several copies. Timothy Vernor, a savvy reseller, acquired used copies (at an office sale and otherwise) and tried to resell them on eBay. Autodesk sent takedown notices. Vernor sued for a declaration that his resales were lawful under the first-sale doctrine—his theory being that the original transaction to the architecture firm was really a sale, so first sale applied and he could resell freely.

The Ninth Circuit disagreed and laid down a three-factor test for distinguishing a licensee from an owner. A software user is a licensee rather than an owner of a copy when the copyright owner (1) specifies that the user is granted a license; (2) significantly restricts the user's ability to transfer the software; and (3) imposes notable use restrictions. Vernor, 621 F.3d at 1111. Because Autodesk's agreement did all three, the architecture firm was a licensee, never an owner; there was never a "first sale"; and Vernor could not invoke § 109(a). His resales infringed Autodesk's distribution right.

The practical upshot is that, in the Ninth Circuit and the many courts that have followed Vernor, a well-drafted license that names itself a license, restricts transfer, and restricts use will defeat the first-sale doctrine. That is enormously consequential. It means software resale markets are largely foreclosed, that a licensee cannot necessarily transfer software even in an asset sale, and that the vendor retains control over downstream distribution essentially forever. (Note that the law is not perfectly uniform—some courts and commentators have criticized Vernor as elevating form over economic substance, and outcomes can differ in other circuits and especially abroad. In the European Union, for example, the Court of Justice's UsedSoft v. Oracle decision reached a strikingly different result for downloaded software, finding an exhaustion of the distribution right. Always check the governing law and forum.)

Why this matters before you read a single clause

Carry this insight into every software contract you encounter: the license grant is the heart of the deal, and the "license not sale" framing means your rights are exactly what the contract gives you and not one inch more. There is no default reservoir of ownership rights to fall back on. If the agreement does not let you copy the software onto a backup server, you may not have that right. If it does not let you assign the license to a buyer of your business, you may not be able to. Everything flows from the grant. So let us read it carefully.

Anatomy of the License Grant

Most software agreements bury their single most important sentence in the middle of a paragraph headed "Grant of License" or "License." It usually reads something like: "Subject to the terms of this Agreement, Licensor hereby grants Licensee a [non-exclusive], [non-transferable], [revocable] license to use the Software [for internal business purposes only] [in the Territory] [during the Term]." Every bracketed word is a negotiated lever. Let's pull each one.

Scope: what you may actually do

"Use" is not self-defining. A grant should specify the permitted uses with precision because, under the "license not sale" logic, anything not granted is reserved. Common scope dimensions include:

  • Permitted acts: May the licensee install, execute, copy (for backup or disaster recovery), modify, create derivative works, reverse-engineer, or sublicense? Each is a distinct right under § 106 and must be expressly granted to be enjoyed. Reverse-engineering and modification are frequently prohibited in proprietary deals; backup copies are frequently permitted.
  • Purpose: "Internal business purposes only" is a classic limitation that prevents the licensee from using the software to provide services to third parties (a "service bureau" use) or to compete with the licensor.
  • Number and identity of users or installations: The grant is often tied to a defined metric—named users, concurrent users, devices, servers, CPUs, cores, or transaction volume. Exceed the metric and you are out of scope, which is both a breach and, ominously, copyright infringement (more on that in the audit section).

A licensee wants the grant broad and the metric generous and easy to measure; a licensor wants it narrow and tied to a metric that scales with the licensee's growth. This is the negotiation our drafting and negotiation guide covers clause by clause.

Exclusivity: exclusive, sole, or non-exclusive

Most software licenses are non-exclusive—the licensor can grant the same rights to anyone else, which is the entire point of selling software to a mass market. Occasionally a licensee negotiates an exclusive license, meaning the licensor cannot license the same software to anyone else (sometimes not even use it itself) within a defined scope. A middle ground is a sole license, where the licensor may continue to use the software itself but will not license it to other third parties.

Exclusivity is expensive and consequential. An exclusive licensee of a copyright is treated as a legal owner of the licensed rights to the extent of the grant and can, in many cases, sue infringers in its own name—so exclusivity is not merely a commercial preference but a question of who controls enforcement. Exclusive arrangements are common in OEM, white-label, and vertical-market deals (e.g., "you have the exclusive right to embed our engine in point-of-sale terminals for the North American restaurant market").

Field of use: slicing the rights by purpose

A field-of-use restriction limits the license to a particular industry, application, or market. The same software might be licensed to one company for healthcare applications and to another for logistics, with each field carved out and priced separately. Field-of-use restrictions let a licensor monetize the same code across many markets while letting a licensee pay only for what it needs. They are common in technology-rich licensing and overlap conceptually with patent licensing fields; if you are licensing patented technology alongside software, see our guide on how to license your patent from valuation to term sheet.

Territory: where the license runs

A territory clause defines the geography in which the licensee may use or distribute the software—worldwide, the United States, the EU, a specific country. Territory matters more in distribution and OEM deals than in a simple internal-use license, but cloud and data-residency rules have made geography newly important even for ordinary use. If a vendor's territory is "United States only" and your team in Frankfurt logs in, you may be out of scope.

Term: how long the license lasts

The term is the duration of the license, and it is the single dimension that most distinguishes the commercial models we turn to next. A perpetual license never expires (though support and maintenance usually do). A fixed-term or subscription license lasts a defined period—monthly, annually, multi-year—and ends unless renewed. The term provision interacts tightly with payment, termination, and what happens to the licensee's data and access when the music stops.

Transferability and sublicensing

Because of Vernor, transfer restrictions are doing double duty: they protect the vendor's business model and they are part of what makes the transaction a "license" rather than a "sale" in the first place. A license that is "non-transferable" cannot be assigned to another person or entity without consent. A grant that includes sublicensing rights lets the licensee grant downstream licenses—essential if the licensee is, say, embedding the software in a product it sells, but something licensors guard carefully. We return to assignment and change-of-control in detail below because it is one of the most litigated and least-read clauses in the entire document.

The Commercial Models: Perpetual, Subscription, SaaS, and How You Pay

The license grant tells you what you may do. The commercial model tells you how long, how you pay, and where the software lives. These have evolved dramatically over the last two decades, and the model shapes nearly every other clause.

The perpetual license: buy once, own (a license) forever

The classic enterprise model is the perpetual license: the licensee pays a large up-front fee for a license that never expires. The software typically runs on-premises—installed on the licensee's own servers or machines. The licensee usually also pays an annual maintenance and support fee (often a percentage of the license fee, historically around 18–22%) to receive updates, patches, and help-desk support. Stop paying maintenance and you keep the software but lose the updates and support.

Perpetual licensing is licensee-friendly in one important way: you have a durable asset and you are not at the mercy of a renewal negotiation. Its downside, from the vendor's perspective, is lumpy, unpredictable revenue, which is precisely why the industry has migrated away from it.

The subscription license: rent, don't buy

A subscription (or term) license flips the economics. Instead of a large up-front fee, the licensee pays a recurring fee—monthly or annually—for a license that lasts only as long as payment continues. The software may still run on-premises, but access ends when the subscription ends. Subscriptions smooth revenue for vendors, lower the entry cost for customers, and create a recurring relationship. They have become the default for most modern software.

Software-as-a-Service (SaaS): you don't even get the software

The most significant shift is SaaS, where the customer does not receive a copy of the software at all. The software runs on the provider's (or a cloud provider's) infrastructure, and the customer accesses it over the internet, typically through a browser. There is nothing to install, nothing to copy, often nothing the first-sale doctrine could even attach to.

This matters legally. A pure SaaS arrangement is sometimes characterized less as a copyright license and more as a service contract—the customer is buying access to a service, not a license to reproduce a work. (Many SaaS agreements still include a license grant for any downloadable components, agents, or APIs, and for the user-facing interface.) The vendor controls the single hosted instance, updates it continuously, and never relinquishes a copy. SaaS agreements consequently emphasize a different set of terms: uptime and service-level agreements (SLAs), data ownership and portability, security, privacy, and what happens to the customer's data on termination. The center of gravity moves from "what may I do with this copy?" to "what happens to my data and my access?"

If your transaction is SaaS, recognize that much of the classic on-premises license vocabulary still applies, but the data and exit terms become paramount. The review checklist toolkit breaks out SaaS-specific diligence items.

Pricing metrics: seats, usage, and everything in between

Independent of the model, the pricing metric determines what you actually pay for:

  • Per-seat / named-user: a fixed price per identified individual.
  • Concurrent-user: priced on the number of simultaneous users, which can be cheaper for organizations with many occasional users.
  • Usage / consumption-based: priced on transactions, API calls, compute, storage, or some other meter—increasingly common in cloud and AI tooling.
  • Per-device / per-core / per-CPU: classic for infrastructure software.
  • Enterprise / site license: a flat fee for unlimited use within the organization.
  • Freemium and tiered: a free base tier with paid upgrades.

The metric is not a footnote; it is where audit disputes are born. A vague or hard-to-measure metric ("per business unit," "per affiliate") is a future fight. Define it precisely and make it auditable in your own favor.

Proprietary vs. Open Source: Two Philosophies of Licensing

Everything above assumes proprietary software—the vendor keeps the source code secret and grants narrow rights for a fee. There is a whole parallel universe: open source software (OSS), where the source code is public and the license grants broad rights to use, study, modify, and redistribute the code, usually at no charge, subject to conditions.

Open source is not the absence of a license; it is a different kind of license, and the conditions matter intensely. Broadly, OSS licenses fall into two camps:

  • Permissive licenses (MIT, BSD, Apache 2.0) let you do almost anything—including incorporating the code into proprietary products—so long as you preserve attribution and copyright notices. Apache 2.0 adds an express patent license and patent-retaliation provision.
  • Copyleft licenses (the GPL family, LGPL, AGPL, MPL) attach a viral condition: if you distribute software that incorporates copyleft code, you may be required to license your derivative work under the same terms, including releasing your own source code. The strength of this obligation varies—GPL is strong copyleft, LGPL is weaker (it lets you link to a library without infecting your whole program, with version-specific nuances), and MPL is file-level copyleft.

The danger in enterprise software is mixing these incompatibly. The original source material for this article wrestled with exactly that problem: code under LGPLv2.1 cannot freely incorporate Apache 2.0 code, while LGPLv3 can; combine a permissively licensed component with a strong-copyleft component and the resulting derivative work may inherit the more restrictive license. Get the combination wrong and a company can find that its proprietary "secret sauce" must, by the terms of a license it never read, be released as open source—or that it is distributing in violation of the license and exposed to an infringement claim.

This is not theoretical. Open source compliance failures surface in due diligence during acquisitions and financings and can derail deals. For the practical landmines and how to avoid them, see our dedicated pieces on open source licensing landmines in enterprise software development and the complete collection of open source compliance checklists. The headline lesson: open source is "free" like a puppy, not free like beer. It comes with obligations, and a serious software organization needs a policy and an inventory.

Clickwrap, Browsewrap, and the Law of "I Agree"

We now arrive at the question that touches every person reading this: when you click "I Agree," or just keep using a website, have you actually formed a binding contract? This is the law of online contract formation, and it is one of the more fascinating corners of contract law because it forces ancient doctrine—offer, acceptance, mutual assent, notice—onto a brand-new medium.

From shrink-wrap to clickwrap: ProCD v. Zeidenberg

The story begins in the 1990s with shrink-wrap licenses—terms printed inside a software box or displayed during installation, which the buyer could not read until after purchase. Were they enforceable? The seminal case is ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), an opinion by Judge Frank Easterbrook that anyone interested in software contracts should read.

ProCD compiled a telephone-directory database and sold it on CD-ROM with two price tiers: a cheap consumer version and an expensive commercial one. Every box contained a license—visible on the outside, repeated on the screen at startup—restricting use to non-commercial purposes. Matthew Zeidenberg bought the consumer version, ignored the license, and put the data on a website for a fee. ProCD sued. Zeidenberg argued the license terms inside the box could not bind him because he didn't see them until after he paid.

Judge Easterbrook rejected that argument with a now-famous analysis. Plenty of everyday contracts present terms after the initial payment—an airline ticket, a concert ticket, an insurance policy, a box of software—and they are routinely enforced so long as the buyer has the opportunity to review the terms and reject the deal (here, by returning the software). The court held that the shrink-wrap license was an enforceable contract: ProCD made an offer (the software plus the terms), and Zeidenberg accepted by using the software after having the chance to read and reject the terms. ProCD, 86 F.3d at 1452–53. The court also held that the contract claim was not preempted by federal copyright law, because a contract creates rights against the contracting party, not rights "equivalent to" copyright against the world.

ProCD established the principle that terms presented after payment can still bind a buyer who has a meaningful opportunity to review and reject them. That principle migrated directly to the internet.

Clickwrap: the gold standard of online assent

The online descendant of the shrink-wrap is the clickwrap (or "click-through") agreement: the terms are displayed on the screen and the user must take an affirmative action—clicking a box or a button labeled "I Agree," "I Accept," or "Continue"—to proceed. Crucially, the user cannot get the software or service without clicking.

Clickwrap agreements are routinely enforced. Courts treat the affirmative click as classic acceptance: the user was presented with the terms (or a conspicuous link to them) and manifested assent by clicking. The reliability is high enough that clickwrap is the recommended design pattern for any EULA, SaaS sign-up, or terms-of-service acceptance. The Practical Law standard documents in this area—clickwrap EULAs, clickwrap cloud-services agreements, clickwrap API license agreements—are all built on this foundation precisely because the affirmative-click model is the most defensible. The drafting craft lies in making the assent unambiguous: terms (or a clear, working link) presented before the click, a button that requires a deliberate act, and a record that the user clicked.

Browsewrap: the weak cousin, and Specht v. Netscape

At the opposite, far weaker end is the browsewrap agreement: terms posted somewhere on a website (often a small "Terms of Use" link in the footer) that purport to bind the user merely by using the site—no click, no affirmative action required. The user need never see the terms, let alone agree to them. Courts are deeply skeptical of browsewrap because the bedrock of contract is mutual assent, and it is hard to find assent in a user who never saw and never agreed to anything.

The foundational case is Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), an opinion by then-Judge Sonia Sotomayor. Netscape offered free downloadable software ("SmartDownload"). Users clicked a "Download" button to get it. The license terms—including an arbitration clause Netscape wanted to enforce—were not on the download screen; a reference to them sat below the download button, where a user would have to scroll down to even notice it. Nothing required the user to view or assent to the terms before downloading.

The Second Circuit refused to enforce the arbitration clause. The court held that a consumer's mere act of downloading did not manifest assent to terms the consumer had no reason to know existed: "a reasonably prudent offeree in plaintiffs' position would not have known or learned, prior to acting on the invitation to download, of the reference to [the] license terms." Specht, 306 F.3d at 20, 31–32. Where terms are submerged below the point of action and require no affirmative agreement, there is no contract. Specht is the cautionary tale that every browsewrap design should be measured against.

Nguyen v. Barnes & Noble and the modern "inquiry notice" test

The principle crystallized further in Nguyen v. Barnes & Noble, Inc., 763 F.3d 1171 (9th Cir. 2014). A customer canceled order, then sued; Barnes & Noble tried to compel arbitration based on its website's Terms of Use, which were available via hyperlinks but to which the user never affirmatively agreed. The Ninth Circuit held the browsewrap unenforceable, articulating the governing standard plainly: where a website offers a browsewrap with no affirmative assent, enforceability "turns on whether the website puts a reasonably prudent user on inquiry notice of the terms of the contract." Nguyen, 763 F.3d at 1176–77. The mere existence of a Terms link, even one in proximity to relevant buttons, was not enough to bind a user who never clicked anything indicating agreement.

The synthesis across these cases is a spectrum:

  • Clickwrap (affirmative click to accept conspicuous terms): almost always enforceable.
  • "Sign-in wrap" (a notice like "By clicking Continue you agree to our Terms," next to a button): often enforceable if the notice is conspicuous and the link is clear—courts increasingly scrutinize the design, font, color, and placement.
  • Pure browsewrap (terms in a footer link, no action required): usually unenforceable against ordinary consumers, unless the user had actual or clear inquiry notice.

The practical drafting lesson is unambiguous: if you want your terms to bind users, use clickwrap. Present the terms conspicuously, require a deliberate affirmative act, and keep a record of it. Courts also continue to police even clickwrap for unconscionability and for terms that are oppressive or that hide important provisions (mandatory arbitration, class-action waivers, liability disclaimers) in ways that surprise a reasonable user. Conspicuousness and clarity protect enforceability. For the consumer-facing dimension of online terms and platform rules, see our overview of social media law basics and the discussion of terms-of-service licenses in copyright registration of websites and website content.

A worked example. Imagine "Acme Analytics, Inc." launches a free trial of its dashboard. Design A: the sign-up page shows the full terms in a scroll box and a checkbox reading "I have read and agree to the Terms of Service," unchecked by default, which the user must check to create an account—and Acme logs the timestamp. Design B: the sign-up page has only a "Create Account" button, with a faint gray "Terms" link in the footer. When a customer later disputes an arbitration clause, Acme will likely win under Design A (clickwrap, affirmative assent, a record) and likely lose under Design B (pure browsewrap, no assent, Specht and Nguyen squarely on point). Same clause, opposite outcomes—because of formation design, not the clause's content.

Risk Allocation: Warranties, IP Indemnity, and Limitation of Liability

If the license grant is the heart of the agreement, the risk-allocation clauses are its nervous system. They decide who bears the loss when the software is defective, when it infringes someone else's intellectual property, or when something goes catastrophically wrong. These three clauses—warranties, indemnification, and limitation of liability—are the most heavily negotiated terms in any serious software deal, and they should be read together, because they interlock.

Warranties: what the vendor promises about the software

A warranty is a contractual promise about the software's qualities or performance; breaching it gives the other party a remedy. Common software warranties include:

  • A performance warranty that the software will conform to its documentation or specifications for a defined period.
  • A non-infringement warranty that the software does not infringe third-party IP (closely tied to the indemnity below).
  • An authority warranty that the licensor has the right to grant the license.
  • A disabling-code / no-malware warranty that the software contains no viruses, time bombs, back doors, or other harmful code.
  • An open source warranty that the software does not include OSS that would require disclosure of the licensee's proprietary code—an increasingly important promise.

Equally important is what the agreement disclaims. Most licensor-friendly agreements include a sweeping disclaimer, often in capital letters, of all implied warranties—particularly the implied warranties of merchantability (that the goods are fit for ordinary purposes) and fitness for a particular purpose that arise under the Uniform Commercial Code (UCC) when it applies. Whether the UCC's Article 2 (sale of goods) even governs a software license is itself a contested question—courts split on whether software is a "good," a service, or a hybrid, and the answer can vary by jurisdiction and by whether the software is mass-market or custom. Because of that uncertainty, vendors disclaim implied warranties expressly rather than rely on the default. The disclaimer must generally be conspicuous (hence the capital letters) to be effective. A licensee should resist a blanket "AS IS" disclaimer and negotiate, at minimum, a performance warranty tied to the documentation.

IP indemnification: who defends you if the software is sued

An indemnification clause is a promise by one party to cover the other's losses from specified claims—to step in, defend the lawsuit, and pay the judgment or settlement. In software licensing, the centerpiece is the IP indemnity: the licensor agrees to defend and indemnify the licensee against third-party claims that the software infringes a patent, copyright, trademark, or trade secret.

This indemnity is enormously valuable to a licensee. If a patent troll sues you because the software you licensed allegedly infringes a patent, the IP indemnity shifts that defense and liability to the vendor who actually wrote and controls the code. A well-drafted IP indemnity addresses:

  • Scope: which IP rights are covered (patents, copyrights, trade secrets, trademarks) and which territories.
  • Procedure: prompt notice, control of the defense, cooperation, and consent rights over settlements.
  • Remedies / mitigation: if an infringement claim succeeds, the licensor typically reserves the right to (a) procure a license so the licensee can keep using the software, (b) modify or replace the software to be non-infringing, or (c) as a last resort, terminate and refund some portion of the fees. The order and generosity of these options matter.
  • Exclusions: indemnity usually does not cover infringement caused by the licensee's modifications, combinations with non-licensed products, or use outside the license scope. Open source components are often carved out, which is one more reason to know what OSS is inside.

A licensee should make sure the indemnity is not gutted by exclusions and that it survives termination as to claims arising during the term. For the underlying mechanics of IP claims that these indemnities are designed to absorb, see what constitutes patent infringement and the consequences of pirating intellectual property.

Limitation of liability: the cap that swallows everything

The limitation of liability clause is, dollar for dollar, often the most consequential sentence in the contract. It does two things. First, it excludes certain categories of damages—almost always consequential, incidental, indirect, special, and punitive damages, and frequently lost profits, lost data, and loss of goodwill. Second, it caps the total liability at a dollar figure—commonly the fees paid in the preceding 12 months, or the total fees paid, or some multiple thereof.

The effect can be stark. Suppose a defect in licensed software corrupts a licensee's database and costs the business $5 million in lost orders. If the agreement excludes consequential damages and lost profits and caps liability at the $100,000 in annual fees, the licensee's maximum recovery is $100,000, no matter how badly the software failed. That is not a drafting accident; it is the deal the parties struck (or that the licensee signed without reading).

Courts generally enforce limitation-of-liability clauses between sophisticated commercial parties as a legitimate allocation of risk, reasoning that the price reflects the risk allocation—cheap software comes with a low cap. But there are limits: many agreements carve out certain liabilities from the cap entirely, and a licensee should fight for carve-outs for (i) the IP indemnity, (ii) breaches of confidentiality, (iii) data-security breaches, and (iv) the licensor's gross negligence or willful misconduct. Some jurisdictions also refuse to enforce caps that would exempt a party from liability for gross negligence, fraud, or willful injury, or that cause an exclusive remedy to "fail of its essential purpose" under UCC § 2-719. The negotiation is essentially a tug-of-war over what sits inside the cap and what sits outside it.

A licensee should never read the limitation clause in isolation. A generous IP indemnity is worth little if the liability cap swallows it—so the indemnity must be carved out of the cap, or its protection is illusory. This interlock is exactly the kind of cross-clause analysis the review checklist toolkit is built to catch.

Operational Terms That Quietly Decide Outcomes

The dramatic clauses get the attention, but the operational machinery often determines whether the relationship works in practice. These terms are easy to skim and expensive to ignore.

Maintenance, support, and service levels (SLAs)

For on-premises software, maintenance and support is usually a separate (and separately priced) commitment covering bug fixes, patches, updates, new versions, and help-desk access. Key questions: Are upgrades (major new versions) included, or only updates (patches)? How long must the vendor support older versions? What are the response and resolution times for different severity levels?

For SaaS, the analog is the service-level agreement (SLA), which promises a level of availability (uptime, e.g., "99.9%"), defines how downtime is measured (and what is excluded—scheduled maintenance, force majeure), and specifies service credits as the remedy when the vendor misses the target. A crucial, often-overlooked point: service credits are frequently the sole and exclusive remedy for downtime, and they are typically modest. A licensee that depends on continuous availability should scrutinize whether the credits are meaningful and whether chronic failures permit termination, not just a small refund.

Source-code escrow: insurance against the vendor's disappearance

When a licensee depends on proprietary software but receives only the executable (object) code—not the human-readable source code—it faces a frightening risk: if the vendor goes bankrupt, gets acquired and discontinues the product, or simply abandons it, the licensee may be stranded with critical software it cannot maintain or fix.

The classic solution is a source-code escrow. The vendor deposits a copy of the source code (and build instructions, documentation, and sometimes development tools) with a neutral third-party escrow agent. The escrow agreement specifies release conditions—typically the vendor's bankruptcy, insolvency, cessation of business, or material failure to provide contracted maintenance. If a release condition occurs, the escrow agent releases the source code to the licensee, who can then maintain the software itself. Escrow has migrated to the cloud era too, with arrangements that escrow not just source code but the configurations, scripts, and credentials needed to stand up a SaaS application if the provider fails ("SaaS escrow" or "cloud escrow").

Escrow is not a panacea—the deposit must be verified (escrow agents offer verification services to confirm the deposited code actually compiles into the product), kept current, and paired with a release trigger that bankruptcy law will actually honor. (U.S. bankruptcy law has special provisions, under § 365(n) of the Bankruptcy Code, protecting licensees of intellectual property when a debtor-licensor rejects the license—an important backstop that interacts with escrow.) But for mission-critical software, escrow is cheap insurance against catastrophe.

Audit rights: the clause that bites licensees

Tucked into nearly every proprietary license is an audit clause giving the licensor the right to inspect the licensee's use of the software to verify compliance with the license metrics. This is where the "license not sale" framework becomes teeth: because the licensee holds only the rights the license grants, using more copies or more seats than licensed is not just a breach of contract—it can be copyright infringement, exposing the licensee to statutory damages and the dreaded prospect of a large "true-up" bill.

Software audits are a genuine industry. A vendor (or an industry group acting on vendors' behalf) sends an audit notice; the licensee must account for every installation and user; over-deployment results in a demand for back-license fees, often at list price and sometimes with penalties. Licensees should negotiate audit clauses to limit their burden: reasonable notice, business-hours timing, no more than once per year absent cause, confidentiality of the licensee's data, the licensee's right to use its own records, and a cost-shifting provision under which the vendor pays for the audit unless the audit reveals over-deployment beyond a small threshold. The single best defense, though, is internal: maintain an accurate software asset inventory so an audit holds no surprises.

Assignment and change of control: the clause M&A lawyers lose sleep over

Recall Vernor: transfer restrictions are central to software licensing. The assignment clause governs whether and how a party may transfer the agreement. A typical clause prohibits assignment "without the other party's prior written consent." That sounds innocuous until a licensee tries to sell its business.

Here is the trap. Many software licenses define "assignment" to include a change of control—a merger, a stock sale, or an acquisition of the licensee—even if the contract is not formally "assigned" to anyone. So when "BigCo" acquires "Acme Corp.," Acme's software licenses may, by their terms, require the licensors' consent or terminate automatically. Each affected vendor suddenly holds a veto—or a chance to renegotiate, demand a transfer fee, or extract a price increase—at the worst possible moment. In an acquisition involving hundreds of software contracts, this can become a major diligence and cost item. (The legal subtlety: courts sometimes distinguish a license that is silent on assignment, where federal copyright policy may make non-exclusive licenses non-assignable by default, from express anti-assignment-on-change-of-control language. The drafting choices have real consequences.)

A licensee should negotiate, where possible, the right to assign the license to a successor in a merger or sale of substantially all assets without consent, or at least carve affiliates out of the restriction. A licensor, conversely, wants the change-of-control hook intact—especially to avoid having its software end up in a competitor's hands. For the broader picture of how IP rights travel with business entities, see our deep dive on corporate structuring and running multiple businesses.

Data and privacy: the new center of gravity

Two decades ago, a software license barely mentioned data. Today, especially in SaaS, the data and privacy terms are often the most important provisions in the entire document, because the vendor is processing the customer's (and the customer's customers') personal information.

Key issues to nail down:

  • Data ownership: the customer should retain ownership of its data; the vendor gets only a limited license to process it to provide the service.
  • Permitted use: can the vendor use customer data to "improve the service" or train AI models? This is a hot, contested term—many customers now expressly prohibit use of their data for training general models.
  • Security: specified security standards, breach notification timelines, and audit/certification (SOC 2, ISO 27001) commitments.
  • Privacy compliance: a data processing addendum (DPA) allocating responsibilities under privacy laws like the GDPR (where the vendor is typically a "processor" and the customer a "controller"), the CCPA/CPRA, and others; standard contractual clauses for cross-border transfers.
  • Data portability and deletion on exit: how, in what format, and within what window the customer can retrieve its data when the relationship ends, and the vendor's obligation to delete it thereafter.

Cross-border data flows in particular have become a legal minefield; see our analysis of international data transfers after Schrems II and, for the AI-training dimension, biometric data privacy laws and their impact on AI development. The exit terms deserve special emphasis: in a SaaS deal, the data clause is your insurance policy, because if you cannot get your data out in a usable form, switching vendors becomes nearly impossible regardless of how the rest of the contract reads.

Confidentiality and termination

Two more workhorses round out the operational core. Confidentiality clauses protect each party's non-public information—source code, the contract's pricing, the customer's data—and they pair naturally with trade-secret protection (the source code of proprietary software is typically a trade secret; see protection of trade secrets and drafting enforceable non-disclosure agreements for technology transactions). Termination clauses specify how the relationship ends—for breach (often after a cure period), for convenience (sometimes), for insolvency—and, critically, what happens after: the license ends, the licensee must stop using and destroy or return copies, accrued fees come due, and (in SaaS) the data-return obligations kick in. Read the "Effect of Termination" section as carefully as the grant; it tells you what you walk away with.

Putting It Together: A Reader's Map of a Software License

If you take one structural insight from this guide, let it be this: a software license agreement is not a random pile of clauses. It is an organized answer to a sequence of questions, and you can read any agreement by asking them in order:

  1. Is this a license or a sale, and is it framed to defeat first sale? (Almost always a license; look for the Vernor hallmarks.)
  2. What exactly does the grant let me do—scope, exclusivity, field, territory, term? (Anything not granted is reserved.)
  3. What's the commercial model and metric—perpetual, subscription, or SaaS; per-seat, usage, or enterprise? (This shapes everything downstream.)
  4. Is there open source inside, and what does it require? (Know your bill of materials.)
  5. If this is online, was the contract properly formed—clickwrap, not browsewrap? (Affirmative assent or bust.)
  6. How is risk allocated—warranties, IP indemnity, and the liability cap, read together? (And is the indemnity carved out of the cap?)
  7. What about the operational machinery—support/SLA, escrow, audit, assignment/change of control, and data/privacy? (The quiet clauses that decide real outcomes.)
  8. What happens when it ends? (Do I get my data; what must I destroy; what survives?)

Run that checklist and you will understand more about a software contract than most people who sign one. For the line-by-line execution, hand off to the drafting and negotiation guide and the review checklist toolkit; for protecting the software as property in the first place, see legal protection of software and copyright registration of computer programs.

Key Takeaways

  • Software is licensed, not sold. That single design choice exists to defeat copyright's first-sale doctrine (17 U.S.C. § 109(a)), and Vernor v. Autodesk confirms that a license naming itself a license, restricting transfer, and restricting use will keep the user a licensee forever. Your rights are exactly what the grant gives you—no more.
  • The license grant is the deal. Scope, exclusivity, field of use, territory, and term define what you may actually do. Read it precisely; anything unstated is reserved to the licensor.
  • The commercial model shapes everything. Perpetual, subscription, and SaaS arrangements emphasize different terms; in SaaS, data ownership, portability, and exit eclipse the classic copy-based vocabulary.
  • Open source is a license, not a giveaway. Permissive and copyleft licenses carry conditions; mixing them carelessly can force disclosure of proprietary code or create infringement exposure.
  • Online contracts are enforceable only if properly formed. Clickwrap (affirmative "I Agree") almost always binds; pure browsewrap (footer link, no action) usually does not (Specht, Nguyen); ProCD established that post-payment terms can bind a buyer given a chance to review and reject.
  • Read the risk clauses together. A great IP indemnity is worthless if the limitation-of-liability cap swallows it—carve indemnities, confidentiality, and data breaches out of the cap.
  • The quiet clauses bite hardest. Audit rights can turn over-deployment into copyright infringement; change-of-control assignment terms can derail an acquisition; SLA service credits may be your only remedy for downtime; source-code escrow is cheap insurance for mission-critical software.
  • When in doubt, get the law and the forum right. Software-contract outcomes vary by jurisdiction (UCC applicability, enforceability of caps, treatment of assignment), and the law abroad (e.g., EU exhaustion) can differ sharply. This is an area where qualified counsel earns its fee.

Frequently Asked Questions

Do I actually own the software I paid for? Almost certainly not. In nearly all commercial software transactions you receive a license—a bounded right to use the software—while the developer retains ownership of the copyright. Under Vernor v. Autodesk, a well-drafted license keeps you a licensee, which means you generally cannot resell, transfer, or do anything with the software beyond what the license expressly permits.

Is clicking "I Agree" really a binding contract? Yes, in the vast majority of cases. A clickwrap agreement—where you must take an affirmative action like clicking "I Agree" to proceed—is routinely enforced because that click is a clear manifestation of assent. The shakier category is browsewrap, where terms sit in a footer link and you never click anything; courts often refuse to enforce those (Specht v. Netscape; Nguyen v. Barnes & Noble) because there is no real agreement. If you want your terms to stick, use clickwrap.

What's the difference between a perpetual license and a subscription? A perpetual license is paid for once and never expires (though support and updates usually require ongoing maintenance fees). A subscription license lasts only as long as you keep paying—stop, and your right to use the software ends. SaaS is a further step: you don't get a copy at all; you access software hosted by the provider, so the key terms shift to uptime, data ownership, and what happens to your data when you leave.

My company is being acquired—do our software licenses survive? Maybe not automatically. Many licenses prohibit assignment without consent and define "assignment" to include a change of control (a merger or acquisition). That can let each vendor block the transfer, terminate the license, or demand a fee at the worst moment. This is a major item in acquisition due diligence. Ideally, negotiate assignment rights for successors up front; if you didn't, plan for vendor consents during the deal.

What is a software audit, and why should I worry about it? Most licenses let the vendor inspect your usage to confirm you are within the licensed metrics. Because you hold only the rights the license grants, deploying more copies or seats than you licensed can be both a breach and copyright infringement, exposing you to back-license fees and statutory damages. The best defense is an accurate internal software inventory, plus a negotiated audit clause that limits frequency, requires notice, and shifts audit costs to the vendor absent material over-deployment.

What is source-code escrow and do I need it? Escrow is an arrangement where the vendor deposits the software's source code with a neutral third party, to be released to you if the vendor goes bankrupt, abandons the product, or fails to provide contracted support. It protects you from being stranded with critical software you receive only in executable form and cannot maintain. For mission-critical, hard-to-replace software, it's worthwhile—just make sure the deposit is verified and the release triggers are enforceable.

Can the vendor really limit its liability to almost nothing? Often, yes, between sophisticated businesses. Limitation-of-liability clauses typically exclude consequential and indirect damages and cap total liability (frequently at 12 months' fees). Courts generally enforce these as legitimate risk allocations. The negotiation is about carve-outs: insist that the IP indemnity, confidentiality breaches, data-security incidents, and willful misconduct sit outside the cap—otherwise your other protections may be illusory.

Is open source software safe to use in my commercial product? It can be, but it is not consequence-free. Open source comes with license conditions ranging from simple attribution (permissive licenses like MIT and Apache 2.0) to "copyleft" obligations that can require you to release your own source code if you distribute software incorporating that code (GPL family). Mixing incompatible licenses can create both compliance and infringement problems. Maintain an inventory of every open source component and its license, and adopt a compliance policy—see our open source licensing landmines guide.

Related Articles

This article is general legal information, not legal advice. Software licensing law varies by jurisdiction and turns on the specific facts and contract language of each transaction. For advice on your situation, consult qualified counsel.