Every EULA opens with some version of the same sentence: "licensed, not sold." Most founders skim past it and go looking for the parts that feel like they matter, restrictions, liability, termination, without realizing that sentence is the entire document's foundation. The license grant clause is where a EULA decides exactly what a user is allowed to do with your software, and just as importantly, what they are not. Get the scope right and every other clause in the document, restrictions, ownership, termination, has something solid to stand on. Get it vague or wrong, and you can end up either handing over rights you never meant to give away or writing a license so thin it doesn't actually cover how your software gets used.
What "licensed, not sold" actually means
Software you distribute to a user, whether it's a downloaded app, a desktop program, or a plugin, is almost always licensed rather than sold, even when the user pays a one-time fee and thinks of it as a purchase. The distinction isn't cosmetic. A sale transfers ownership of a specific copy to the buyer, who can then resell it, lend it, or do largely as they please with that copy under the first-sale doctrine. A license transfers nothing except permission: the software's owner (you, the licensor) retains title to every copy in existence, and the user (the licensee) receives only the specific rights the license grant clause spells out.
This distinction has been tested and upheld in court. In Vernor v. Autodesk (9th Circuit, 2010), the court held that a software transaction is a license, not a sale, when the copyright owner specifies that the user is granted a license, restricts the user's ability to transfer the software, and imposes notable use restrictions, exactly the pattern most EULAs already follow. The practical result is that a user who bought a one-time license to your desktop app generally cannot resell their copy the way they could resell a physical book, unless your license grant explicitly says they can. That's a meaningful protection, and it only exists because the grant clause is written as a license instead of a transfer of ownership.
The elements that actually make up a license grant
A functioning license grant clause is doing several jobs in one paragraph, and each one needs to be a deliberate choice rather than boilerplate copied from another product's EULA. In order, it typically defines who is granting the license (you) and to whom (the user or licensee), what type of use is permitted (install and run, or access and use, depending on whether the software is delivered as a local copy or a hosted service), whether the grant is exclusive or non-exclusive (almost always the latter, since an exclusive grant would stop you from licensing the same software to anyone else), whether it's transferable (almost always not, unless you specifically intend to allow resale), and what limits bound it, the number of devices or seats, a specific organization or individual, a territory, and a duration tied either to an active subscription or a one-time purchase.
The order these decisions get made in matters more than the exact wording you land on, since each answer narrows the next one.
The last step, a reservation-of-rights statement, is easy to treat as filler but does real work: a sentence like "all rights not expressly granted are reserved" closes the door on a user arguing that silence on some use they invented implies permission. Without it, an ambiguous grant tends to get read generously in the user's favor, and a court applying contra proferentem, the rule that ambiguity in a contract is construed against whoever drafted it, will lean the same way. That rule is exactly why vague drafting on your side of a EULA cuts against you, not for you.
What the clause actually gives your users
Once scoped, the grant gives a user a real, usable right: to install and run the software on the number of devices the license permits, or to access and use a hosted product under an active account, for the purpose the software is intended for. It typically also covers the ordinary incidents of that use that a user would reasonably expect, receiving updates and patches during an active license term, making a personal backup copy where the license says so, and using the software's normal output without a separate claim from you on that output. None of that is generous by accident. It's the minimum set of permissions someone needs in order to actually use what they licensed, and a grant clause that's missing any of it tends to generate support tickets and disputes over things that should have been settled in the document itself.
What it doesn't give them
This is the half of the clause that actually protects you, and it's also the half most templates handle sloppily. A license grant, by definition, conveys nothing beyond what it expressly states, which means ownership of the software, the source code, and the underlying intellectual property stays with you regardless of how the rest of the document is worded. A user generally has no right to modify the software, reverse engineer or decompile it, create derivative works from it, or extract and reuse its underlying code, unless the license grant (or a specific carve-out elsewhere in the document) says otherwise. They also can't resell, sublicense, rent, or redistribute their copy to anyone else, which is the direct consequence of the license being non-exclusive and non-transferable in the first place.
License grant vs. an outright sale
| Software license | Sale or assignment | |
|---|---|---|
| Who holds title to the copy | Stays with the licensor | Transfers to the buyer |
| Modify or reverse engineer | Prohibited unless expressly permitted | Generally allowed once owned |
| Resell your copy to someone else | Prohibited unless transferable | Allowed under first-sale doctrine |
| What ends your right to use it | Breach of the license terms | Nothing, once you own it |
| Duration | Defined by the license term | Indefinite, tied to ownership |
That last row is worth sitting with. Because a EULA grants a revocable license rather than transferring ownership, a user who breaches the agreement, using the software beyond the licensed scope, attempting to reverse engineer it, missing a subscription payment, can have that license terminated even though they already paid for it. That's not a loophole; it's the entire point of licensing software instead of selling it, and it's why the grant clause and the termination clause need to be read together rather than as unrelated sections of the document.
Why vague grant language backfires in both directions
A license grant that just says "Company grants you a license to use the Software" reads short and harmless, but it's actually a liability in two different directions at once. It's too thin to give a user confidence about what they're actually allowed to do, which generates disputes and support burden, and it's too vague to reliably stop the uses you didn't intend to permit, since an ambiguous grant tends to get interpreted against the party that drafted it. Specific, bounded language does more legal work in fewer surprises than an open-ended sentence that sounds broader but actually protects less.
- Grants a license to use the Software
- You may use it as permitted
- Non-exclusive license
- No unauthorized use
- Limited, non-exclusive, non-transferable license to install on 3 devices
- No right to sublicense, resell, or redistribute
- Terminates automatically on breach or subscription expiry
- All rights not expressly granted are reserved
The specific version isn't longer because it's trying to sound more official. Every added phrase is closing a question a user, or a court, could otherwise ask: how many devices, can they pass it to someone else, what happens if they break a rule, and does silence on some edge case mean permission. A grant clause that answers those questions up front is doing its job; one that leaves them open is passing the cost of that ambiguity on to whichever side ends up in a dispute over it.
Matching the grant to what your product actually is
The right scope depends heavily on what you're distributing. Installed software, a desktop program, a browser extension, a WordPress plugin, needs a grant built around install and run rights, tied to a device or seat count, since that's the actual mechanism by which the user is getting a copy onto hardware you don't control. A EULA for a web app or SaaS product is a different situation entirely: nothing gets installed, so the grant should be framed around access and use of a hosted service rather than install rights that don't apply, and in a lot of cases the access terms belong in Terms and Conditions instead of a EULA at all. If you're not sure which document your product actually needs, EULA vs Terms and Conditions walks through how to tell.
Getting the grant clause matched to your actual distribution model, rather than copied from a template built for a different one, is most of what separates a EULA that holds up from one that either overreaches or leaves gaps. Our EULA Generator builds the license grant from the specifics of what you're distributing, installed software or a hosted product, the number of devices or seats you intend to permit, and whether the license is perpetual or tied to a subscription, so the scope in the document matches how your software actually gets used instead of a generic grant sentence that either gives away too much or promises too little.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
