Licensed or not? (Part 1)

There’s no doubt about it, software licensing is a complex beast. But before I cover this complex area, it is important to remember that software companies generate licenses for the use of their intellectual property (IP).

As private individuals, we buy IP all the time. Every time I buy a car or a light bulb I am buying IP, and the difference compared to software is that it’s pretty difficult to replicate that IP…..not impossible as we see with things like fake women’s designer handbags for example, but everyone accepts this is illegal and breach of copyright, patent and often trademark.

Software licensing models vary tremendously depending on who sells it and what it is used for:

• Some software is licensed for usage forever after purchase (in perpetuity), some is time limited (often with annual fees).
• Is it licensed by named user or is it by total number of active users?
• Some software has inbuilt controls such as license keys linked to machine serial numbers, or blocks access when you reach a peak condition level.
• Some software may be licensed by throughput of all manner of things (vendors’ ingenuity to link charging to events seemingly has no constraint). There may also be different rules for test, development and backup copies of software.
• Licensing conditions can also vary over time, dependent on your conditions of usage and contract (more on that later). As software-as-a-service adoption increases, you should also be cognisant of the fact that, unlike with on-premise software, it is the vendor that controls whether it is used or not, which is an important nuance.

What is clear is that you need to understand in-depth the details of your vendor’s licensing terms and conditions. You won’t be surprised to hear that the vendor license audit team understands it!

Contract conversations

It always amazes me how many software products are sold without the ability to measure what customers sign up to in their purchase contracts. It seems to me to be an omission that customers should be very keen to question.You should not be satisfied with just words, you should demand documented procedures and processes, including full technical definitions. If the onus is on the user of the software to prove to the vendor that they are meeting the terms and conditions, it surely makes sense to ensure you have all the necessary information readily available.

Contracts and how they are written are key to a quiet life going forward. Putting the effort in using people who already know the software up front is an extremely critical activity. It is not advisable rushing to meet an artificially created purchase deadline (you know, when the salesperson says if you get this deal signed by the 30^th June, I can give you this discount, after which you won’t get the discount!). Meeting the sales targets and commission revenue of the vendor is not your concern, and if they really value your continuing custom, you will get the discount at any time.

Time is also a concern in software procurement. How long will you keep your software in use? Because over that time newer versions of software can be released, that will likely do things differently. A further challenge is when features get split, removed and/or unsupported and remarketed as a different and new product. So, what can you do in this situation? When producing your contract, firstly always define what is important to you – don’t accept standard contracts if they don’t meet your needs and be prepared to walk away to someone else that will accept amendments.Also consider defining what you are purchasing by your business processes, not the software, and specify what you are buying so that any renaming/updating/splitting does not impact you.Some vendors also reference your terms and conditions to an evergreen website, so you need to decide whether that is acceptable to you. Many find this unacceptable, and instead link their contract to an indexed dated copy of the terms and conditions.

Indirect Access?

I couldn’t write this piece without reference to the hot topic of Indirect Licensing. Some of these issues originate from long ago when big ERP users originally purchased their software licenses. The concept of using multiple vendor solutions was not the direction of travel at the time and the connected world hadn’t really commenced. Remember I talked about IP earlier? This is what the debate is all about, if you access that IP you have to pay for it, all dependent on what you signed up for.

In part 2 of this blog post next month, I’ll cover off some specifics on licensing in the world of SAP.