How to Write a Software License Agreement

A software license agreement does one job that no other document does: it grants permission to use software that the licensee does not own and never will. Everything else in the agreement, the restrictions, the warranty disclaimer, the liability cap, exists to define the edges of that permission. Get the grant of license clause loose or vague, and every clause built on top of it inherits the same looseness.

This is a different document from a EULA, even though the two get used interchangeably in casual conversation. A EULA is written for a mass-market end user clicking “I agree” on an install screen, typically non-negotiable and the same for every buyer. A software license agreement is the document a vendor negotiates with a business customer, a reseller, or a partner, and it carries commercial terms, seat counts, and negotiated restrictions a shrink-wrap EULA never needs.

What a Grant of License Actually Grants

The grant of license clause is a single sentence that does most of the legal work in the document: “Licensor grants Licensee a [exclusive or non-exclusive], [perpetual or term-limited], [transferable or non-transferable] license to use the Software solely for [field of use].” Every bracket is a decision, and each one narrows or widens what the licensee is actually allowed to do.

Non-exclusive is the default for almost all commercial software. It means the licensor can sell the same license to as many other customers as it wants. Exclusive is rare and expensive: it means the licensor cannot license the software to anyone else, sometimes not even use it itself, for the duration of the agreement. A sole license sits between the two: the licensor agrees not to license to any other party, but keeps the right to use the software itself. Most vendors resist exclusive or sole terms unless the deal specifically pays for that exclusivity.

Field of use is the clause that limits what the license is for, not just who holds it. A license granted “for internal business operations” does not cover reselling access to the licensee’s own customers. A license granted for one product line does not extend to a subsidiary the licensee acquires next year. Vague field-of-use language is one of the most common sources of licensing disputes, because both sides assumed a scope the contract never actually stated.

Setting the Scope: Seats, Instances, and Field of Use

Scope is where the commercial terms live: the number of authorized users or seats, the number of devices or server instances the software can run on, whether use is per-employee or concurrent-user, and whether the license covers one legal entity or the licensee’s full corporate family. A ten-seat license used by fifteen people is a breach even if nobody intended it that way, which is why license audits exist and why vendors write overage terms into the agreement rather than leaving them to be negotiated after the fact.

The other scope decision that shapes the rest of the document is whether the license is perpetual or a subscription.

A perpetual license is paid once and, barring a breach, survives indefinitely, but it is almost always paired with a separate maintenance and support agreement that renews annually and is what actually funds ongoing updates. A subscription license ties continued access directly to continued payment, which is simpler to enforce and easier to reprice, and it is the default structure for anything delivered as SaaS rather than installed.

Restrictions That Belong in Every Software License

The restrictions clause is where the license grant gets its teeth. Every commercial software license needs, at minimum, a bar on reverse engineering, decompiling, or disassembling the software, a bar on sublicensing, reselling, or renting access without the licensor’s written consent, a requirement to keep copyright and proprietary notices intact, and a bar on using the software to build a competing product.

The reverse-engineering restriction has a genuine legal limit worth knowing before drafting one: in the EU, the Software Directive (2009/24/EC, Article 6) preserves a narrow right to decompile software for interoperability purposes even when a contract purports to forbid it entirely, and several US states carve out similar exceptions. A restriction that says “except to the extent such restriction is prohibited by applicable law” is not boilerplate padding, it is what keeps the clause enforceable in the jurisdictions where an absolute bar would not hold up.

Each clause in that order depends on the one before it. A restriction is only meaningful once the grant defines what was permitted in the first place, and a liability cap only matters once the warranty disclaimer has already limited what the licensor promised.

Warranty Disclaimers: Why “AS IS” Has to Be Conspicuous

Software is licensed “AS IS” as a matter of routine, but the word choice is not decoration. Under the Uniform Commercial Code (UCC Section 2-316), a disclaimer of the implied warranty of merchantability must be conspicuous and, in most states, must specifically use the word “merchantability” to be effective; a buried, fine-print disclaimer risks being unenforceable, which is exactly why these clauses are almost always set in full capital letters or bold type in the actual contract, not just for emphasis. The same clause typically disclaims the implied warranty of fitness for a particular purpose and any warranty of non-infringement, leaving only whatever express warranties the agreement separately states, if any.

There is a real difference in enforceability between those two columns, not just tone. A court asked to enforce a disclaimer that never named the specific warranty it was disclaiming, or that was printed in the same small type as the rest of the contract, has a real basis to strike it, which puts the licensor back on the hook for warranties it thought it had excluded.

Limitation of Liability and Termination

The limitation of liability clause usually does two things: it excludes indirect, incidental, and consequential damages entirely, and it caps whatever direct damages remain at a fixed number, most commonly the fees the licensee paid in the twelve months before the claim arose. Most agreements carve exceptions into that cap for IP infringement indemnification, confidentiality breaches, and gross negligence or willful misconduct, partly because many jurisdictions will not enforce a liability waiver against gross negligence regardless of what the contract says.

Termination closes the loop the grant of license opened. A termination-for-breach clause states what counts as a breach, whether the licensee gets a cure period before termination takes effect, and what has to happen once the license ends: cease all use, destroy or return copies, and confirm compliance in writing. A short list of clauses is written to survive termination regardless, typically confidentiality, the limitation of liability, and any payment obligations that accrued before the license ended.

Our EULA generator builds the mass-market end-user version of this document; for a negotiated business-to-business grant with seat counts, field-of-use limits, and a standalone warranty disclaimer, the clause order above is the one to follow directly in a custom agreement. For how a software license agreement differs from the EULA a buyer clicks through on install, see EULA vs Terms and Conditions; for how often companies actually get audited against the license terms they signed, see the 2026 software licensing audit data.

Getting the grant of license clause specific, naming the exclusivity, the term, and the field of use in one sentence, is what makes every other clause in the agreement enforceable rather than aspirational. Restrictions only restrict what was granted, and a warranty disclaimer only holds up when it is written the way the clause actually requires: conspicuous, specific, and never buried in the fine print.