License purchases and entitlement
Many organisations, large and small, struggle with being able to establish their software license entitlement. In a previous blog post, I wrote about how important it is to be able to prove your license purchases, but how do you go from there to having a license entitlement? A few important points can help businesses to achieve this essential step in understanding if they are compliant in their use of software.
The first point to recognise is that a license purchase and the license entitlement it confers are two very different things. One is what you have bought, the other is what you are allowed to use as the result of that purchase. A license purchase may be a single line item on an order, or one individual license for a piece of software. The license entitlement that purchase infers could range from a single named user in a specific business and location to every single person in an entire office or even country.
The second point is that in order to determine the license entitlement that a license purchase confers, there are some key elements of data which will be required.
Translating a purchase into an entitlement
What follows is a very basic list of data elements that are required in order for a license purchase to become license entitlement. It is not definitive, and certainly isn’t exhaustive, but it is a good start.
Purchasing Organisation name
Who bought the software? It will have a big impact on who can use it.
The name of the publisher of the software, Microsoft, Adobe, IBM etc.
Application Name: The name of the application as t has been sold.
The edition of the application purchased. (I cannot stress enough just how important this is. If an organisation purchases the standard edition of an application and deploys the enterprise version, someone is going to have a bad day.)
If the purchase is made as part of an agreement, then the agreement details should be recorded. If nothing else, it can help if it becomes necessary to review purchases from a publisher at a later date.
The license metric. Did you license users, or devices? Processors or cores? Are the user licenses concurrent or for specific named users? It is almost impossible to understand the entitlement inferred by a purchase without this data.
Have you purchased a license with maintenance, or just the license? Is the license an upgrade for a license you purchased previously or is it a subscription?
How many licenses have you purchased? It may only be one line in a purchase document but it could represent a number of licenses. It may be that you purchased one pack of 10 licenses.
If you purchased licenses with maintenance (Software Assurance in the Microsoft parlance) how many of those purchases have you purchased maintenance for? One of them? All of them?
Maintenance start date
If you did purchase maintenance, when does it start? Without a specified date most publishers will assume it begins on the day of purchase.
Maintenance end date
And just as important as when the maintenance starts, is when it stops. This often determines the version of the application you’re entitled to deploy if the maintenance expires and you decide not to renew it.
Locating evidence of software license entitlement
In most cases this data will not be captured on the purchase order (PO) an organisation has used to transact a purchase. In many cases a PO contains the word ‘software’ and a, sometimes eye-watering, figure. That shouldn’t necessarily come as a surprise. It’s unlikely any of the data elements I’ve outlined above will be of any use to the person in procurement trying to complete the transaction, but it will be required nevertheless if you have the desire to establish an accurate software license entitlement.
In some cases, these data elements might be found in a quote document, or an invoice. It may be that in order to establish a license entitlement you will require the purchase contract or agreement. Whatever the case, once you have located those documents they should be stored somewhere secure so that they can be referenced in the future.
The third point to recognise is that, once all of the information you need has been collected, that information needs to be analysed and the resulting license entitlement recorded somewhere. Anyone who has been through the process of tracing software maintenance purchases from consecutive purchase agreements back to an initial purchase will recognise that, after you have completed it once, you won’t want to repeat the exercise.
The value of establishing a license entitlement position for an application or publisher should not be overlooked. There will be a reasonable amount of effort involved and finding a way to store the results of those efforts is something that should be considered at the outset of any project – it will be key to building and maintaining that entitlement position in the future.