Latest ITAM News

EXTENDED AND UNPREDICTABLE LICENSE REQUIREMENTS

Nearly all organisations depend on software for their business, regardless of what their business is. The software that is used provide great benefits; efficiency, involving and interacting with customers and business partners, shipping and invoicing, production to name but a few. But sometimes there are, as the title suggests, problems, and that is when the license requirements are extended or become unpredictable.

It has never been easy, cheap or particularly predictable to be a software customer. But during my years in the business it has gradually become worse. The financial risk has become huge. One of (too) many examples is a Nordic, small organization, where a huge software vendor’s audit report showed incompliance at roughly $170 million. To be clear, this was not what they asked for, it was the number of alleged unlicensed processors times the gross price for the product in question. However, I believe that the number above serves as a poignant example to show that part the software industry have a major problem when it comes to the relation between customers and software companies.

In contrast to how the software companies act, during my years of doing audits I never saw any reluctance from organizations to pay for the software that they consumed and the benefits it provided. But it is difficult to know what to license that will serve the business purpose best. It has become highly unpredictable. And thereby risky.

Lack of clarity
In some cases the extension is blamed on third party technology, like for example Oracle and their view on non-Oracle virtualization technologies. In other cases unpredictable license requirements is a result of very unclear contracts, such as SAP’s indirect usage.

Extended license requirements
In June 2001, oracle introduced the Processor metric that’s still in use, relatively unchanged. It was at the time a good metric. One Processor contained one core and required one license. Easy and predictable. If a company increased the number of Processors they had to get additional licenses. There was a fair relation between increased use and increased cost.
In 2004 licensing became a bit more complicated when dual core processors had become common and Oracle responded with the core-factor system. But still, easy to understand and one could find out the license requirement. There was a predictable correlation between increased use and increased cost.

In 2009 we see the first example of an extended license requirement when VMware releases version 4 and Oracle responds with requiring a license for each processor on each server in a cluster – even though it was impossible for a virtual server to use resources from more than one physical host at a time. Oracle argued its position by saying ”it’s impossible to know which server is used at any given time”.

VMware releases version 5 in 2013 and all of a sudden, the license requirement is extended to include all cores, in all processors, of all servers of all clusters in a vCenter. Then follows version 6 and I believe all readers know that story. In my opinion these are clear examples of unexpected extension of the license requirement without any additional business value for the customer.

Unclear contracts
A legal principle that is accepted pretty much all over the world is that ambiguities in a contract should be to the disadvantage of the party who wrote the contract. In our business, it seems to be the other way around – software companies write very vague contracts and then benefit from any ambiguities. The argument is usually that they own the IP-rights and that everything that is not explicitly allowed isn’t allowed. SAP and their view on indirect usage can serve as an example of this.

The term Indirect Usage is at best vaguely described in the contract. Exactly what is, or isn’t indirect usage is virtually impossible for anyone to figure out – even if you’re an SAP-expert.

Who and what should be licensed? What differentiates one integration from another? What about mobile apps? What about sensors that collect or receive data? Batching? Should those that see data in the receiving system be licensed? Export of flat files and so on….

If you can’t find the answers in the contract you have to make your own analysis. But what is to say that that analysis is shared by SAP? Of course you can ask someone at SAP but that is problematic too. You will probably get different answers depending on who at SAP you ask and if SAP suspects that there might be indirect usage you might end up in a negotiation for what you are already using, and that is definitely not a good negotiation position.

To add insult to injury, sales representatives sometimes disregard their own company’s licensing rules to be able to sell the software. For in all honesty, how many deals would there be if they said on record – “that’ll be $170 million to run on 10 CPU’s – because we don’t like your choice of virtualization technology”.

It’s important to mention that what I have described doesn’t apply to all software companies, perhaps not even a fraction of them. Most are well intended and you have great relations with those. But with some companies It’s more difficult to have a good relationship which I’m sure most of you can relate to.

What’s the reason some software companies act this way?
One explanation is that software in some segments is really hard to sell because the market is heavily saturated. Examples of this is ERP systems, CRM-on premise, database and middleware. Existing customers already have the licenses they need and at the same time it’s very difficult to find new customers.

In addition, there’s really fierce competition from new, cloud-based players on the market. Areas where the dinosaurs have made huge investments in development, data centres and acquisitions to stay competitive.

When sales numbers are down it’s easy to turn to the oldest trick in the book – audits – now combined with extended license requirements. This way they can keep up sales of products that are difficult to sell, regardless that the result is alienating current and new customers alike.

In addition to the obvious benefits of selling products that don’t have much of a demand, audits serve other, very creative purposes that doesn’t particularly benefit the customers.

Firstly, audits are used as a door opener. If you have not picked up the phone when they call or made any new purchases lately, at least not the “right” products, it’s easy to get attention by invoking the audit clause. You no longer have a choice but to answer the phone.

Secondly, audits are used to sell products that are strategic to the software company. They start with showing enormous numbers for an alleged incompliance situation. After that, the customer is presented with a set of different solutions to the problem that are priced from offensively high to much lower – this is what they really want to sell. This way the software company push their customers in the direction that they want, be it cloud, or hardware or a particular database.

For organizations this is problematic in many ways, for example:
* Spending a lot of money without any additional business value and increased support cost.
* Weak negotiation position since it’s an audit.
* Difficulty to budget, because how can you budget for the unknown?
* Decreased control over strategic decisions – If it will cost you 10 million to go to cloud or $170millions to license on premise to resolve the claimed incompliance – what choice do you really have?

Is there a solution?
I would say no, in the sense that it is very unlikely that software companies will quit what they are doing – it’s too much money at stake, to easy and there is really nowhere to run for their customers.

What can be done however, is to focus on things that can be affected to limit financial exposure and keep the initiative in strategic decisions.

* Analyse the software contracts that you already have signed and look for risks and ambiguities to be able to deal with risk pro-actively. If you can, look at alternative solutions and calculate the cost, it may be cheaper in the long run.

* Review all new contracts very carefully in the negotiation phase with focus on future risk and try to rid the contract of ambiguities and other risks during the negotiations.

* Document the procurement process and what was said. If you shared how you intend to use the software and got an OK on that, document it. Any advice you were given, document it and make sure to have this confirmed in an email.

* Only buy software where you can measure the usage, if you cannot, make sure the contract reflects this from the outset and/or any concessions negotiated.

* When making new investments with a software company, use that to eliminate the risks in existing contract. When there is money on the table, almost everything is possible. Especially in Q4 and if you buy products that are strategic to the what the software company, such as cloud. Use that to your advantage!!

Make the unpredictable less so
To protect oneself against the unpredictable is by definition very difficult, but not impossible.

A very good start is to understand what drives and motivates the counterpart. Understand their driver beyond a good sale, what products, which incentives and why.

I hope that you are helped by what you have read about why some software companies act the way they do. How they use vague contracts to extended license requirements and then present enormous incompliance numbers in audits to use as leverage when they want to influence your decisions.

To end this article on a positive note – the Nordic $170 million audit ended up with a purchase of a strategic products at 0,12% of that value as a result of a negotiation strategy based on an understanding of what motivated the vendor and the sales representative.

Good luck!

About Rasmus Larsson

Rasmus Larsson is the Sr. Enterprise SAM Advisor for Snow Software