Software Licence Language 101
28 April 2020
If you’re in the IT operations or procurement department of any large corporation, you likely spend a large part of your day-job dealing with software suppliers and managing the acquisition and maintenance of various licences - with a wide variety of applications and restrictions.
When engaging with software suppliers, the language in the contract that grants the licence is often key, but strangely also frequently overlooked. Too often the actual terms of the contract are overshadowed by the commercials of the transaction, without focus on the key commercial terms in the licence grant itself, like who gets to use the software and for how long.
Software licensing is a complex area. In this article we will really only be touching the surface of this topic, but we trust you will nevertheless find these pointers useful as a start.
Basic Language for a Grant of Rights
Exclusive / Sole / Non-exclusive
Exclusive licences allow you, and you alone (not even the licensor), to have the use of the software in question.
Sole licences are generally understood to mean that the licensor grants the licensee the exclusive right to use the software but still retains the right to use the software itself. Don’t use “Sole and Exclusive” in your drafting as the two are technically not mutually compatible. When in doubt, you could simply define the term to make sure it means what you want it to. For “Sole” licences, you could perhaps just say something along the lines of “grants the licensee an exclusive licence to use the software, but subject to the licensor’s continued right to use”.
Non-exclusive means the supplier can grant the right to use the software to anyone else.
Worldwide / Territory
This either allows the global deployment of the licence or limits its application to specific territories or even buildings/sites or individuals.
Perpetual / Term
Perpetual licences are indefinite (in some licences unless otherwise terminated in accordance with the terms of the licence) whereas term licences are subject to time periods, such as monthly or annual subscriptions.
Revocable / Irrevocable
Where a licence is revocable, it means that the licensor can withdraw your use of the licence. Where a licence is irrevocable, a licensor cannot withdraw your ability to use the licensed software. In essence, it is a perpetual licence with the added protection that it cannot be terminated. Do not confuse perpetual licences with irrevocable licences.
Transferable / Non-transferable
The right to use transferable licences can be shared if the correct procedure is followed. Non-transferable means that the licence’s authorised users are fixed.
It’s critical to appreciate that if you get the grant language wrong, you’ll likely end up buying something different to what you intended, or something not fit for purpose. Beyond that, you may place your organisation at risk and drive cost not budgeted for. If, for example, you go out to tender and only realise after down-selection that the original licensing language or use-case is inaccurate, you jeopardise the integrity of the process and may well have to revisit the commercials. This is because the supplier will have only priced for a specific licence use-case and deployment. Alternatively, you could deploy software that is not under licence and expose your organisation to a software licence audit resulting in a potentially damaging fine from the supplier as you’ve incorrectly scoped and unlawfully deployed the software.
Licence grant language often doesn’t actually call out all the details required to fully understand the right to use. If, for example, a licence isn’t expressly limited to a specific period of time, it’s generally assumed that the grant will be perpetual (but be wary of terminology in the contract which might lend weight to a different interpretation). The below sets out some default implied terms that will apply if not specifically addressed in the contract:
Where the grant language is silent on: territory
The default is usually that the licence is: worldwideWhere the grant language is silent on: exclusivity
The default is usually that the licence is: non-exclusiveWhere the grant language is silent on: restrictions
The default is usually that the licence is: not restricted
Implied terms should, however, not be relied on too heavily, if at all. It might seem pedantic and frustrating to deal with these perceived mundane details when contracting, but this is arguably the most important content in any licensing agreement. If the agreement is silent on any of these terms, ensure that you insert appropriate language in your favour - unless you are absolutely certain (after proper legal assessment) that the terms cannot be construed in any other way.
There are instances where certain elements of the licence grant will have increased importance. If, for example, the licence is going to be granted to a business area with a lot of user movement, then the customer’s ability to re-allocate or transfer licences to different users will potentially make or break the commercial model.
If you’re on a term licence, ensure that this includes all new releases and updates as part of that subscription. If not, there is a very real risk that, as a customer, you could be stuck with having the indefinite use of a specific version of the software (i.e. version X) but without the rights to new releases, functionality updates or ongoing maintenance of that specific version. If you’re restricted to a specific version in this way, and a new version is released, you might be tempted to try avoiding any integration hassles and just continue on your older version. As support services are usually qualified with language such as “Supplier will provide the support services only for the then current or X previous versions”, you may end up paying for support, unaware that contractually the supplier is no longer obliged to provide “Gold/Platinum/Premium” support (or support of any kind). The unfortunate result is that you’ll then have to make a ‘lesser of two evils’ decision - either re-purchase a new perpetual licence and start the cycle all over again or pay for extra support in addition to your redundant support package (if that’s even possible and the supplier still provides support for the older version).
Software Use
Suppliers will often have models in place that are specific to the use of their own software. These models can encapsulate any combination of a user’s identity and their locations, the type of machine, the purpose for which it’s used and the environment it’s deployed in or other restrictive volume metrics.
It’s critical for the business to understand these parameters lest they expose the entity to aggressive ‘true-ups’ (i.e. where you have to pay for overuse in arrears) or licence audits.
If you’re a group entity you must also consider whether affiliates (and potentially even subcontractors who might be assisting with services using the software) require the use of the software. Preferably, your original grant language should be wide enough for this but where it is not or, for example, you have a named-user licence, ensure that your licence conditions clearly allow you to assign licences as required within the group.
There is considerable risk if the contract you’re signing doesn’t adequately provide for what you actually need and how you intend to use the software. Software suppliers generally make sure they have at least a suspension right where misuse is present. If, for example, your business’ payment processing or booking system is affected through a duly exercised suspension right (by the supplier) you place your organisation in harm’s way. Sometimes this can even hinge on mere “suspicion” of misuse. For this reason, it’s important to ensure that a supplier’s suspension rights are limited to specific, material misuse based on objective criteria such as non-payment and evidence that misuse is in fact present. If non-payment or misuse can be proven, you should also have a reasonable cure period (following notice from the supplier of its intention to suspend) to address or remedy the misuse before suspension is allowed. It is also sometimes useful to have an escalation and dispute resolution provision, involving appropriately senior people, which would delay the suspension of use and potentially lead to resolution. This would allow you to first trigger the dispute, and if not resolved, you can then trigger your cure period.
Intellectual Property
Suppliers will normally retain intellectual property rights in “out-the-box” or proprietary software. However, it’s important to also consider the extent to which you will be paying for bespoke developments of the software (and essentially funding your supplier’s R&D) which will ultimately then be available to your competitors at lower cost, unless you ensure you own the bespoke piece. For this reason, it might be useful to introduce an exclusive-use period following deployment of bespoke software, securing you ‘first-mover advantage’ and some time to exploit the software before the competition. Alternatively, consider re-licensing these improvements back to the supplier, so creating some commercial leverage in your favour. Customers should also consider whether they require ownership of the outputs of the software.
Bundle Bungle
Software suppliers also sometimes grant enormous discounts for bundled software purchases. While this can hold commercial appeal, there is a potential pitfall to bear in mind. Some software within the bundle might become redundant within the organisation, but the termination and/or maintenance of any portion of this discounted software bundle is commonly linked to the remainder of the bundle. This means that if you terminate any portion of the bundle, it will require re-negotiation on the pieces you want to keep (and you’ll potentially lose your bundle discount). Suppliers could include smaller purchases which, coupled with larger purchases, would mean that a customer would be required to continue paying for licensing, support and maintenance of a redundant product. Where possible, take a longer-term view of whether bundled software purchases are appropriate for your business.
“Check” it out…
Although there are various ways in which software can be licensed, there are some key questions to keep in mind which are applicable to most deals, and which we suggest are useful to consider. The following link contains a checklist that we recommend be considered in every software licence deal:
by Stefan Swart
The information and views contained in this article does not constitute legal advice. If you do require legal advice, please contact us on hello@lighthouse.law.
