Imagine three companies that all think they "bought software" last quarter.

The first, a regional hospital, paid a vendor $400,000 and received a download link and a thick license agreement; it believes it now owns a copy of a records system. The second, a marketing agency, clicked "I agree" on a web page and started paying $90 per user per month for a tool it reaches entirely through a browser; it believes it is renting a service. The third, a robotics startup, hired an outside development shop to build a control system from scratch and paid by the hour; it believes it owns whatever the developers wrote. Every one of those beliefs is, at least in part, probably wrong--and the gaps between what these buyers think they got and what their contracts actually say are exactly where software disputes are born.

Software is the strangest thing the law of commercial transactions has ever had to digest. It is not quite a good you can drop on your foot, and not quite a pure service like accounting or legal advice. It is copyrightable expression, sometimes patentable invention, frequently a trade secret, and almost always licensed rather than sold. It is delivered on a disc, downloaded, streamed from a data center you will never see, or embedded invisibly inside a thermostat. And the body of contract law that governs the sale of toasters and steel--Article 2 of the Uniform Commercial Code--was written in the 1950s, decades before anyone imagined a "transaction" in which nothing physical changes hands and the "buyer" never actually owns the thing.

This article is the map of that territory. It explains the major types of software deals and how they differ, the unsettled question of which law governs them, how those deals are formed (including the click-to-agree contracts you accept dozens of times a week), who owns the intellectual property when software is built to order, and the practical terms--warranties, indemnities, liability caps, service levels, data and privacy commitments, open-source obligations, and source-code escrow--that make or break a deal. It ends where software lawyers spend a surprising amount of their time: the disputes that actually erupt, and the moment when software changes hands in a merger or acquisition. By the end you should be able to look at any software arrangement and ask the right first questions. What kind of deal is this? What law applies? Who owns what? And where is the risk hiding?

If you want to go deeper on any one branch, this piece is the trunk of a small tree. Its closest companions are Software Licensing Agreements--An Overview, which zooms in on the license itself; the term-by-term Drafting Software License Agreements--Key Terms and Negotiation Points; and the practical Software License Agreement Review Checklists--A Complete Toolkit. This overview deliberately stays at altitude--it covers the whole family of deal types--and hands you off to those pieces when you need to draft a particular clause.

What We Mean by a "Software Transaction"

A software transaction is any contract whose central subject is software--its use, access, creation, delivery, support, or resale. The word "transaction" is deliberately broad, because software is monetized in many ways at once. A single relationship might bundle a license to use a product, a subscription to a hosted service, professional services to configure it, and a maintenance plan to support it, all in one master agreement.

It helps to start with a vocabulary that recurs through every software deal.

A licensor (or vendor, or provider) is the party that owns or controls the software and grants rights in it. A licensee (or customer, or end user) is the party that receives rights to use it. A license is a grant of permission to do something--use, copy, modify, distribute--that, absent the license, would infringe the owner's intellectual property. That last point is the conceptual key to the entire field, and it is worth sitting with: software is almost never sold the way a car is sold. It is licensed. The owner keeps the underlying copyright, patent, and trade-secret rights and merely lets you do specified things with a copy. We will see exactly why that distinction carries such enormous weight when we reach the license-versus-sale question below.

Software is protected by an overlapping bundle of intellectual property rights--copyright in the code and user interface, sometimes patents on the underlying methods, trade-secret protection for the source code and algorithms, and trademark in the product name. Understanding which rights are in play shapes every transaction. A SaaS provider, for example, may never need to worry about copyright distribution at all (it distributes nothing), but lives and dies by trade-secret protection of code it never lets out of its data center. For the full picture of how those rights stack on a single program, see Legal Protection of Software--Copyrights, Patents, Trade Secrets, and Contracts.

The Four Big Families of Software Deals

Most software arrangements fall into one of four families. They differ in what the customer actually receives, where the software lives, who controls it, and--critically--how the law treats them. Knowing which family you are in is the first move in any analysis.

1. The Traditional License: You Get a Copy

In the classic on-premises license, the customer receives a copy of the software--historically on physical media, now usually by download--and installs it on hardware the customer controls. The vendor grants a license defining who may use it (named users? a server? a whole site?), how (production only? internal business purposes? not for resale?), for how long (perpetual, or a fixed term), and subject to what restrictions (no reverse engineering, no copying beyond backups, no transfer).

Licenses come in two broad flavors. A perpetual license grants the right to use a specified version forever, usually for a one-time fee, often paired with an annual maintenance and support fee that buys bug fixes, updates, and a help desk. A term or subscription license grants the right to use the software for a fixed period--say, one or three years--after which the right lapses unless renewed. The economics differ sharply: perpetual licenses are capital expenditures with a big up-front number; subscriptions are operating expenses that recur. Vendors have spent two decades migrating customers from the former to the latter because recurring revenue is worth more to them and easier to forecast.

A worked example, clearly hypothetical. Acme Manufacturing licenses a perpetual copy of an inventory system from Vendor Corp for $250,000, plus 20% per year in maintenance. Acme installs it on its own servers. Acme controls the data, the uptime, and the security--and bears responsibility for all three. If Acme stops paying maintenance, the software keeps running, but Acme stops receiving patches. This is the world the hospital in our opening thought it was living in.

2. SaaS and Cloud Subscriptions: You Get Access, Not a Copy

Software as a Service (SaaS) flipped the model. In a SaaS deal, the customer never receives a copy of anything. The software runs on the vendor's (or a cloud host's) servers, and the customer simply accesses it over the internet, typically through a browser, for a recurring subscription fee. Think of the difference between buying a DVD and subscribing to a streaming service: in one you possess a copy; in the other you possess only a right of access that ends when you stop paying. SaaS is one slice of a larger cloud taxonomy that practitioners distinguish by what the provider hosts--infrastructure as a service (IaaS, raw compute and storage), platform as a service (PaaS, a development and deployment environment), and SaaS (a finished application). The legal center of gravity shifts as you move up the stack, but the through-line is the same: the customer is buying access to someone else's environment, not a copy of anything.

This difference is not cosmetic--it reshapes the legal questions. Because nothing is delivered, a SaaS contract is much harder to characterize as a "sale of goods," which has consequences for warranty law we will reach shortly. Because the vendor hosts the software and holds the customer's data, the contract's center of gravity shifts away from "what may I do with this copy" and toward service levels (will the system be up?), data ownership and security (who owns and protects my data?), privacy compliance (how is personal information handled?), and what happens to my data when this ends (can I get it back?). Many SaaS deals add a thin layer of downloadable client-side software--an agent, a plug-in, a mobile app--which reintroduces a small "you get a copy" component and is why pro-customer SaaS forms increasingly pair access terms with a narrow license for the downloadable piece.

The marketing agency from our opening is a SaaS customer. It owns no software. It owns its data (if the contract says so--more on that below), and it has a contractual right of access that evaporates the day it stops paying. A SaaS agreement that reads like a 1995 box-software license--full of provisions about copying, installation, and media defects, and silent on uptime, data export, and security--is a misfit, and unfortunately many still are.

3. Development Agreements: Someone Builds It for You

In a software development agreement, one party pays another to create software--custom code written to the customer's specifications. This is fundamentally a services deal layered on top of an intellectual-property deal, and it raises the single most litigated question in the field: who owns what gets built? We devote a full section to ownership below, because the intuitive answer ("I paid for it, so I own it") is frequently and expensively wrong.

Development deals come in styles that mirror how the software is actually built. A fixed-scope/fixed-price (often "waterfall") arrangement specifies deliverables, acceptance criteria, and a price up front. An agile arrangement--increasingly the norm--proceeds in iterative sprints with evolving requirements and is paid time-and-materials or per sprint, which makes "scope," "acceptance," and "completion" genuinely hard to pin down in a contract written for fixed deliverables. The mismatch is real: agile and Scrum methodologies deliberately defer detailed requirements, while the standard development contract wants a frozen specification to measure acceptance against. Drafting for that reality is its own craft; see Navigating the Legal Landscape of Agile Software Development.

The robotics startup from our opening is a development customer. Whether it actually owns the control system its developers wrote depends entirely on contract language it may never have read.

4. Resale, VAR, OEM, and Distribution: Software Moving Through a Channel

The fourth family covers deals in which software moves through a channel to reach end users. Here the licensor is not selling to the end customer at all; it is enlisting an intermediary, and varied distribution channels are a classic way for a software company to maximize revenue and reach markets its own sales team cannot. The intermediaries come in distinct flavors, and the differences are not pedantic--they drive which clauses matter.

A plain reseller or distributor buys the right to resell the vendor's product (often the object-code version) to downstream customers or sub-distributors across a territory, usually without touching the software itself. A value-added reseller (VAR) goes further: it bundles the licensor's software with other software and distributes the combined product, typically under the VAR's own branding, adding configuration, integration, or support. An OEM (original equipment manufacturer) bundles the licensor's software with equipment--hardware or a device--and ships an integrated product under the OEM's brand: the operating system inside a point-of-sale terminal, the navigation engine inside a car, the analytics library embedded in another company's appliance. The rough rule of thumb practitioners use: VARs bundle with software and tend to advertise the licensor's component (so VAR agreements usually carry a trademark license, because the VAR wants to say "powered by"), while OEMs bundle with hardware and usually private-label the result (so the embedded component is invisible and trademark provisions matter less).

These channel deals raise their own cluster of issues. The scope of the grant must spell out a development-and-integration license (may the VAR or OEM modify or adapt the software, and does that require source-code access?), a distribution license (object code only? to end users only, or to sub-distributors too?), and often a trademark and documentation license. Licensors typically resist letting a VAR or OEM modify the software, because modification needs source code and invites defective or competitive derivatives; the cleaner solution is to provide interoperability information instead. When modification is unavoidable, the parties must allocate ownership of the resulting improvements, often through a grantback--but here antitrust law intrudes: exclusive grantbacks of improvements can be challenged as anticompetitive, so non-exclusive grantbacks are the safer design (see the DOJ/FTC Antitrust Guidelines for the Licensing of Intellectual Property (2017), § 5.6). Channel deals also force a decision about end-user terms: does the distributor pass through the licensor's EULA, or grant its own sublicense with terms at least as protective, and is the licensor a third-party beneficiary able to enforce against end users directly? Royalty calculation, audit rights, support responsibility, and the fate of deployed copies when the channel relationship ends all need answers. And because the intermediary sits between licensor and end user, distribution arrangements can trip antitrust and even franchise laws that pure two-party licenses never touch.

Finally, channel deals magnify open-source and third-party-component risk, because obligations attached to embedded code can flow all the way downstream to end users--a point we return to under "open-source flow-down." For the mechanics of these deals, the companion practice materials on software distribution and VAR/OEM negotiation go term by term; this overview gives you the lay of the land.

These four families are not airtight boxes. Modern deals blend them: a vendor might host its software as SaaS (family 2), let a partner resell that SaaS (family 4), and provide professional services to configure each customer's instance (a services deal that looks like family 3). The point of the taxonomy is not to force every contract into one bucket but to train the eye to spot which dynamics are in play.

The Threshold Puzzle: Which Law Even Applies?

Here is the question that has fascinated and frustrated software lawyers for forty years, and it is genuinely fun once you see the stakes: when two parties sign a software contract, what body of law governs it? The answer is not obvious, and it can flip outcomes on warranties, the statute of frauds, the battle of the forms, and damages.

Goods, Services, and the UCC Article 2 Question

In the United States, contracts for the sale of goods are governed by Article 2 of the Uniform Commercial Code--a uniform statute adopted (with local variations) in every state but Louisiana. Article 2 is a powerful, buyer-friendly, off-the-shelf rulebook: it supplies implied warranties of merchantability and fitness for a particular purpose (UCC §§ 2-314, 2-315), a four-year default statute of limitations (§ 2-725), gap-filling terms, and the famous "battle of the forms" rule (§ 2-207) for reconciling conflicting purchase orders and acknowledgments. Contracts for services, by contrast, are governed by the common law of contracts, which has no automatic implied warranties of quality and is generally more deferential to whatever the parties actually wrote.

So: is software a "good"? A "good" under Article 2 is, roughly, a thing that is movable at the time of identification to the contract (UCC § 2-105). A box of software on a disc looks like a good. Pure custom-development labor looks like a service. A download looks like... something in between. SaaS--where nothing moves at all--looks least like a good of all.

Courts have wrestled with this for decades, and the dominant answer for mixed deals is the predominant purpose (or "predominant factor") test, drawn from the seminal mixed-goods-and-services case Bonebrake v. Cox, 499 F.2d 951 (8th Cir. 1974). Under that test, a court asks whether the predominant thrust of the transaction is the sale of a good (UCC applies to the whole contract) or the provision of a service (common law applies). A shrink-wrapped, off-the-shelf program tends to be treated as a good; a heavily customized system built to order tends to be treated as a service; and the gray middle is litigated case by case. An influential early decision, Advent Systems Ltd. v. Unisys Corp., 925 F.2d 670 (3d Cir. 1991), held that software--even custom software in that case--qualified as a "good" under the UCC, reasoning that a program does not stop being a good merely because it embodies intellectual effort. Other courts have leaned the other way for bespoke development, and SaaS poses the question afresh: a contract for access to remotely hosted software, with no copy ever delivered, is a poor fit for a statute about movable things, and courts and commentators increasingly treat pure SaaS as a service governed by common law. The result is a doctrine that is coherent in theory and unpredictable in application.

Why It Matters: A Tale of Two Warranties

The abstraction becomes concrete the moment a product fails. Suppose Vendor Corp licenses a payroll program to Acme, and the program miscalculates overtime, causing real losses.

If the deal is governed by Article 2, Acme may invoke the implied warranty of merchantability (the software is fit for the ordinary purposes of payroll software) and, if Vendor knew Acme's particular needs, the implied warranty of fitness for a particular purpose--unless Vendor effectively disclaimed them. Article 2 lets sellers disclaim implied warranties, but only by following its rules: a merchantability disclaimer must mention "merchantability" and, if written, be conspicuous; an "as is" sale disclaims implied warranties (UCC § 2-316). This is precisely why software license agreements shout, in ALL CAPS, that "THE SOFTWARE IS PROVIDED 'AS IS' WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE." That conspicuous shouting is not lawyers being dramatic; it is them satisfying § 2-316's conspicuousness requirement to make the disclaimer stick.

If the deal is governed by the common law of services, those implied warranties may not arise at all, and Acme is generally limited to whatever express warranties Vendor chose to give. The statute of limitations may differ. The rules for forming the contract over conflicting forms differ. Same failure, materially different legal toolkit--turning on a characterization question the parties may never have discussed.

The drafting lesson is liberating: because both regimes largely permit the parties to allocate quality risk by contract, a well-drafted software agreement answers the question itself. It states its own warranties expressly, disclaims everything else conspicuously enough to satisfy § 2-316 if Article 2 ever applies, sets its own limitation period, and specifies governing law. Good drafting renders the goods-versus-services debate largely academic--which is exactly why sophisticated software contracts are so explicit about warranties and disclaimers. For how those provisions are negotiated line by line, see Drafting Software License Agreements--Key Terms and Negotiation Points.

The Ghost of UCITA: The Law That Almost Was

The uncertainty above was supposed to be solved by a purpose-built statute. In 1999, the National Conference of Commissioners on Uniform State Laws (now the Uniform Law Commission) promulgated the Uniform Computer Information Transactions Act (UCITA)--a comprehensive model statute designed to be the "Article 2 for software." UCITA tried to provide tailored rules for licensing computer information: how electronic contracts form, when mass-market terms bind, what warranties attach to information products, and how disputes resolve.

UCITA is one of the great cautionary tales in American commercial law, because it failed--and failed loudly. Critics, including many state attorneys general, consumer advocates, and library and technology groups, attacked it as too vendor-friendly: they objected to provisions that appeared to bless restrictive mass-market click-through terms, to permit electronic self-help (a vendor remotely disabling software upon an alleged breach), and to validate broad warranty disclaimers and limitations. Only two states--Maryland and Virginia--ever enacted UCITA. It was effectively abandoned; the Uniform Law Commission stopped actively promoting it in the early 2000s.

The backlash went further than mere non-adoption. Several states--including North Carolina, Iowa, West Virginia, and Vermont--passed so-called anti-UCITA or "bomb-shelter" statutes designed to protect their residents from UCITA's reach, providing that a choice-of-law clause selecting a UCITA state would not be enforced to apply UCITA to their citizens. It is a rare thing for legislatures to pass laws whose entire purpose is to repel another state's statute, and it tells you how fierce the fight was.

The practical upshot for 2026: outside Maryland and Virginia, software contracts are still governed by the patchwork of UCC Article 2 (where software is treated as a good), common-law contract principles (where it is treated as a service or pure information), and--above all--the parties' own carefully drafted terms. The lesson UCITA's failure teaches every drafter is the same one the warranty discussion teaches: do not rely on a default statute to fill your gaps for software; write the deal yourself.

A Note on International and Choice-of-Law Wrinkles

Cross-border software deals add another layer. The United Nations Convention on Contracts for the International Sale of Goods (CISG) governs many international sales of goods between parties in signatory countries by default, and whether it reaches software (especially downloaded or hosted software) is itself contested--which is why international software contracts routinely opt out of the CISG expressly. Governing-law and forum-selection clauses therefore do heavy lifting in software agreements, and they should be chosen deliberately rather than copied from a form. Data-localization and export-control rules add still more cross-border friction, but the contracts-law point is simple: in a global software deal, never leave the governing law to chance.

How Software Contracts Are Formed: Clickwrap, Browsewrap, and "I Agree"

Before any of the substance matters, a contract has to exist. For most enterprise software, formation is ordinary: two parties negotiate and sign a written master agreement. But an enormous share of software is licensed through mass-market electronic contracts--the click-throughs, scroll-wraps, and terms-of-service links you accept constantly--and whether those bind has produced a rich, practical body of law.

The terminology has settled into a few categories. Clickwrap (or clickthrough) agreements require the user to take an affirmative action--clicking a box or button labeled "I agree"--after being presented with the terms. Browsewrap agreements purport to bind the user merely by using the website or software, with the terms available behind a hyperlink that the user need not open or affirmatively accept. Scrollwrap requires scrolling through the terms before assent. Shrinkwrap is the older, physical analog: terms printed on or inside the box, deemed accepted by opening the package or installing the software.

The doctrinal throughline is old-fashioned contract law: was there reasonable notice of the terms, and manifestation of assent to them? Four cases anchor the analysis.

Clickwrap and "money now, terms later" generally work. In ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), Judge Easterbrook enforced shrinkwrap license terms that restricted a buyer's use of a CD-ROM database, reasoning that terms inside a package can bind a buyer who has an opportunity to review them and reject the product by returning it. ProCD is the foundational decision validating mass-market software licensing in which payment precedes the chance to read the full terms.

Burying terms behind a passive link often fails. In Specht v. Netscape Communications Corp., 306 F.3d 17 (2d Cir. 2002), the Second Circuit (in an opinion by then-Judge Sotomayor) refused to enforce an arbitration clause in a browsewrap license where users could download free software without ever encountering the terms, which sat below the download button. The lesson: if a reasonable user would not even see the terms before acting, there is no assent and no contract. The browsewrap problem recurred in Nguyen v. Barnes & Noble, Inc., 763 F.3d 1171 (9th Cir. 2014), where the Ninth Circuit declined to enforce terms available only via a hyperlink, holding that the mere presence of a "Terms of Use" link, without more, does not put a reasonable user on constructive notice.

Conspicuous design plus a clear action wins. In Meyer v. Uber Technologies, Inc., 868 F.3d 66 (2d Cir. 2017), the court enforced terms presented on a registration screen where a reasonably conspicuous notice told the user that creating an account meant agreeing to the linked terms--a hybrid sometimes called "sign-in-wrap." The decision is a practical blueprint: present the terms (or a clear link) right at the point of assent, and pair them with an unambiguous action.

A historically important wrinkle worth knowing: in Step-Saver Data Systems, Inc. v. Wyse Technology, 939 F.2d 91 (3d Cir. 1991), the court treated a box-top license as a proposed modification to an already-formed contract under UCC § 2-207 and refused to enforce its disclaimers where the parties had already struck their deal by phone and purchase order. Step-Saver and ProCD sit in tension, and the modern reconciliation is that timing and notice control: terms presented before assent and clearly tied to it tend to bind; terms sprung after a deal is already complete face a much harder road.

The drafting and design takeaways are concrete: require an affirmative click; present the terms or a conspicuous link at the moment of assent; avoid pure passive browsewrap for anything important (especially arbitration and class-action waivers); keep records of which version each user accepted and when; and remember that the same notice-and-assent principles govern your privacy policy and end-user license. For the consumer-facing side of this in apps and online services, see Protecting Your Mobile App--A Comprehensive IP Strategy Guide and Social Media Law Basics.

License Versus Sale: Why "I Bought It" Is Usually Wrong

Return to the hospital from our opening, convinced it owns a copy of its records system. Whether that is true matters enormously, because of a copyright doctrine called the first sale doctrine (17 U.S.C. § 109). The first sale rule says that the owner of a lawfully made copy of a copyrighted work may resell, lend, or give away that copy without the copyright owner's permission--this is why you can sell a used book or a used DVD. If you own your copy of software, you may be able to resell it. If you are merely a licensee, you cannot--because you never owned a copy to sell in the first place.

Software vendors learned to exploit this distinction with surgical precision. The leading case is Vernor v. Autodesk, Inc., 621 F.3d 1102 (9th Cir. 2010). Timothy Vernor bought used copies of Autodesk's AutoCAD software at an office sale and tried to resell them on eBay; Autodesk objected. The Ninth Circuit held that the original transferee was a licensee, not an owner, so the first sale doctrine did not apply and the copies could not be freely resold. The court articulated a three-factor test: a user is a licensee rather than an owner where 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. Most commercial software licenses are drafted, deliberately, to satisfy all three--which is why "you don't own this, you license it" is the default reality of the software economy.

The practical consequences ripple outward. A licensee generally cannot resell or transfer the software without consent, which matters in mergers and asset sales (discussed below). A licensee's rights end when the license ends. And the much-litigated question of whether you can resell "used" software licenses has come out very differently in the United States (largely no, under Vernor) than in the European Union, where the Court of Justice's UsedSoft v. Oracle decision (2012) permitted resale of "used" downloaded software licenses under EU exhaustion principles--a sharp transatlantic split worth knowing for any global deal. For the foundational license mechanics, see Software Licensing Agreements and the broader Software Licensing Agreements--An Overview.

Who Owns What Gets Built: IP Ownership in Development Deals

Now the robotics startup's problem--and the single most important thing to understand about development agreements. The intuition is universal and the law is unforgiving: "I paid for it" does not, by itself, mean "I own it."

Software is protected by copyright the instant it is fixed in a tangible medium (17 U.S.C. § 102), and copyright vests initially in the author--the person who created the work (17 U.S.C. § 201(a)). When you hire an outside developer to write code, the developer is the author and the default owner of the copyright, even though you paid for the work, unless one of two things happens: the work qualifies as a work made for hire, or the developer assigns the copyright to you in a signed writing.

The Work-Made-for-Hire Trap

Under 17 U.S.C. § 101, a "work made for hire" is either (a) a work prepared by an employee within the scope of employment, or (b) a work specially ordered or commissioned that falls into one of nine enumerated categories and is the subject of a signed written agreement saying it is a work made for hire. Two traps lurk here.

First, independent contractors are not employees. The Supreme Court in Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), applied common-law agency factors--control over the work, source of tools, skill required, tax and benefits treatment, and more--to determine that a sculptor hired to create a statue was an independent contractor, not an employee, so his work was not "for hire" under prong (a). The same analysis routinely makes outside software developers contractors rather than employees.

Second--and this is the trap that catches even sophisticated buyers--custom software is generally not one of the nine enumerated categories for commissioned works. The nine categories (contributions to collective works, parts of motion pictures or audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases) do not squarely include ordinary application software. So even a contract that says "this is a work made for hire" may not actually transfer ownership of custom code, because the statutory prerequisites are not met.

The cure is simple to state and easy to forget: the development agreement must contain a present, express assignment of all intellectual property rights from the developer to the customer ("Developer hereby assigns to Customer all right, title, and interest in and to the Deliverables, including all intellectual property rights therein"), ideally backed up by a "work made for hire to the extent applicable, and otherwise hereby assigned" belt-and-suspenders clause, plus a further-assurances covenant requiring the developer to sign whatever documents are later needed to perfect and record the assignment. The leading cautionary tale is Effects Associates, Inc. v. Cohen, 908 F.2d 555 (9th Cir. 1990): where a filmmaker commissioned special-effects footage but obtained no written transfer, the court held the creator retained the copyright and the customer received only an implied nonexclusive license to use the footage--enough to use it, not enough to own or exclude others. Many a company has commissioned and paid full freight for software only to discover, years later during a financing or acquisition, that it holds nothing but an implied license to a product it thought it owned.

Background IP, Residuals, and the Real-World Compromise

Even with a clean assignment, ownership is rarely all-or-nothing in practice, because developers reuse background technology--their pre-existing tools, libraries, frameworks, and know-how. A developer cannot realistically assign away the general toolkit it brings to every engagement, and a customer does not want to be sued for using the very deliverable it paid for. The standard compromise: the customer owns the deliverables (the custom code written for it), the developer retains its pre-existing background IP, and the developer grants the customer a broad, perpetual, royalty-free license to any background IP embedded in the deliverables so the customer can actually use what it bought. The agreement should also address residuals (the developer's right to use general ideas, concepts, and know-how retained in memory) and any open-source or third-party components incorporated into the work.

These ownership questions are inseparable from the employee side of the equation: a company's developers should be under robust invention-assignment agreements so the company actually owns what its own people create, and contractors should be under the assignment language above. For the employee dimension, see Employee Invention Assignment Agreements--Drafting for Enforceability Across Jurisdictions; for the confidentiality scaffolding that protects what gets built, see Drafting Enforceable Non-Disclosure Agreements for Technology Transactions.

The Commercial Terms That Actually Allocate Risk

Once you know the deal type, the governing law, and the ownership picture, the negotiation moves to the provisions that allocate money and risk when things go wrong. These appear in nearly every software agreement, and their interactions--not any single clause--determine who bears the loss.

The Grant and Its Scope

The license grant (or, in SaaS, the right to access) is the heart of the deal: who may use the software, for what purposes, in what territory, on how many machines or for how many users, and with what restrictions. Scope is where vendors make money and where customers create unbudgeted liability. A grant limited to a "named user" count, or to a particular legal entity, can expose a growing or restructuring customer to audit claims if it exceeds the licensed metric. Customers should negotiate for affiliates, reasonable growth, and clear, fair measurement metrics; vendors should define the metric precisely so it is auditable.

Warranties and Disclaimers

As discussed under the Article 2 analysis, software agreements typically give a narrow express warranty (the software will perform materially in accordance with its documentation for some period, e.g., 90 days) with a limited exclusive remedy (repair, replace, or refund), and then disclaim all other warranties, conspicuously, in capital letters. The customer's leverage is in the express warranty: its scope, its duration, and--crucially--whether the "exclusive remedy" actually fixes the customer's problem. A repair-or-replace remedy is cold comfort if the software simply cannot do what the customer needs; watch for whether the remedy "fails of its essential purpose" (UCC § 2-719(2)), a doctrine that can revive other remedies when the contractual one proves illusory.

Indemnification (Especially IP Indemnity)

Indemnification is one party's promise to defend and cover the other against specified third-party claims. The marquee software indemnity is the IP infringement indemnity: the vendor's promise to defend the customer if a third party claims the software infringes a patent, copyright, or trade secret, and to cover resulting damages. This is essential protection--the customer did not build the software and cannot assess whether it infringes--but vendors hedge it heavily with carve-outs (no coverage for customer modifications, combinations with non-vendor products, or use outside the license) and with a remedy cascade: if a claim arises, the vendor may, at its option, procure the right to continue using the software, modify it to be non-infringing, or--last resort--terminate and refund. Customers should scrutinize whether that cascade leaves them stranded, and should negotiate the cap treatment of indemnity obligations (often, IP indemnity is carved out of the general liability cap). In channel deals the indemnity gets more complicated still, because the licensor, the VAR or OEM, and the end user each want protection and each may have introduced the infringing element. For why this indemnity is so live an issue today, see Open Source Licensing Landmines in Enterprise Software Development and Conducting Freedom-to-Operate Analysis for New Products.

Limitation of Liability

If indemnity is the sword, the limitation of liability clause is the shield--and it is usually the most heavily negotiated provision in the entire agreement. It typically does two things: (1) excludes consequential, incidental, and indirect damages (lost profits, lost data, business interruption), and (2) caps total liability at a dollar figure, often tied to fees paid (e.g., "amounts paid in the 12 months preceding the claim"). The fights are over the cap multiple, what is excluded from the cap (common "super-cap" or uncapped carve-outs include IP indemnity, breach of confidentiality, data-breach liability, and gross negligence or willful misconduct), and whether the consequential-damages waiver swallows the customer's real remedy. A liability cap of "fees paid" can be cruelly inadequate against a six-figure subscription that causes a multimillion-dollar data breach--which is why data-breach and confidentiality carve-outs have become front-line issues.

Service Levels (the SaaS Heartbeat)

In SaaS and hosted deals, the service level agreement (SLA) is what a warranty is to packaged software: the promise of availability (uptime, often expressed as "99.9%"), performance, and support responsiveness, with service credits as the remedy for missing them. Two cautions for customers: service credits are usually a percentage discount, not real damages, and are often the sole remedy for downtime; and the uptime percentage is meaningless without the definitions--what counts as "downtime," what exclusions apply (scheduled maintenance, force majeure, customer-caused outages), and how it is measured. A "99.9% uptime" with enough exclusions can be worth very little. For mission-critical systems, customers should also negotiate a termination right if downtime persists past a threshold, because credits alone do not solve a business that simply cannot run.

Data Ownership, Privacy, and Security

Where the vendor holds the customer's data--every SaaS deal, and many others--the contract must answer several questions. Who owns the customer data? (It should expressly remain the customer's.) What may the vendor do with it? (Beware broad "improve our services" or AI-training license grants buried in the terms.) How is it protected? (Security standards, encryption, audit rights, certifications like SOC 2 or ISO 27001.) What happens on a breach? (Notification timing, cooperation, liability.) And what happens at termination? (Data export in a usable format, and deletion.) If the data includes personal information, the contract must also satisfy privacy law--a data processing agreement (DPA) is typically required, allocating roles (controller/processor) and obligations under laws like the GDPR, the CCPA/CPRA, and the growing roster of U.S. state privacy statutes. For cross-border data flows, see International Data Transfers After Schrems II--Standard Contractual Clauses and Transfer Impact Assessments, and on the trade-secret stakes of cloud-hosted data, see Trade Secrets in the Age of Remote Work and Cloud Computing.

Open-Source Flow-Down: The Risk Inside the Code

Almost no modern software is written entirely from scratch; it is assembled, substantially, from open-source software (OSS) components. That is enormously productive and almost always benign--but open-source licenses carry obligations that can flow downstream through a transaction and attach to a buyer who never agreed to them and may not even know they are there.

Open-source licenses fall into two broad camps. Permissive licenses (MIT, BSD, Apache 2.0) ask little--usually just attribution and preservation of notices--and impose few constraints on combining the code with proprietary software. Copyleft licenses (the GPL family, and the network-triggered AGPL) are the ones that bite: they require that derivative works distributed to others be made available under the same license, including the source code. A company that unknowingly incorporates strongly copyleft code into its proprietary product and distributes it can face a demand to release its own source code--an existential problem for a software business whose value is its proprietary code. (Note the AGPL twist: it can be triggered by providing access over a network, which means even a SaaS provider that "distributes" nothing in the traditional sense can incur copyleft obligations.)

In a transaction, this is the flow-down problem. The development agreement should require the developer to disclose every open-source component and its license, to avoid copyleft-contaminating components in deliverables intended to stay proprietary, and to warrant and indemnify against undisclosed OSS obligations. In M&A, OSS is a core diligence item: acquirers scan the target's codebase (often with a software bill of materials, or SBOM, and automated composition-analysis tools) to find license obligations that could encumber the very asset being bought. The enforceability of these licenses is real, not theoretical--Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), held that open-source license conditions are enforceable copyright conditions, so violating them can be copyright infringement, not merely breach of contract. For the full treatment, see Open Source Software and the practical Open Source Compliance Checklists--The Complete Collection.

Professional Services and the Statement of Work

Many software deals include professional services--implementation, configuration, integration, data migration, training--governed by a statement of work (SOW) that hangs off a master services agreement (MSA). The MSA sets the standing terms (IP, confidentiality, liability, governing law); each SOW describes a specific engagement: scope, deliverables, timeline, acceptance criteria, fees, and assumptions.

The recurring failure point is scope and acceptance. A vaguely worded SOW invites "scope creep" (the customer expecting more than the vendor priced) and acceptance disputes (the customer refusing to sign off, the vendor claiming completion). Good SOWs define acceptance criteria and an acceptance procedure--the customer tests deliverables against agreed criteria within a defined window, with a cure process for failures and a deemed-acceptance default if the customer goes silent. They also fix change control: how scope changes get priced and approved in writing, so that "while you're in there, can you also..." does not become unbillable obligation. Agile engagements make all of this harder, because requirements deliberately evolve; the contract must define value and acceptance per sprint rather than against a frozen specification. See again Navigating the Legal Landscape of Agile Software Development and, for the startup-stage paperwork that frames many of these deals, Popular Legal Documents for Startups.

Source-Code Escrow: A Safety Net for "What If the Vendor Disappears?"

Here is a problem unique to software. When Acme licenses an on-premises program in object code (the compiled, machine-readable form), it gets a working product but not the source code--the human-readable form needed to fix, modify, or maintain the software. The vendor keeps the source code as its crown-jewel trade secret, because source code is the "key" a competitor would need to copy or reverse-engineer the product. But what if the vendor goes bankrupt, is acquired by a competitor, or simply stops supporting the product? Acme could be left running mission-critical software it cannot maintain.

The classic answer is source-code escrow. A neutral third-party escrow agent holds a copy of the source code (and build instructions, documentation, and dependencies), to be released to the licensee only upon defined trigger events--typically the vendor's bankruptcy, cessation of business, or material failure to support the product. Done well, escrow gives the customer a maintenance safety net without surrendering the vendor's secret. Done poorly, it is theater: the deposited code is stale, incomplete, or unbuildable. A useful escrow arrangement therefore requires verified, current deposits (the agent or a technical reviewer confirms the deposit actually compiles into the product), narrowly defined and genuinely protective release conditions, and a license, surviving release, that lets the customer actually use the released source for maintenance.

A bankruptcy wrinkle worth knowing: when a software vendor files for bankruptcy and rejects its license agreements, a special provision of the Bankruptcy Code--§ 365(n)--lets a licensee of intellectual property elect to retain its license rights despite the rejection, an important protection that pairs naturally with escrow. The interaction of escrow, § 365(n), and bankruptcy rejection is technical, but the headline is reassuring: a licensee is not necessarily helpless when its vendor fails.

Cloud and SaaS Escrow: A Different Safety Net for a Different Problem

In a pure SaaS world, traditional source-code escrow is an awkward fit. The customer never runs the software anyway, and the thing it stands to lose is not the source code but the running production environment--the live application and, above all, its own data--all of which sit on infrastructure the provider controls. If the provider suffers a service failure, defaults on its obligations, "pulls the plug," becomes insolvent, or is forced to sell the asset, the customer can lose access to both the application and the data inside it overnight.

The market's response is cloud software escrow (sometimes "SaaS continuity" or "data-and-application escrow"). Rather than depositing only source code, these arrangements aim to ensure the customer can keep accessing and operating the cloud-hosted application and retrieving its stored data if the provider wrongfully fails to deliver the service. Structures vary--some deposit the application's source plus deployment scripts and configuration so the application can be rebuilt elsewhere; some replicate the running environment with a standby provider; some focus on guaranteed, periodic export of the customer's data in a usable format. The goal is the same in every case: business continuity, minimized disruption to essential functions that depend on the application or its data, and management of the legal, regulatory, operational, and financial risk that a sudden loss of access creates. The conceptual point carries across both worlds: plan now for the vendor's disappearance later, and tailor the safety net to what you would actually lose--source code in the on-premises world, the live environment and your data in the cloud.

When Software Changes Hands: M&A and Asset Transfers

Software is often the most valuable asset in a corporate transaction, and moving it from one owner to another raises questions that catch dealmakers off guard. This is also where all the earlier doctrines come home to roost: the license-versus-ownership distinction, the work-made-for-hire trap, and open-source flow-down each resurface as diligence findings that can move price or kill a deal.

First, the anti-assignment problem. Recall that customers usually hold licenses, not ownership. Many license agreements prohibit assignment without the licensor's consent--and some treat even a change of control (a merger or stock sale) as a deemed assignment requiring consent. So when Buyer acquires Target, Target's valuable software licenses may not transfer automatically; Buyer may need hundreds of vendor consents, each an opportunity for a vendor to demand a fee or renegotiate. This is a standard, and sometimes deal-shaping, diligence item. The structure of the deal changes which licenses bite: an asset purchase transfers only specified, assignable contracts (so non-assignable licenses simply do not come along), while a stock sale or merger keeps the entity--and its contracts--intact but trips change-of-control clauses. Carve-out transactions add a further wrinkle: if the seller held an enterprise license covering affiliates that are being spun out, the deal must address how those entities will keep using the software after closing.

Second, IP chain of title. Buyer wants assurance that Target actually owns the software it claims to own--which loops back to the development-agreement ownership rules above. Diligence frequently uncovers code written by contractors who never signed assignments (leaving Target with a mere implied license, à la Effects Associates), employees in jurisdictions with quirky invention-assignment rules, or co-developed and jointly owned code with murky ownership. Diligence teams therefore map how the target's IT reaches customers (physical copies, downloads, restricted portals, SaaS, or through OEMs, VARs, and resellers), and whether downstream distributors pass through enforceable EULAs that the target can actually enforce. A gap in the chain of title, or a distribution structure the target cannot police, can reduce the value of the deal or require pre-closing cleanup.

Third, open-source and third-party obligations that travel with the code (covered above), export-control classifications for software with encryption or sensitive functionality, and privacy and data-security exposure for any target that holds personal data in the cloud--often a separate diligence workstream of its own. The structured practice materials on software, cloud, and IT due diligence in M&A walk through the document requests in detail; the strategic point is that software diligence is where the abstractions of this article turn into a number on a term sheet. For how corporate structure interacts with asset ownership and risk, see Corporate Structuring and Running Multiple Businesses--A Deep Dive into Holding, Operating, and Parent Companies.

Where the Disputes Actually Come From

Theory is one thing; the cases on a litigator's desk are another. Software-license disputes tend to erupt from a short list of recurring fault lines, and knowing them helps you draft to avoid them.

The most common trigger is ambiguous scope: the parties negotiate the headline business terms carefully but leave the operative language loose, and later read the same words differently--how many "users" the metric covers, whether affiliates are included, what counts as "the software" after years of updates. The second is acceptance and performance: the customer says the software does not do what was promised and withholds payment; the vendor says it conforms to the documentation and suspends the license; both escalate. The third is the suspension/termination spiral, which is uniquely dangerous in software because the consequences are immediate and operational. A vendor that suspends a license over a payment dispute can paralyze a customer that runs its ERP, CRM, e-commerce, or customer-facing search on that software--turning a modest billing disagreement into an existential threat to the customer's business, and, for the vendor, into lost revenue, diverted resources, and reputational harm. The fourth is the cluster this article has emphasized: ownership and IP fights in development deals, and open-source surprises discovered too late.

The practical lessons run through this whole article. Define the metric precisely. Build a real acceptance procedure with cure rights and deemed acceptance. Make termination and suspension rights proportionate, with notice and cure periods, so a billing skirmish cannot instantly cripple a business that depends on the software. Assign the IP in the present tense. Disclose the open source. And remember that the cost of a software dispute is rarely just legal fees--for the licensee it is operational paralysis, and for the licensor it is lost revenue and a damaged reputation. For the broader dispute-resolution toolkit, see Arbitration--A Comprehensive Guide to Alternative Dispute Resolution.

A Worked Hypothetical: Putting It All Together

Let's run a single deal through the whole framework, because the concepts come alive when they collide. The following is illustrative and hypothetical.

Northwind Logistics, a mid-sized freight company, wants a custom route-optimization platform. It hires DevShop, an outside developer, to build the core engine (a development deal), and it will access the finished platform as a hosted service that DevShop will operate (a SaaS deal), with DevShop's people providing implementation and integration services (a professional-services SOW). Northwind also plans to let logistics partners resell access to the platform under their own brands (a channel deal). One relationship, all four families of software transaction.

Which law? The development and services components look service-like (common law); the hosted-access component looks like neither a classic good nor a service and is best treated as a service. Rather than litigate the question later, the parties draft expressly: their own warranties, conspicuous disclaimers (in case Article 2 ever reaches any piece), governing law, an opt-out of the CISG for any cross-border element, and a clear limitation period.

Who owns the engine? Critical. Without a present assignment, DevShop--as author--owns the custom code, and Northwind holds only an implied license (Effects Associates). Calling it a "work made for hire" likely fails, because custom logistics software is not one of § 101's nine categories and DevShop's coders are contractors, not Northwind employees (Reid). So Northwind insists on an express present assignment of the deliverables, a license-back of DevShop's background libraries embedded in the engine, and a further-assurances covenant.

Open source? DevShop's engine pulls in several OSS components. Northwind requires a disclosed bill of materials, prohibits strong-copyleft and AGPL contamination of the proprietary engine, and obtains a warranty and indemnity against undisclosed OSS obligations--because if the engine secretly inherited copyleft obligations, Northwind's "proprietary" platform might not be proprietary at all.

The channel. For the reseller layer, Northwind grants its partners a non-exclusive distribution right, decides whether partners pass through Northwind's EULA or grant their own at-least-as-protective sublicense, keeps Northwind a third-party beneficiary so it can enforce against end users, and structures any grantback of partner-built integrations as non-exclusive to stay clear of the antitrust concern flagged in the DOJ/FTC IP Licensing Guidelines.

Formation and ongoing access. End users will click through an end-user agreement to use the platform; Northwind designs a conspicuous clickwrap (Meyer), not a buried browsewrap (Specht, Nguyen), and logs which version each user accepted.

Risk allocation. DevShop gives a narrow performance warranty with a repair-or-replace remedy (Northwind checks it does not "fail of its essential purpose"), an IP indemnity carved out of the liability cap, an SLA with real uptime definitions, meaningful (not merely cosmetic) credits, and a termination right for chronic downtime, a DPA covering shipment and customer data, and a liability regime that uncaps data-breach and confidentiality exposure.

The vendor-disappears problem. Because Northwind will depend on this platform daily, it negotiates a cloud escrow: if DevShop fails or stops operating the service, Northwind can extract its data and a deployable copy of the engine and run it elsewhere--the SaaS-appropriate analog to source-code escrow.

Every one of those moves traces directly to a doctrine in this article. That is the payoff of the map: it turns a sprawling, intimidating contract into a checklist of questions you actually know how to ask.

Key Takeaways

Software transactions reward the lawyer or businessperson who slows down and asks four questions in order. What kind of deal is this?--license, SaaS, development, or channel, because each has a different center of gravity. What law governs?--Article 2 (if software is a good), common law (if a service), or, most importantly, the terms you write yourself, since UCITA's failure left no purpose-built statute outside Maryland and Virginia. Who owns what?--because "I paid for it" is not "I own it," and a development deal without a present IP assignment may leave the buyer holding only an implied license. And where is the risk?--in the interplay of warranties, indemnities, liability caps, SLAs, data and privacy terms, open-source flow-down, and the plan for the day the vendor disappears.

Above all, software contracts reward explicitness. The default rules are uncertain and the technology outruns the statutes, so the discipline is to leave nothing to be filled in by a body of law that was never designed for software. Write the warranties. Disclaim the rest, conspicuously. Assign the IP in the present tense. Disclose the open source. Define acceptance. Make suspension and termination proportionate. Plan for failure. Do those things, and the legendary uncertainty of software law becomes, mostly, somebody else's problem.

Frequently Asked Questions

Is buying software a "sale of goods" governed by the UCC? It depends, and the law is genuinely unsettled. Courts apply the predominant purpose test (from Bonebrake v. Cox): if the deal's main thrust is delivering a product, UCC Article 2 tends to apply; if it is providing a service (like custom development), common law tends to apply. Off-the-shelf packaged software often looks like a good (Advent Systems v. Unisys); SaaS, where nothing is delivered, looks least like one and is increasingly treated as a service. The practical answer is to draft your own warranties, disclaimers, and governing-law terms so the characterization matters as little as possible.

Whatever happened to UCITA, the "software UCC"? It failed. The Uniform Computer Information Transactions Act was promulgated in 1999 to be a tailored statute for software and computer-information licensing, but critics attacked it as too vendor-friendly--especially its tolerance of restrictive mass-market terms and electronic self-help. Only Maryland and Virginia adopted it, and several states (including North Carolina, Iowa, West Virginia, and Vermont) passed "bomb-shelter" anti-UCITA laws to shield their residents. Outside those two states, software contracts rest on the UCC/common-law patchwork plus the parties' own terms.

Do I own custom software just because I paid a developer to build it? Usually not, unless your contract says so in the right way. Copyright vests initially in the author--the developer--and an outside developer is typically an independent contractor, not your employee (CCNV v. Reid). Custom software is generally not one of the nine "work made for hire" categories, so a "work made for hire" label alone may not transfer ownership. Without a present, written assignment of the IP, you may hold only an implied license to use the work (Effects Associates v. Cohen). Always include an express assignment plus a further-assurances clause.

Are the "I Agree" click-throughs actually binding contracts? Often yes--if they are designed for notice and assent. Clickwrap agreements that require an affirmative "I agree" after presenting the terms are generally enforced (ProCD v. Zeidenberg; Meyer v. Uber). Passive browsewrap--terms hidden behind a link the user need never see--frequently is not (Specht v. Netscape; Nguyen v. Barnes & Noble). Present the terms at the moment of assent, require a clear action, and keep records of which version each user accepted.

Can I resell software I no longer use? Usually no, in the United States. Most software is licensed, not sold, so the copyright first-sale doctrine (which lets you resell a book or DVD you own) does not apply. In Vernor v. Autodesk, the Ninth Circuit held that a user who is granted a license, restricted in transfer, and subject to use restrictions is a licensee, not an owner--and cannot freely resell. (The EU reached a different result for downloaded software in UsedSoft v. Oracle, so cross-border answers vary.)

What is the difference between a VAR and an OEM? Both are software distributors that bundle a licensor's software into a larger product, but with a key difference. A value-added reseller (VAR) bundles the software with other software and usually distributes the combined product under its own branding--often advertising the licensor's component ("powered by"), which is why VAR deals typically include a trademark license. An OEM (original equipment manufacturer) bundles the software with equipment (hardware or a device) and ships an integrated product under the OEM's brand, usually with the licensor's software invisible to the end user. The license-grant, branding, source-code-access, and end-user-terms provisions differ accordingly.

What is source-code escrow, and is it different for SaaS? Traditional escrow is a safety net for licensees of on-premises software, who typically receive only object code. A neutral escrow agent holds the source code and releases it to the licensee only on defined triggers--usually the vendor's bankruptcy, cessation of business, or failure to support--and is worth negotiating for mission-critical software, but only if the deposit is verified and current. For SaaS it is different, because the customer never runs the software and what it stands to lose is the live environment and its own data, not the source. The analog is cloud escrow or SaaS continuity: an arrangement focused on letting the customer keep operating the application and retrieving its data elsewhere if the provider fails.

Why do liability caps matter so much in software deals? Because they decide who absorbs the loss when software fails. A typical clause excludes consequential damages (lost profits, lost data) and caps total liability at fees paid--which can be trivial against the cost of a serious data breach caused by a modestly priced subscription. The negotiation centers on the cap size and on what is carved out of the cap (commonly IP indemnity, confidentiality breaches, and data-breach liability). Read the cap together with the indemnity and SLA; no single clause tells the whole story.

What's the difference between a SaaS agreement and a software license? A traditional license gives you a copy of software to install and run yourself; a SaaS subscription gives you only access to software the vendor hosts, ending when you stop paying. The legal emphasis shifts accordingly: licenses focus on copying, installation, and use restrictions, while SaaS focuses on uptime/SLAs, data ownership and security, privacy compliance, and data return on termination. A SaaS contract written like an old box-software license is a misfit.

Related Articles

This article provides general information for educational purposes only and is not legal advice. Software transactions turn on specific facts, contract language, and jurisdiction-specific and fast-evolving law; consult qualified counsel before acting on anything discussed here.