If your company sells or distributes software, whether as a desktop application, a mobile app, an on-premise enterprise product, or an embedded system, the document that governs your relationship with end users is the End User License Agreement. Unlike a SaaS Terms of Service, which governs ongoing access to a cloud-hosted service, a EULA governs the grant of a license to use software that is installed or downloaded.
That distinction matters because the legal questions a EULA answers are different from those a SaaS agreement answers. A EULA must establish what the user is licensed to do with the software, what they are prohibited from doing, who owns the software (the licensor always does), what happens when the license ends, and what the licensor’s liability is for software defects. Get those questions wrong, and your business is exposed to IP claims you cannot defend, liability for software behavior you cannot predict, and enforcement problems you cannot fix.
This article explains what a EULA must include, how it differs from other software agreements, and where software companies make mistakes that undermine the agreement’s enforceability.
1. A EULA Is a License, Not a Sale
The most fundamental concept in EULA drafting is one that software companies frequently fail to communicate clearly: the end user does not buy the software. They buy a license to use it. This distinction has major legal and business consequences.
Under the first sale doctrine (17 U.S.C. § 109), when someone purchases a copy of a copyrighted work, they can resell, lend, or give away that specific copy. This doctrine, which applies to physical goods, would allow users who own a physical disc to resell the software on that disc. A properly drafted EULA makes clear that the transaction is a license, not a sale, which means the first sale doctrine does not apply and users cannot resell, sublicense, or transfer the software without the licensor’s consent.
Courts have generally upheld this license-not-sale framework when the EULA is presented to the user and accepted before access is granted. In Vernor v. Autodesk, Inc. (621 F.3d 1102, 9th Cir. 2010), the Ninth Circuit held that software users who agreed to Autodesk’s license terms were licensees, not owners, and therefore could not resell the software under the first sale doctrine. That outcome depended on specific language in the license agreement. Vague or absent license grant language leaves your software vulnerable to the opposite conclusion.
2. The License Grant: The Most Important Clause You Probably Underspecify
The license grant defines exactly what the user is permitted to do with the software. Most EULAs draft this clause too broadly and leave critical restrictions out, or draft it too narrowly and restrict legitimate use cases that frustrate users and damage customer relationships.
What the License Grant Must Specify
The license grant must identify the scope of use: how many users or installations are permitted, what platforms the software may be installed on, whether the license is perpetual or time-limited, and whether it covers commercial, non-commercial, or both categories of use.
It must state whether the license is transferable. If the user cannot assign the license to another party, the agreement must say so explicitly. If the user can transfer it with licensor consent, the process must be documented. Silent agreements get interpreted against the drafter.
It must address sublicensing. If the user is a business deploying the software to their employees or clients, the EULA must specify whether that downstream deployment is permitted, whether it requires additional licenses, and what terms apply to end users in that scenario. Enterprise software deployments frequently create disputes when the enterprise customer assumes the right to deploy to unlimited users and the EULA did not make this clear.
Restrictions Are Part of the Grant
The restrictions that follow the license grant are equally important. These typically include: prohibitions on reverse engineering, decompiling, or disassembling the software; prohibitions on creating derivative works; prohibitions on removing copyright notices or proprietary markings; and prohibitions on using the software to develop competing products.
Under the DMCA (17 U.S.C. § 1201), circumventing technological protection measures is prohibited independently of your EULA. But contractual prohibitions on reverse engineering give you an additional breach of contract claim against users who circumvent your protections, which may be easier to enforce in some jurisdictions than DMCA claims.
3. Ownership, Copyright, and Retained Rights
Every EULA must explicitly state that the licensor owns the software, all copies of it, and all derivative works. This is not implied by law in the same way that copyright ownership is implied by authorship. Users in a license relationship sometimes assert rights to customizations they make to licensed software, and a EULA that does not address this question creates a dispute about who owns what was built on top of your product.
The EULA should include a clause stating that any modifications, customizations, or derivative works created by the user using the software do not transfer any rights in the underlying software to the user, and that if the agreement permits users to create certain derivative works, those works are licensed back to the licensor or remain the user’s property without granting any rights in the underlying software.
For software that includes third-party components (open-source libraries, licensed frameworks, or embedded technology from other vendors), the EULA should disclose the existence of third-party components and note that separate license terms apply to those components. Failing to disclose open-source components in commercial software can create obligations under copyleft licenses that override your EULA’s terms.
4. Warranty Disclaimers: What You Can and Cannot Disclaim
The warranty disclaimer is one of the most legally significant clauses in any EULA. It is also one of the most frequently drafted too broadly, in ways courts decline to enforce.
What You Can Disclaim
Under the Uniform Commercial Code (UCC Article 2, applicable to software sales in many states), sellers can disclaim the implied warranty of merchantability and the implied warranty of fitness for a particular purpose if the disclaimer is conspicuous. Most EULA warranty disclaimers present this language in all caps to satisfy the conspicuousness requirement. A disclaimer buried in the same typeface as surrounding terms may not be enforceable.
For software distributed under a license-not-sale model, some state UCC provisions may not apply, but it is still best practice to include explicit warranty disclaimers to document the parties’ intent and to address implied warranties that exist under the common law of the applicable jurisdiction.
What You Cannot Disclaim
Consumer protection statutes in several states impose non-disclaimable warranties on software sold to consumers. California’s Song-Beverly Consumer Warranty Act, for example, requires that consumer goods sold in California include an implied warranty of merchantability that cannot be entirely disclaimed. If you sell software to consumers in California, a total warranty disclaimer may not be enforceable as written.
For business-to-business software, implied warranty disclaimers are more broadly enforceable, but they need to comply with the UCC’s conspicuousness and specificity requirements to be effective.
5. Limitation of Liability: Protecting Against Software Defect Claims
A limitation of liability clause caps your financial exposure when the software fails, produces errors, causes data loss, or otherwise causes harm to the user. Without a cap, a lawsuit arising from software defect can expose you to consequential damages that exceed the revenue you received from the user many times over.
The standard EULA limitation of liability clause limits the licensor’s total liability to the amount paid for the software in the prior twelve months, or to a specific dollar cap, and excludes liability for consequential, incidental, special, punitive, or exemplary damages. For software distributed at no charge (freemium models, trial versions), the twelve-month payment cap creates a zero-liability floor, which is appropriate but should be stated explicitly.
Courts scrutinize limitation of liability clauses in consumer contexts more carefully than in B2B contexts. A limitation of liability clause in consumer software that eliminates all liability for personal injury or property damage caused by defective software is unlikely to be enforced in most states. The EULA should be calibrated to the audience: broader exclusions for enterprise B2B software, more carefully scoped exclusions for consumer products.
6. EULA Acceptance and Enforceability
A EULA that users never read and never affirmatively accept is a weaker legal instrument than one with a documented acceptance mechanism. Courts consistently draw a distinction between click-through agreements (where users check a box or click “I Agree”) and browse-wrap or shrink-wrap agreements (where terms are referenced but not actively accepted).
Click-through acceptance, where the user must affirmatively check a box or click an “I Accept” button to proceed, is the strongest form of EULA acceptance. Courts have upheld click-through agreements consistently when the user was presented with the terms before acceptance and had a meaningful opportunity to review them.
For enterprise software, EULA acceptance is typically governed by a separate order form or enterprise license agreement that incorporates the EULA by reference. In those situations, the EULA is part of a broader contract signed by an authorized representative of the buyer, which is more enforceable than a click-through for most purposes.
Mobile app EULAs presented through app store flows (Apple App Store, Google Play) must comply with those platform’s requirements for how terms are displayed and accepted. The app store agreements impose their own legal terms on the relationship between the app developer and end users, which your EULA should not contradict.
7. What a Technology Lawyer Addresses That Templates Miss
Generic EULA templates from the internet address the standard clauses: license grant, restrictions, warranty disclaimer, limitation of liability. What they do not address is the specific risk profile of your product, your distribution model, your user base, and your jurisdiction.
A SaaS company that adds an installable desktop component to its product needs a EULA for that component and must reconcile it with the SaaS Terms of Service so users understand which agreement governs which aspect of the product. An enterprise software vendor with customers in the EU needs a EULA that addresses GDPR implications for any personal data processed by the software. A mobile app developer needs a EULA that works within the constraints imposed by Apple and Google’s platform agreements.
Technology lawyers who work with software companies review these product-specific risks and draft accordingly. The intellectual property practice at TOSLawyer works with software vendors, app developers, and enterprise technology companies on EULA drafting, software license agreements, and the broader IP framework that protects your product. If your current EULA was adapted from a template or written without a technology lawyer’s review, it is worth assessing what it actually covers before a dispute reveals the gaps.
Frequently Asked Questions
What is the difference between a EULA and a Terms of Service?
A EULA governs the license to use software that is installed or downloaded. A Terms of Service governs ongoing access to a cloud-hosted service. SaaS companies typically use Terms of Service because users access the software over the internet rather than installing it. Desktop applications, mobile apps, and on-premise enterprise software typically use EULAs because users install and run the software on their own devices. The legal questions they address overlap in some areas (ownership, permitted use, liability), but the structures differ because the relationship between the software company and the user is structured differently.
Do I need a EULA for a free app?
Yes. A EULA protects your IP ownership, limits your liability for software defects, and establishes what users can and cannot do with the software regardless of whether they paid for it. Free apps distributed at no charge are not exempt from copyright law, and users of free software can still assert claims arising from software defects or data loss. The limitation of liability clause in a EULA for a free app typically caps liability at zero (since no payment was made), but the other protections are still meaningful.
Can users sell or transfer their software license?
Only if your EULA permits it. The default under a properly drafted EULA is that the license is personal and non-transferable. If you want to permit transfers (for example, in a perpetual license model where enterprise customers may need to reassign licenses between employees or entities), the EULA should specify the conditions under which transfer is permitted and what process applies. Silent agreements create disputes.
What happens to the EULA if the user modifies the software?
A properly drafted EULA addresses this directly. Modifications to licensed software typically remain subject to the EULA, do not transfer any rights in the underlying software to the user, and may themselves be owned by the licensor depending on how the EULA is written. If you permit enterprise customers to customize the software, your EULA should specify what rights those customers have in their customizations and whether those customizations survive termination of the license.
My software uses open-source components. How does this affect my EULA?
Open-source components are subject to their own license terms, which exist independently of your EULA. Copyleft licenses (GPL, LGPL, AGPL) impose conditions on how the code can be distributed and whether the EULA’s terms are compatible with the open-source license. Permissive licenses (MIT, Apache, BSD) impose fewer restrictions but typically require attribution. A technology lawyer can review your software’s open-source component stack and identify conflicts between those licenses and your EULA’s terms before you distribute the product.
Make Sure Your EULA Actually Protects What It Claims To
A EULA that is never read, poorly drafted, or derived from a generic template may provide the appearance of legal protection without the substance. The specific language in the license grant, the warranty disclaimer, the limitation of liability, and the acceptance mechanism determines whether your EULA holds up when a user challenges your right to terminate their license, when a customer sues over software defects, or when a competitor argues they can reverse engineer your product.
If you distribute software and your EULA has not been reviewed by a technology lawyer with experience in software licensing, contact Hansen Tong at TOSLawyer.com. Our technology and intellectual property practice works with software companies on EULA drafting, software license structures, and the IP agreements that protect your product across its lifecycle.