Software License Agreements and EULAs: What Software Companies Should Include

What is a software license agreement or EULA?

A software license agreement, often presented to users as an end user license agreement (EULA), grants permission to use software without transferring ownership. It should define who may use the software, on which devices, where, and for how long, then address restrictions, IP ownership, open source, support, warranties, liability limits, IP indemnity, audits, termination, and export controls.

The word “license” matters. A license is permission to do something the owner could otherwise prevent. Copyright law gives a software publisher exclusive rights to reproduce and distribute its code, so the license agreement is the document that defines exactly which of those acts the customer may perform and on what conditions.

Software companies often need more than one version: a negotiated enterprise license, a click-through EULA for self-service users, or a subscription agreement for a hosted product. They share many clauses but allocate risk differently.

What is the difference between an EULA and terms of service?

An EULA governs use of a copy of software, such as an installed app or downloaded program. Terms of service govern access to an online service, including accounts, acceptable use, and content. Many products need both, or one combined agreement covering each.

The distinction tracks the delivery model. When a user installs software, the publisher is authorizing copies on the user’s device, so the agreement focuses on the license grant and copying restrictions. When a user logs in to a hosted platform, nothing is copied to the user in the same way; the agreement focuses on access rights, account security, user content, and service availability.

Mobile and desktop apps that connect to a cloud backend often blend the two. In that case, one agreement can include a license to the installed client and terms of service for the hosted features, provided the two parts do not contradict each other.

How does a SaaS subscription differ from an on-premise software license?

An on-premise license lets the customer install and run copies on its own systems, so it centers on installation limits, copying, and audits. A SaaS subscription grants access to software the vendor hosts, so it centers on uptime, data handling, security, and subscription term.

• Delivery: on-premise software is installed by the customer; SaaS is accessed through a browser or API.
• License metric: on-premise licenses often count installations, servers, cores, or named users; SaaS usually counts seats, usage, or tiers.
• Term: on-premise licenses may be perpetual with separate maintenance fees; SaaS rights typically end when the subscription ends.
• Data: SaaS agreements need confidentiality, security, and often a data processing agreement, because the vendor holds customer data.

What should the license grant cover?

The grant should state who may use the software, how many users or devices are covered, where it may be used, for how long, for what purpose, and whether the license is exclusive, transferable, or sublicensable.

Vague grants create disputes. If the agreement says “use by the customer” without defining customer, the parties may later disagree about affiliates, acquirers, or outsourced service providers.

• Users: named users, concurrent users, or an enterprise-wide grant, and whether affiliates and contractors may use the software on the customer’s behalf.
• Devices and environments: number of installations, servers, or instances, plus whether test, backup, and disaster recovery copies count.
• Territory: worldwide or limited to specific countries, which also connects to export control obligations.
• Term: perpetual, fixed term, or tied to a subscription, and what happens at renewal.
• Purpose: internal business use only, or broader rights such as embedding the software in the customer’s own products.
• Nature of the grant: nonexclusive, nontransferable, and non-sublicensable unless the deal specifically calls for something different.

Which restrictions and ownership terms protect the software?

The agreement should prohibit uses outside the grant, such as copying, reverse engineering, competitive benchmarking, or sharing credentials, and state that the publisher retains all rights, title, and interest not expressly granted.

Characterizing the transaction as a license rather than a sale also matters. The Copyright Act gives the owner of a copy of a computer program certain rights, such as making a copy needed to run it. Publishers that want to restrict resale and transfer generally structure distribution as a license with meaningful use and transfer limits, but how a court characterizes a particular transaction depends on the agreement and the facts.

• No copying, modifying, or creating derivative works except as the agreement permits.
• No reverse engineering, decompiling, or disassembling, to the extent applicable law allows the restriction.
• No renting, leasing, reselling, or providing the software to third parties as a service bureau.
• No removing proprietary notices or circumventing license keys and usage controls.
• Ownership of feedback, configurations, and customer data stated clearly, so the customer keeps its data while the publisher keeps its platform.

How should a software license agreement address open source components?

Disclose that the product includes open source components, state that those components are governed by their own licenses, and confirm that the company’s use complies with each license, especially copyleft licenses that can require source code disclosure.

Most commercial software contains open source code. Permissive licenses such as MIT, BSD, and Apache 2.0 generally require attribution and preservation of notices. Copyleft licenses such as the GPL can require a distributor to make the source code of a combined work available on the same terms, and the AGPL extends similar obligations to software made available over a network. Whether an obligation is triggered depends on how the component is used, linked, modified, and distributed.

Enterprise customers increasingly ask for an inventory of open source components, sometimes called a software bill of materials. A current inventory also helps the company avoid warranting that the product contains no copyleft code when it does.

How should warranties, liability limits, and IP indemnity work together?

Give narrow, specific warranties, disclaim implied warranties conspicuously, cap liability and exclude indirect damages, and offer an IP infringement indemnity with defined exclusions and remedies. Together these terms decide who bears the cost when something goes wrong.

Courts differ on whether the Uniform Commercial Code applies directly to software licenses, and some jurisdictions restrict how far a party may limit liability for its own fraud, willful misconduct, or certain statutory claims. Consumer-facing EULAs also face state consumer protection and automatic renewal laws. Drafting these provisions for the specific customer base and governing law reduces the chance that a key protection is unenforceable.

• Express warranties: commonly that the software will perform materially as documented for a stated period, with repair, replacement, or refund as the remedy.
• Disclaimers: implied warranties of merchantability and fitness for a particular purpose disclaimed in conspicuous text, following the approach of UCC Section 2-316.
• Limitation of liability: a cap tied to fees paid, an exclusion of consequential and lost profit damages, and any carve outs the parties agree to.
• IP indemnity: the publisher defends claims that the software infringes third-party IP, subject to prompt notice and control of the defense.
• Indemnity exclusions: customer modifications, combinations with non-supplied products, and use outside the documentation.
• Infringement remedies: the right to procure a license, modify the software, or terminate and refund prepaid fees.

What do audit, termination, and export control clauses do?

Audit clauses let the publisher verify license compliance, termination clauses define when rights end and what survives, and export control clauses allocate responsibility for complying with US export and sanctions rules.

Software, and especially software with encryption functionality, can be subject to the Export Administration Regulations administered by the Bureau of Industry and Security. Classification and any required filings depend on the product, so publishers should confirm their export position rather than relying on a contract clause alone.

• Audit rights: reasonable notice, limited frequency, confidentiality of the review, and payment of underlicensed fees, with audit costs shifting only above a stated threshold.
• Support and updates: whether maintenance is included, how long versions are supported, and whether updates are covered by the same license.
• Termination: rights to terminate for breach after a cure period, for nonpayment, or for convenience, and the effect on prepaid fees.
• Post termination duties: stop using the software, uninstall copies, certify deletion, and return or export customer data where relevant.
• Export controls: the customer’s promise not to export or provide access in violation of the Export Administration Regulations and sanctions laws.

Are clickwrap and browsewrap EULAs enforceable?

Courts generally enforce clickwrap agreements, where users must take an affirmative step such as checking a box or clicking “I agree.” Browsewrap terms, linked passively on a page, are enforced less consistently and typically only when the user had reasonable notice and manifested assent.

The questions courts ask are practical: Was the user shown the terms or a clear link to them? Was the notice conspicuous on the screen where the user acted? Did the user take an action that unambiguously signaled agreement? Design choices such as small gray link text, terms placed below the action button, or wording that does not tie the click to the terms have weakened enforcement in reported cases.

Keep records that can prove assent: the version of the EULA in effect, the date and time of acceptance, the user account, and a screenshot or specification of the acceptance screen.