The software licensing minefield

Software vendors make their money from licensing software for individual and corporate use. From the buying perspective, you’d think it could be a simple question of asking how much you need, and working out a price for that. But nothing in IT is ever so straightforward. In France they have an expression – “why do something simply when you can do it complicated?” – and much the same principle appears to have been applied to software licensing.

To be fair, it’s not always going to be obvious what needs to be measured. Back in the olden times of computing, when everybody in the industry knew each other by their first name and when there were fewer computers in the world than Russian tanks (and they were arguably built to a similar spec), costs were measured and billed based on amount of processor time actually used. As technology diversified, a number of new models emerged which gave us the plethora of choice we know today. License fees can be charged by:

•Server, based on hardware performance – for example, based on CPU types, and/or the number of CPUs (or cores) in the box. This model is used mostly for platform software and external web apps.

•Module or product. This model is mainly for packaged applications such as enterprise management software, and business-facing applications such as enterprise resource planning (ERP), for example there can be different fees for general ledger and accounts payable modules.

•Named user, sometimes with multiple fees based on role. This model is also used with packaged apps such as ERP.

•Concurrent user, which may be honesty-based or enforced through use of token management software (such as Flexnet). This model used to be popular for some software development tools and desktop applications. Transaction processed. This model is more for financial, business-to-business trading and payroll applications.

Desktop/laptop/mobile device. Used for personal applications, games, security software and machine-specific utilities.

Such licensing models can be used in combination, of course, and as if that wasn’t complicated enough the length of the licensing period can be varied. Most consumer and desktop software is on a perpetual basis, but business packages are more often licensed on a fixed-term basis which also covers costs of maintenance and support for the term. In the case of perpetual licenses, of course, vendors do eventually withdraw support even if the software continues to be usable.

Why all the complexity? Ultimately, this has to boil down to vendors wanting to maximize the return on their software development investment, and end-user businesses wanting a fair deal, with sufficient value coming from the application or package to justify the spend. So, the model in each case needs to best reflect what an organization is prepared to pay for – users, transactions, modules or whatever.

Forget altruism: as anybody who has been involved in licensing negotiations between a larger business and a software vendor will report, these are business deals, pure and simple, at the end of which both sides need to feel they have got the best out of it.

The problem is that the software vendors have a vested interest in making the options as transparent as mud, so that clear pricing comparisons are very difficult to make. Rather like mobile phone tariffs, in fact, and we all know how easy those are to decipher. And they count on the fact that few companies can afford expensive legal teams to decipher the licenses to determine how to achieve the best value. So rather than a win-win situation, it is often more a case of “I won, the other side just thinks they did.”

For the vendor sales guy, there is a personal interest as well, as illustrated when I was buying some software from a database company. As we left the offices of our procurement people, I watched as he punched the air and said, “I’m going to Barbados!”

I do hope the weather was nice for him.

Meanwhile of course, things continue to get more complicated. Virtualisation really is the cat amongst the licensing pigeons, as vendors struggle to get their heads round the business models that result. Per-server or per-CPU models fall apart for example when multiple VMs can be run on a single processor, and elsewhere multiple instances of a single package may be lying dormant in a suspended VM. Some vendors appear to have been dragging their heels when it comes to virtualisation, and for many organizations it will be a case of returning to the negotiating table looking for a fairer deal.

Second, there is open source. From a procurement standpoint, whatever the complexities lie behind the different flavours of GNU Public Licenses, open source vendors make their money from support, maintenance and service contracts based on criteria such as those above. Virtualisation is also causing challenges in the open source procurement world, particularly given the attitude that if the base software is in some way ‘free’, surely it can be installed as many times as the organization likes?

And finally – for now in any case, there’s the question of software-as-a-service models. While pay-per-use may appear to be a core principle of such models, we know that many vendors that deliver their software ‘over the wire’ are actually following a similar procurement model to that of annual licensing contracts. There’s a good reason for this, namely that (at the moment at least) that’s how software tends to be bought in mid-sized and larger companies. However innovative the IT industry may like to be, it’s going to take a while to change the behaviour of companies that have internal buying processes requiring paperwork to be signed in sextuplet.

In the conversations we have with IT management types here and elsewhere, there is plenty of interest in changing this model. This is not so much about starting to buy software using their credit cards, but more that any payment model can take into account what is actually used, as opposed to what might be necessary as predicted a year or more in advance. Perhaps eventually we shall return to where we were several decades ago, with monthly billing cycles and itemized invoices. But for anyone in a software buying position, I wouldn’t be holding my breath.

Content Contributors: Jon Collins