Revenera logo

In reviewing many software vendors licensing practices with an eye towards improving them, I’ve come across a general dissatisfaction with CPU-based software licensing and pricing models. Because of this, for several years I have done everything I can to steer potential software licensing designs away from any CPU-based licensing model.

The CPU relevant models that most commonly come up are:

  1. Number of CPUs/cores
  2. Size or capacity of a CPU
  3. Amount of CPU time consumed
  4. Specific CPU processor model or type

All of these models appear on the surface to be valid ways of aligning price with value received, especially to an engineer that understands what the acronym CPU stands for. But in reality, CPU-based software licensing makes for a very poor business model. Even if Moore’s Law doesn’t continue on it past path, changes in CPU capability, size, model, cores, etc., occur far too rapidly compared to the lifecycle of most software.


Optimize Your Quote-to-Cash Process

Learn how your back-office systems can work together to drive efficiency.

The power and value of a single CPU 5 years ago is not equivalent to today. CPU metrics are hard to understand for business people. CPU metrics are also hard to predict. I may decide to buy and install software on a 4 core machine, but how do I know that I’m going to need all 4 cores? Am I overbuying? This makes the sales of the software very difficult and can easily lead to customer dis-satisfaction if they end up over buying because of unpredictability. Virtualization makes some of the CPU models like number of CPUs irrelevant. I can run 5 virtual machines (VMs) on a single or even a 4-way machine and easily exceed my license terms.

So all of that is a good argument for why not to do CPU-based software licensing, but it doesn’t answer what type of software licensing model should be used. The best software licensing solutions are tied to a value metric. Feature capabilities or transactional capacities are good examples but the best choices will be a metric that has these properties:

  • It is easy for anyone to understand how the metric relates to use of the software, business or technical.
  • It is measurable. Can I programmatically determine if the metric is on/off or a quantity from the application?
    • E.g. database size is measurable, employee headcount probably isn’t unless the value is stored in the database
  • It is enforceable or the value can be aggregated over time and reported upon in support of post use payment models.

 Finally, the licensing implementation of the product using the value metric must reflect value! If I have a per-use licensing model and I consume a license at startup but then immediately shutdown, have I derived any value from running the application? You can take a good value metric and make it a bad one through poor business rules or enforcement policy. My suspicion is that you can never take a bad value metric and make it a good one through policy.

Download the 2020 Monetization Models and Pricing for more information about how software vendors and enterprise customers feel about software licensing and compliance practices, models and metrics.