Here is a small puzzle that sits at the heart of the modern economy. When you buy a hardcover novel, you own that copy. You can read it, lend it to a friend, scribble in the margins, sell it at a garage sale, or feed it to the fireplace, and the author cannot say a word. But when you "buy" a copy of a word processor, a video game, or the firmware running inside your tractor, you very likely own nothing of the sort. You own a license--a bundle of permissions, fenced in by a contract you almost certainly did not read--and the company on the other side reserves the right to tell you what you may and may not do with the very thing you paid for.

That difference is not a lawyer's trick, though it can feel like one. It is the load-bearing wall of a multi-trillion-dollar software industry, and it explains why a single kind of document--the software license agreement--quietly governs how almost every business and household on earth uses its most important tools. It is why a video game costs the same whether one person or ten thousand could run it, why a vendor can charge you again next year for software you "already have," and why reselling your old copy of an expensive design program can land you in federal court.

This article is the conceptual map of that terrain. It is deliberately the high-altitude view: the big ideas, the mental models, and the handful of doctrines and decisions that explain why software contracts read the way they do. It will not march you through every clause--mclaw.io has dedicated field manuals for that, and we will point you to them as we go. By the end you should be able to look at any software deal and immediately understand what kind of animal it is, why the law treats it as it does, and where the money and the risk are hiding.

A quick word on how this fits with its siblings, so you land in the right place. If you want the full clause-by-clause anatomy of a license--grant, field of use, warranties, indemnity, caps, and the rest, dissected one at a time--read the companion primer, Software Licensing Agreements. If your deal is not a classic license at all but sits in the wider universe of development agreements, resale and OEM channels, cloud subscriptions, and M&A asset transfers, start with Software Transactions--An Overview. When you are ready to draft or negotiate, see Drafting Software License Agreements--Key Terms and Negotiation Points; when you are reviewing someone else's paper, use the Software License Agreement Review Checklists toolkit. This piece is the friendly front door to all of them.

The One Idea Everything Else Hangs On

Strip away the jargon and a software license is just permission. To see why permission is even necessary--why you cannot simply do what you like with software the way you can with a toaster you bought--you have to start with copyright.

Software is a literary work in the eyes of copyright law, protected the instant it is "fixed in a tangible medium of expression"--which, for code, means the moment it is saved to a disk. Copyright hands the author a bundle of exclusive rights set out in 17 U.S.C. § 106: the right to reproduce the work, to distribute copies, to prepare derivative works, and more. Nobody else may do those things without permission.

Now notice the trap. Running a program is not like reading a book. To execute software, your computer must copy it--from storage into memory (RAM), into caches, sometimes onto disk. Each of those is, mechanically, a reproduction. Absent permission, simply using software would arguably infringe the reproduction right. Congress patched part of this hole with 17 U.S.C. § 117, which lets the owner of a copy of a program make the copies "essential" to running it and an archival backup--but, crucially, those rights belong only to an "owner of a copy," a phrase that will turn out to matter enormously.

So here is the foundational idea, and it bears repeating because everything downstream depends on it: software is so wrapped in copyright that using it requires permission, and a license is the instrument that grants that permission on stated conditions. The vendor keeps the intellectual property; you receive a defined, usually revocable, often non-transferable right to use it. Copyright is the source of the leverage; the license is how the vendor spends it. (For the larger picture of how copyright, patents, trade secrets, and contracts stack up to protect code, see Legal Protection of Software--Copyrights, Patents, Trade Secrets, and Contracts.)

A useful analogy: a license is to software what a lease is to an apartment. Buy a house and the deed transfers ownership; you may do almost anything the law allows, including selling it to the next person. Rent, and you get a limited right to occupy on the landlord's terms--no subletting without consent, no knocking down walls, and the keys go back when the lease ends. The software license is the lease, not the deed. Hold onto that picture; we will keep returning to it.

Why the Industry Licenses Instead of Selling: The First-Sale Problem

If copyright explains why permission is needed, a second doctrine explains why the industry chose to grant that permission as a license rather than simply selling copies outright. That doctrine is first sale, and the whole architecture of modern software distribution was built to route around it.

First sale, codified at 17 U.S.C. § 109(a), is the rule that lets you resell that hardcover novel. Once a copyright owner sells a particular copy, the owner's distribution right in that copy is "exhausted." The buyer may resell, lend, or give the copy away without asking. First sale is why used-bookstores, libraries, and the secondhand market in CDs and DVDs are all perfectly legal. The Supreme Court traced the principle to Bobbs-Merrill Co. v. Straus, 210 U.S. 339 (1908), where a publisher printed a minimum-resale-price notice inside a novel's cover and tried to enforce it; the Court held the publisher's control ended at the first sale.

Software companies looked at first sale and saw an existential threat. If selling copies exhausted their distribution rights, a thriving secondhand market in used software would spring up, and every used copy resold is, in effect, a sale the vendor did not make. Worse, an owner of a copy would also enjoy the backup-and-essential-step rights of § 117 no matter what the vendor wanted.

The industry's elegant escape was to stop selling and start licensing. The logic is a chain: if the transaction is a license and not a sale, then no "sale" ever occurs, so first sale never triggers, so the customer never becomes the "owner of a copy" under § 117, so the vendor's restrictions--no resale, no transfer, no reverse engineering--all hold. That single move is why the shrink-wrapped box, the download button, and the app-store "purchase" all deliver a license, not title. Understanding this chain is most of what separates someone who is fluent in software licensing from someone who is merely confused by it.

When Is a "Sale" Really a License? Vernor v. Autodesk

Courts did not simply rubber-stamp the magic word "license." The leading decision is Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010). Timothy Vernor bought several used copies of Autodesk's AutoCAD software at an office sale and resold them on eBay. Autodesk fired off takedown notices; Vernor sued for a declaration that first sale protected him. The threshold question was whether Autodesk had sold those copies (so Vernor could resell) or merely licensed them (so he owned nothing to resell).

The Ninth Circuit gave us a three-factor test that is now the industry's recipe. A user is a licensee rather than an owner when the copyright holder (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. 621 F.3d at 1110-11. Autodesk's terms checked all three boxes, so Vernor was a licensee, first sale did not apply, and his resales infringed. The same court reasoned in parallel about a digital-download license in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010).

The practical upshot is symmetrical. A vendor that wants its restrictions to survive should make sure its agreement clearly uses license language, restricts transfer, and imposes real use limits--hit all three Vernor notes. A customer that wants resale or transfer rights has to negotiate them expressly, because the default modern agreement is engineered to deny them.

But Vernor is not the last word everywhere, and the line is genuinely contested. Two currents are worth flagging:

  • Digital exhaustion. Should first sale ever apply to purely digital files? In Capitol Records, LLC v. ReDigi Inc., 910 F.3d 649 (2d Cir. 2018), the Second Circuit held that a service for reselling "used" iTunes files infringed, because moving a digital file necessarily makes a new copy, and first sale protects only distribution of the particular lawfully made copy, not reproduction. Europe went the other way for software specifically: in UsedSoft GmbH v. Oracle International Corp., Case C-128/11 (CJEU 2012), the Court of Justice of the European Union held that a perpetual software license sold for a one-time fee can exhaust the distribution right under EU law, allowing resale--a striking transatlantic split that any company operating on both sides of the ocean has to plan around.
  • Economic reality over labels. The word "license" helps, but it is not a talisman. In UMG Recordings, Inc. v. Augusto, 628 F.3d 1175 (9th Cir. 2011), promotional CDs stamped "promotional use only--not for sale" were held to have been given away, not licensed, so recipients could resell them under first sale. A one-time payment, perpetual rights, and no meaningful ongoing relationship can still look like a sale to a skeptical judge, whatever the box says.

A Field Guide to Reading Any Software Contract

Before we survey the deals you will actually meet, here are four mental models that let you read almost any software agreement without drowning in its clauses. Think of them as the lenses an experienced technology lawyer flips through in the first five minutes.

1. License or sale--and if a license, how license-like? Run the Vernor checklist in your head: does it call itself a license, restrict transfer, and limit use? The more boxes checked, the further you are from owning anything, and the more the contract (not copyright's default rules) governs your rights.

2. Scope is king. The single most consequential thing in any license is the scope of the grant--who may use the software, for what, where, how many, and for how long. A license to "the Customer" says nothing about its affiliates, contractors, or the company it merges into next year. A license for "internal business purposes" may not cover using the software to serve your customers. A license for "one named user" is a wholly different thing from "one server" or "up to 500 monthly active users." When software disputes reach court, they are almost always scope disputes: did the customer's real-world use fall inside or outside the lines the grant drew? Read the grant first, twice.

3. Find the risk-shifting clauses. A handful of provisions decide who pays when things go wrong: the warranties (what the vendor promises), the IP indemnity (who defends you if the software is sued), and the limitation of liability (the cap and the excluded categories of damages that, between them, often shrink a catastrophe down to a refund). If you read nothing else, read those three. We sketch them below; the drafting and review resources dissect them line by line.

4. Follow the lifecycle, especially the exit. Every license has a beginning (grant, fees, acceptance), a middle (use, support, audits, changes of control), and an end (termination, data return, what survives). Buyers obsess over the beginning and forget the end--but for cloud software in particular, exit is where leverage runs out and where the worst surprises live.

Keep these four lenses handy. The rest of this article is really just an elaboration of them.

The Four Worlds of Software Licensing

Software comes wrapped in several very different commercial models, and they allocate rights, money, and risk in genuinely different ways. (If your deal does not look like any of these--say, you are paying a vendor to build custom software, or moving code through a reseller channel--you are in the broader territory mapped by Software Transactions--An Overview.)

The Perpetual License

The classic model. The customer pays a one-time fee for the right to use a specific version of the software forever. The IP stays with the vendor; the customer just gets perpetual use rights. Perpetual licenses are usually paired with an optional, recurring maintenance and support fee--commonly 18-22% of the license price per year--that buys bug fixes, updates, and a help desk. Stop paying maintenance and the license typically survives, but the updates stop. Perpetual licensing ruled the on-premises era and still governs much enterprise and embedded software, even as subscriptions eclipse it.

The Subscription License

Here the customer pays a recurring fee--monthly or annual--for time-limited use rights. When the subscription lapses, so does the license: keep using the software and you are now infringing. Subscriptions can cover software you install (your right to run it is simply metered by your subscription) or, more often, hosted services. The migration from perpetual to subscription has been one of the defining business-model stories of the past fifteen years, reshaping companies like Adobe and Microsoft and trading a big upfront sale for predictable recurring revenue.

Software as a Service (SaaS)

In a SaaS arrangement, the customer does not receive a copy of the software at all. The vendor hosts the application on its own or a cloud provider's infrastructure, and the customer reaches it over the internet, usually through a browser or an API, for a subscription fee. The software is installed nowhere on the customer's systems, the infrastructure is shared among many customers (multi-tenant), and customization is limited.

This is a profound legal difference, not a cosmetic one. Because no copy is delivered to or made by the customer, a pure SaaS deal is arguably not a copyright "license" in the traditional sense at all--it is a services agreement, an access right, more like a utility than a product. Copyright's first-sale and § 117 questions largely evaporate, and the contract becomes everything. The whole center of gravity shifts: away from copy-based concepts and toward service-level commitments (uptime), data ownership and portability (who owns what you put in, and can you get it back out), security and privacy, subprocessor disclosures, and exit and transition assistance. For a regulated-data SaaS deal--health records, financial data--the contract also has to satisfy sector law, which is where data and privacy terms stop being boilerplate and become the main event. (Confidential code and architecture, meanwhile, are often guarded as trade secrets.)

Open Source

Open source software (OSS) inverts the usual proposition. Instead of restricting use, an open source license grants broad rights to use, study, modify, and redistribute the source code--in exchange for compliance with conditions. The conditions sort the families:

  • Permissive licenses (MIT, BSD, Apache 2.0) ask little--keep the copyright notice and license text--and let you build proprietary products on top.
  • Copyleft licenses (the GPL family) are reciprocal: distribute software that incorporates GPL code and you must release your combined source under the same terms. This is the famous (and widely misunderstood) "viral" effect--really a condition on distribution, not a virus.
  • Weak copyleft licenses (LGPL, MPL) split the difference, requiring reciprocity for the open components while letting proprietary code link to or combine with them under defined conditions.

The non-obvious point is that open source licenses are real copyright licenses, not informal giveaways. The Federal Circuit confirmed in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), that the terms of an open source license (there, the Artistic License) are enforceable conditions on the copyright grant--so violating them is copyright infringement, not mere breach of contract, which unlocks injunctions and statutory damages. The practical hazard is that mixing incompatible licenses, or pulling copyleft code into a proprietary product, can create obligations a company never meant to take on. For the full treatment, see mclaw.io's deep dives on open source software, the open source compliance checklists, and the war stories in open source licensing landmines in enterprise software development.

And One Document Type That Cuts Across Them: the EULA

A end-user license agreement (EULA) is the consumer- or end-user-facing license that ships with packaged or downloaded software--the "I Agree" screen on a desktop app or a mobile game. EULAs are typically take-it-or-leave-it, non-negotiable, and drafted heavily in the vendor's favor. They stand in contrast to enterprise license agreements and master agreements, the negotiated documents between sophisticated parties (often a master agreement plus order forms or statements of work) where the customer has real bargaining power. The model and the document type are different axes: a perpetual, subscription, or SaaS deal can each be delivered through a non-negotiable EULA or a heavily negotiated master agreement.

Did You Even Agree? The Law of Clickwrap and Browsewrap

Notice a problem we have been gliding past. You did not negotiate the EULA on your operating system. Nobody read all fourteen thousand words. So how can a court hold you to a contract you never opened? Before we can argue about what a license says, we have to answer whether it formed at all--and the answer is a rich body of case law that turns on a single distinction: clickwrap versus browsewrap.

Clickwrap presents the terms (or a conspicuous link to them) and requires the user to take an unmistakable affirmative act to proceed--classically, checking a box or clicking "I Agree." Courts reliably enforce clickwrap, because the click supplies the assent that contract law demands. The foundational software case is ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996). Matthew Zeidenberg bought a CD-ROM telephone database whose on-screen license, which required acceptance before use, limited the data to non-commercial purposes; he resold it commercially anyway. Writing for the Seventh Circuit, Judge Frank Easterbrook held the license enforceable even though Zeidenberg saw the full terms only after paying at the register. "Money now, terms later," the court reasoned, is a familiar and legitimate way to contract--think of an airline ticket or an insurance policy whose details arrive afterward--so long as the buyer can review the terms and reject the deal by returning the product. ProCD blessed the shrink-wrap/clickwrap model and is cited in nearly every formation dispute since.

Browsewrap is the opposite design. The terms sit behind a hyperlink--often a small "Terms of Use" in the page footer--and the site claims that merely using it binds you, no click required. Browsewrap is enforceable only when the user had actual or constructive notice, and courts are far more skeptical, because a buried link does not reliably put anyone on notice. The cautionary tale is Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), where users clicked a prominent "Download" button while the license terms (including an arbitration clause) lurked in text only visible if you scrolled below the button. Then-Judge Sonia Sotomayor held that no contract formed: "a reference to the existence of license terms on a submerged screen is not sufficient to place consumers on inquiry or constructive notice of those terms." No notice, no assent; no assent, no agreement. The modern synthesis came in Nguyen v. Barnes & Noble, Inc., 763 F.3d 1171 (9th Cir. 2014), which refused to enforce footer-link Terms of Use even when the link appeared on every page, holding that a conspicuous hyperlink "without more" does not give rise to constructive notice. 763 F.3d at 1178-79.

The current frontier is the hybrid called "sign-in wrap": no separate "I Agree" box, but a clear notice next to the action button saying "by clicking [Continue / Sign Up] you agree to the Terms," with the Terms hyperlinked. Whether these bind turns on the two-part test the Second Circuit set out in Meyer v. Uber Technologies, Inc., 868 F.3d 66 (2d Cir. 2017): was the user given reasonably conspicuous notice, and did the user take an action that unambiguously manifests assent? Uber's clean sign-up screen passed; tiny gray font, by contrast, has failed (Berman v. Freedom Financial Network, LLC, 30 F.4th 849 (9th Cir. 2022)). The design lesson reduces to a few words every interface designer should know: notice visible without scrolling, placed beside the action button, in legible contrast, hyperlinking the real terms, with an affirmative act. Do those things and you usually have an enforceable contract; hide your terms in a footer and you are gambling that no one ever sues. (These same formation rules run through every deal in Software Transactions--An Overview.)

Where the Money and Risk Live: A High-Altitude Tour of the Clauses

The companion primer takes these clauses apart one at a time; here we just want you to recognize the half-dozen that actually decide outcomes, and why they matter, so you know where to slow down.

The license grant. As lens number two said: scope is king. The grant is a string of carefully chosen adjectives--exclusive or non-exclusive, transferable or not, sublicensable or not, perpetual or term-limited, worldwide or territorial--capped by the all-important scope of use (named users, seats, servers, cores, instances, transactions; production only, or also dev, test, and disaster recovery). Every adjective is a negotiation, and the scope-of-use line is where most litigation is born.

A worked example (hypothetical). Suppose Acme Logistics licenses a route-optimization platform "for use by up to 50 named users for Acme's internal business operations." Acme later spins up a subsidiary, Acme Air, and lets its dispatchers in; it also builds a customer portal that runs the platform's engine to give Acme's own clients optimized routes. Both moves likely fall outside the grant--the subsidiary's users were never licensed (affiliates were not included), and serving third parties is not "internal." When the vendor's audit catches it, Acme faces back-license fees and a breach claim. None of it happens if Acme's counsel had negotiated "Acme and its Affiliates" plus an express service-provider right at signing. That is the whole game: most disputes are scope disputes that good drafting would have prevented.

Warranties. A promise about the software that, if false, yields a remedy. Vendors typically offer a thin limited performance warranty (the software will "substantially conform to its documentation" for, say, 90 days, with repair/replace/refund as the sole remedy) and a non-infringement warranty (that they have the right to license it and it does not infringe), then disclaim everything else--the implied warranties of merchantability and fitness--in conspicuous ALL-CAPS, because UCC § 2-316 requires a merchantability disclaimer to be "conspicuous." Lurking underneath is an unresolved question: is software a "good" governed by UCC Article 2, or a service/license governed by common law? Courts are split, the attempted uniform fix (UCITA) was adopted by only two states and effectively abandoned, and so the safe course is to address warranties expressly rather than rely on uncertain background law. (That goods-or-services puzzle is explored at length in Software Transactions--An Overview.)

IP indemnification. The headline protection for a customer: the vendor agrees that if a third party sues the customer claiming the software infringes a patent, copyright, or trade secret, the vendor will defend and pay the resulting damages and settlements. This is enormously valuable, because IP litigation is ruinous and the customer cannot assess infringement risk in code it cannot see. Watch the carve-outs (no indemnity for the customer's modifications, combinations, or out-of-scope use) and watch that the liability cap below does not swallow the indemnity whole.

Limitation of liability. If you read only one clause, read this one. It does two enormous things: it excludes whole categories of damages (consequential, incidental, indirect, special, punitive--and very often lost profits and lost data), and it caps the vendor's total exposure, very commonly at the fees paid in the prior 12 months. So a customer paying $100,000 a year may have a contract under which the most it can ever recover, even for a catastrophe, is $100,000. Courts generally enforce these between sophisticated parties as a legitimate price-for-risk bargain, but not always--many states will not let a limited remedy "fail of its essential purpose" (UCC § 2-719(2)) or excuse gross negligence, fraud, or willful misconduct. The negotiation, in a sentence: accept the cap for ordinary performance disputes, but carve out from both the exclusions and the cap the things you cannot afford to under-recover on--confidentiality breaches, the IP indemnity, and data-security failures, often subject to a higher "super-cap."

The operational terms that quietly decide outcomes. Three more deserve a mention because they bite quietly:

  • Service levels (SLAs). For subscription and SaaS deals, the SLA promises uptime ("99.9%" is roughly 8.8 hours of permitted downtime a year; "99.99%" is under an hour) and specifies the consequence of a miss--almost always service credits as the sole and exclusive remedy. Two hard truths: credits rarely let you recover your actual losses, and the definitions do all the work (a 99.99% SLA with generous exclusions can be weaker than a 99.5% SLA with tight ones).
  • Audit rights. Most enterprise licenses let the vendor audit your deployment against the license metrics. Software audits are a real and sometimes adversarial business; major vendors run dedicated compliance programs that surface shortfalls and demand back-fees. Negotiate guardrails--reasonable notice, once a year, at the vendor's expense unless a material shortfall is found--and defend yourself the same way you defend against a scope dispute: know your grant and track your usage.
  • Source-code escrow. For business-critical on-premises software, customers fear the vendor vanishing--bankruptcy, acquisition, abandonment--and leaving them running software no one can fix, because they only ever got the executable, not the source. The traditional answer is escrow: the vendor deposits source code with a neutral agent that releases it on defined conditions (typically the vendor's bankruptcy or failure to support). Two things make escrow more than theater: the deposit should be verified to actually build, and Bankruptcy Code 11 U.S.C. § 365(n) lets IP licensees keep their license rights even if a bankrupt licensor rejects the contract. Escrow matters far less for SaaS, where data portability and transition assistance protect you instead--you could not run the vendor's hosted infrastructure even if you held the code.

For all of these clauses at full resolution--model language, fallback positions, and who-asks-for-what--turn to Drafting Software License Agreements and the Software License Agreement Review Checklists toolkit.

The Lifecycle of a License, in Three Acts

It helps to see a license not as a static document but as a relationship with a beginning, a middle, and an end--lens number four made concrete.

Act I: Formation and grant. Did the contract form (clickwrap versus browsewrap)? What exactly was granted, and is your real-world use inside the scope? What did you pay, and on what model? This is the act everyone reads.

Act II: Use and change. Now the relationship runs. Maintenance and support keep the software current; SLAs measure the vendor's performance; audits test your compliance. And life intervenes: companies merge, get acquired, restructure. The assignment and change-of-control clause--easy to skim, painful to ignore--decides whether your license survives your own acquisition or the vendor's, and is a clause M&A lawyers genuinely lose sleep over. Confidentiality obligations run throughout this act, and for SaaS, so do the data, privacy, and security commitments that have become the contract's true center of gravity.

Act III: Termination and exit. Every relationship ends. Watch the grounds (material breach uncured after notice, typically 30 days; sometimes termination for convenience) and, more importantly, the consequences: you usually must stop using and destroy or return the software, and certain clauses survive (confidentiality, the liability cap, accrued payments, and--critically for SaaS--data return and transition assistance). For cloud software, Act III is where the leverage you had in Act I has evaporated, which is exactly why the smart customer negotiates exit terms before signing, when it still has any.

A Negotiation in Miniature

To make the abstractions concrete, picture a stylized deal. Brightline Health, a mid-size clinic network, is licensing a SaaS scheduling-and-records platform from Vendor Corp. The standard form arrives looking like every standard form: a broad grant of the vendor's rights, thin warranties, a 12-month-fees cap that swallows everything, no carve-outs, a one-sided audit clause, a 99.5% SLA with loose exclusions, and a data clause letting the vendor "use aggregated data" in undefined ways.

Brightline's counsel works the document in priority order, and the order itself is the lesson. Because Brightline handles protected health information, the first fight is data and security: a HIPAA business-associate agreement, SOC 2 evidence, a tight breach-notification clock, a clear statement that Brightline owns its data, real limits on the "aggregated data" use, and a data-export-and-deletion right on exit. Next is liability: accept the 12-month cap for ordinary performance issues, but carve out--as exceptions to the cap--confidentiality breaches, data-security failures, and the IP indemnity, subject instead to a higher super-cap. Then the IP indemnity itself (defense plus damages, with procure/modify/refund options, narrowed carve-outs); the SLA (push to 99.9%, tighten "downtime," add a chronic-failure termination right); scope (cover affiliated clinics and contractors so a later expansion does not trip an audit); and transition assistance (the vendor must help migrate data after termination, because for a SaaS customer, exit is where the leverage runs out).

Vendor Corp. gives ground where its risk is controllable--it has good security and an indemnity it can stand behind--and holds the line on the base cap and on SLA exclusions for third-party network failures it cannot control. The deal that emerges is balanced because each side fought hardest over the risks it best understood. That, in miniature, is software licensing negotiation: not a war over every word, but a disciplined allocation of a handful of risks that actually matter.

Special Situations Worth Flagging

A few contexts bend the analysis enough to mention:

Mobile apps and app stores. A developer distributing through Apple's App Store or Google Play is bound by the platform's developer agreement and must present its own EULA to end users (Apple even supplies a default license if the developer provides none). The platform takes its cut and sets the rules. See Protecting Your Mobile App--A Comprehensive IP Strategy Guide and Popular Legal Documents for Startups.

Government and regulated buyers. Standard commercial terms often collide with federal procurement rules--the government generally cannot agree to indemnify, to certain governing-law clauses, or to terms that offend the Anti-Deficiency Act--so vendors selling to government need conforming addenda.

AI and machine-learning tools. Licenses for AI systems raise questions the classic clauses do not squarely answer: who owns the outputs, what may the vendor do with customer prompts and data to train its models, and who bears infringement risk for generated content. Many AI agreements now add output indemnities and training-data opt-outs, and the area is moving fast; mclaw.io tracks it in Artificial Intelligence Key Legal Issues--An Overview.

Embedded and "smart" products. When software runs inside a physical thing--a car, a tractor, a medical device--the license can restrict what the owner of the hardware may do, which is the engine of the right-to-repair debate and of reverse-engineering and anti-circumvention fights like the ones behind the DMCA phone-unlocking exemption. It is also why "do you really own the things you buy?" has become a live legal question rather than a philosophy-seminar one.

Key Takeaways

  • A software license is permission to use, not a transfer of ownership. Copyright (17 U.S.C. § 106) makes using software an act that needs permission; the license grants it on conditions, and the vendor keeps the IP. Picture a lease, not a deed.
  • The industry licenses rather than sells to sidestep first sale (17 U.S.C. § 109) and the copy-owner rights of § 117. Under Vernor v. Autodesk, a transaction is a license--not a sale--when the agreement says so, restricts transfer, and limits use.
  • Formation matters before content does. Clickwrap (affirmative click; ProCD) is reliably enforceable; browsewrap (buried link; Specht, Nguyen) usually is not, absent reasonably conspicuous notice (Meyer v. Uber).
  • The four worlds--perpetual, subscription, SaaS, open source--allocate rights, money, and risk very differently. SaaS is really an access-and-services deal where data, security, and SLAs eclipse copyright concepts; open source licenses are enforceable copyright conditions (Jacobsen v. Katzer).
  • A handful of clauses decide who wins: the grant (scope is king), warranties, IP indemnity, limitation of liability (exclusions plus a cap), SLAs, audit rights, and escrow. Identify the risks you cannot afford to under-recover on, and carve them out of the cap.
  • Read it before you sign, track your actual usage, and license what you really need. Most disputes are scope disputes that good drafting would have prevented, and for cloud software, the exit terms are the ones to win up front.

Frequently Asked Questions

Do I own software I "buy"? Almost never. You buy a license--a right to use--while the vendor keeps ownership of the software's intellectual property. That is why your license can restrict resale, transfer, and reverse engineering in ways that would be impossible if you owned the copy the way you own a book.

Why is software licensed instead of just sold? To avoid copyright's first-sale doctrine. If the deal were a sale, you could resell your copy and you would gain the copy-owner rights of 17 U.S.C. § 117. By structuring the deal as a license, the vendor keeps control over resale, transfer, and use--the move blessed (within limits) by Vernor v. Autodesk.

Can I resell software I no longer use? Usually not, under U.S. law. Because the transaction is typically a license rather than a sale, first sale does not apply and the license usually prohibits transfer (Vernor). Some licenses permit one-time transfers, and EU law treats certain perpetual software licenses as resellable (UsedSoft v. Oracle), so the answer depends on the agreement and the jurisdiction. Read the transfer clause.

Is a clickwrap agreement I never actually read enforceable? Generally yes. Clicking "I Agree" with notice of the terms (or a conspicuous link) forms a binding contract whether or not you read it--the core of ProCD v. Zeidenberg and its progeny. Failing to read is not a defense; lacking notice and a chance to assent is.

What is the difference between clickwrap and browsewrap? Clickwrap requires an affirmative act--a box or an "I Agree" button--and is reliably enforced. Browsewrap claims that merely using a site or product binds you to terms behind a link, with no click, and is enforced only with conspicuous notice. Buried-footer browsewrap usually fails (Specht; Nguyen).

How is a SaaS subscription different from a traditional license? In SaaS you never receive a copy; you access the vendor's hosted application over the internet. That makes it more an access-and-services arrangement than a copyright license, so the key terms shift to uptime/SLAs, data ownership and portability, security, privacy, and exit assistance rather than copy-based concepts like first sale.

What is the most important clause in a software license? For risk, the limitation of liability, because it excludes whole categories of damages and caps exposure (often at one year of fees). For rights, the license grant, because its scope decides whether your real-world use is even permitted. Most disputes turn on one of these two.

Is software a "good" under the UCC or a service? Courts are split, and the answer affects which warranties are implied and how the contract is read. Because the background law is uncertain (the attempted uniform statute, UCITA, was largely abandoned), address warranties, remedies, and risk allocation expressly rather than relying on default rules.

Which mclaw.io article should I read next? If you want every clause dissected, read the companion primer, Software Licensing Agreements. If your deal is a development, resale, cloud, or M&A transaction rather than a plain license, start with Software Transactions--An Overview. To draft or negotiate, use Drafting Software License Agreements; to review someone else's paper, use the Review Checklists toolkit.

Related Articles

This article provides general information only and is not legal advice. Software licensing law varies by jurisdiction and evolves quickly; for guidance on a specific agreement or situation, consult qualified counsel.