Scoping a Software License: Granting Exactly What You Intend
When a software company licenses its product, the license grant is the provision that defines what the customer is allowed to do with the software. It is the core of the deal from the licensor’s side, because it draws the line between what the customer paid for and everything else the company has built. A grant drawn too narrowly frustrates the customer and invites disputes about whether ordinary use is even permitted. A grant drawn too broadly gives away rights, and often revenue, the company never meant to part with.
This article looks at the license grant from the perspective of the company granting it, the licensor, though the customer, the licensee, is negotiating against it the whole way, and the reasonable terms usually land somewhere between what each side would prefer. The licensor’s objective is to grant exactly the rights it intends to grant, no more, and to define the scope precisely enough that the customer’s permitted use and the price the customer pays stay aligned. Several dimensions of the grant determine that scope, and each is a place where a loose definition can expand what the customer receives beyond what the licensor intended.
The dimensions that matter most are what the grant actually conveys, how usage is measured, who is allowed to use the software, where and for what purpose it can be used, and what happens to the license if the customer is acquired.
What the Grant Conveys
The first thing the grant has to make clear is that it is a license, not a transfer of ownership. The customer receives the right to use the software on defined terms. The company keeps ownership of the software and all the intellectual property in it. This distinction is fundamental, and a well-drafted grant states it plainly: the licensor retains all rights not expressly granted, and the customer receives only the specific rights the license describes.
The nature of the license is then defined by a series of adjectives. A non-exclusive license lets the licensor grant the same rights to other customers, which is the norm for most software. A non-transferable license prevents the customer from passing the license to someone else. A term-limited license lasts only for the defined subscription or license period and ends when that period expires or the agreement is terminated. Each of these words limits the grant, and leaving one out can broaden the license beyond what the licensor intended. If transferability matters, for example, the agreement should address it expressly rather than leave the result to applicable law.
The grant should also state whether the licensee may sublicense any of its rights. For most end-user licenses the answer is no, but leaving the point unclear can create questions where affiliates, contractors, resellers, or other third parties are involved. A grant that says nothing about sublicensing invites argument about whether the customer can permit others to use the software under its license.
The permitted use itself has to be described with care. There is a difference between a license to use the software for the customer’s internal business purposes and a broader license that would let the customer use the software to provide services to third parties. A company that intends the former but drafts the latter has licensed a materially different product.
How Usage Is Measured
Most software licenses tie the scope of use, and the price, to a measurable metric. The choice of metric defines both what the customer is allowed to do and what the licensor is paid for, so the two have to be aligned. If the metric is loose, the customer can expand its use without paying more, and the licensor loses the revenue that growth in use was supposed to generate.
The most common metric is the user, but even that requires definition. A named-user model licenses a specific number of identified individuals, each of whom may use the software. A concurrent-user model licenses a number of simultaneous users, allowing a larger pool of people to share a smaller number of active seats. The two produce very different economics for the same headline number. Ten named users means ten specific people. Ten concurrent users might mean fifty people sharing ten seats. A licensor that means one and writes the other has mispriced the deal.
Other metrics fit other products. Software may be licensed by the volume of transactions processed, the quantity of data stored or handled, the number of locations or devices, the computing capacity used, or a tier of functionality. Whatever the metric, the license has to define it precisely and address what happens when the customer exceeds it. A well-drafted license specifies both the metric and the consequence of going over it, whether that is an automatic true-up to a higher tier, an overage charge, or a requirement to purchase additional capacity. A license that sets a metric but says nothing about exceeding it leaves the licensor without a clear remedy when the customer grows past what it paid for.
A metric also has to leave the customer room to grow. One that matches how the customer actually uses the software, with tiers priced so that growth in use produces growth in revenue, keeps the two sides aligned. One that punishes ordinary growth too aggressively, or trips a penalty at the first sign of success, will sour the relationship. The licensor’s task is to capture the value the customer receives without making routine expansion feel like a trap.
Who Is Allowed to Use the Software
The license is granted to a specific customer, and defining who that customer is turns out to be one of the most consequential parts of the grant. The entity that signs the agreement is clear enough. The question is who else gets to use the software under the same license.
The affiliate question is where this most often expands beyond what the licensor intended. Customers frequently ask that the license extend to their affiliates, so that subsidiaries and related companies can use the software without separate agreements. That can be reasonable, but the definition of affiliate controls how far the license reaches. An affiliate defined as any entity under common control with the customer can sweep in a large corporate family, and if the customer is part of a big group, or is acquired into one, the licensed population can grow dramatically without any corresponding increase in fees. A licensor that grants affiliate use should define affiliate deliberately, and should consider tying affiliate use to the same usage metrics and fees that apply to the named customer, so that expanded use produces expanded revenue.
Contractors and outsourcers raise a related question. A customer may want its third-party service providers, such as an outsourced IT function or a consulting firm, to use the software on the customer’s behalf. This can be legitimate, but it also extends access to entities the licensor never evaluated, and it can shade into the customer using the license to benefit third parties in a way the grant was not meant to permit. The license should state whether contractor use is allowed, and if it is, condition it so that the contractor uses the software solely for the customer’s benefit and is bound by the license terms.
The through-line is that the licensor is licensing to a defined population, and every expansion of that population, to affiliates, to contractors, to a broader corporate group, is an expansion of the grant that should be priced and bounded rather than conceded through an undefined term. If the licensed population expands, the licensor should make that expansion deliberately.
Where and For What Purpose
Two further limits appear in some licenses, depending on the product and the business model: a territorial limit and a field-of-use limit.
A territorial limit restricts where the software may be used, which matters more for some products than others. For most cloud-based software accessed from anywhere, a tight territorial restriction can be impractical and is often omitted. But a licensor with a regional business model, or with different pricing or distribution arrangements in different markets, may want to define the territory in which the license applies. Where territory matters to the business, it should be stated, because if the grant contains no territorial restriction, the agreement may provide no contractual basis for limiting use by geography later.
A field-of-use limit restricts the purpose for which the software may be used. A licensor might grant a license to use the software in one industry or for one type of application, while reserving other fields for different customers, different products, or different pricing. Field-of-use limits are common where the same underlying software has value across multiple markets and the licensor wants to license each market separately. Where the business depends on that separation, the field of use has to be defined in the grant, because if the grant does not restrict the field of use, the licensor may have no contractual basis for imposing that limitation later.
Neither limit belongs in every license. The point is that where the licensor’s business model depends on limiting geography or purpose, the license has to say so. A licensor that relies on a territorial or field-of-use distinction in its business but omits it from the license may have no contractual basis for enforcing that distinction against the customer.
What Happens If the Customer Is Acquired
The assignment and change-of-control provisions determine what happens to the license if the customer changes hands, and this is one of the places a loosely drafted grant can produce a result the licensor never intended.
A license is typically non-assignable without the licensor’s consent, which prevents the customer from transferring the license to a third party. But an acquisition can transfer a license without a formal assignment, depending on how the deal is structured and what the agreement says. If the customer is acquired and the license passes to the buyer, the licensor can find its software in the hands of a company it never agreed to license, which may be larger than the original customer, may use the software far more heavily, or may be a competitor of the licensor. A license that addresses assignment but not change of control leaves that possibility open.
A licensor that cares about who holds the license, and most do, should address change of control directly. The provision can require the licensor’s consent for the license to survive a change of control of the customer, or provide that the license terminates on a change of control unless the licensor agrees to continue it, or permit continuation but on terms that account for the new owner’s size and use. The customer will resist a provision that lets the licensor block or tax an acquisition, because the customer wants its contracts to transfer cleanly in a sale, and this is a real negotiation. But a licensor that grants unconditional survival through a change of control has agreed to license whoever ends up owning the customer, on the original terms, which is a meaningful concession that should be made knowingly rather than by omission.
The Takeaway
The license grant is where the licensor decides exactly what it is selling. What the grant conveys, how usage is measured, who is allowed to use the software, where and for what purpose, and what happens on a change of control are all dimensions the licensor controls, and each is a place where an undefined or loosely defined term can hand the customer more than the company intended to give. The customer is negotiating for breadth on all of them, which is legitimate, and the reasonable terms usually land between the two positions. The licensor’s job is to make sure every expansion of the grant is one it chose, priced, and bounded, rather than one that slipped in through vague drafting.
The common failure is treating the grant as standard language rather than the definition of the product being sold. A license assembled from a template, without attention to the metric, the licensed population, the territorial and field-of-use limits the business model depends on, and the change-of-control treatment, can grant materially more than the licensor realized. The grant is the product. Scoping it precisely is how the licensor sells what it means to sell and keeps what it means to keep.
This post is general information only and does not constitute legal advice. For questions about a particular license or agreement, contact Cruxterra Law Group.
