Who Wants a Perpetual "Liability" Business Model?

by: Cris Wendt

The perpetual license model is the most frequently used one for selling software.  However we’ve uncovered several problems that can occur with this model, in working with customers on entitlement & compliance systems design and product packaging behavior.

Let’s Summarize the Perpetual License Model:

Most of the B2B software licenses are sold in a model where the right to use the software is sold with the perpetual license.  Once the software license has been purchased with a license fee, the user has the right to use it, in essence, forever.

As part of the business model, the customer can optionally purchase a maintenance contract, which provides product support, and entitles the customer to refresh the functionality of the software with new updates and upgrades.   The access to new updates and upgrades keeps the software current – that is, the software is continually enhanced to fix defects, provide additional functionality required for the software to be productive, or even enable the movement of software to next generation hardware platforms as older platforms reach end-of-life.   Maintenance is often priced at a value of 18% - 22% of the list price of the software.

The Pressure to Protect Revenue:

Over time, this arrangement becomes a blessing and a curse.  When products mature in the market, the revenue stream associated with product maintenance increases to a point where it overtakes the new product revenue.  So it’s important to keep the customers on a maintenance plan.  However, with time, there is an evolution of the license lifecycle of the product that becomes very difficult for processes and systems to manage.  

Enter the License Lifecycle of a Perpetual License:

Below is a fictional, but all-too-real, description of what happens behind the scenes in a software company.

Product A, version 1.0 evolves to version 1.1, then 1.2, etc.  At some point in the lifecycle of Product A, marketing decides to split this into multiple products (products B and C).  To deal with this re-packaging, product management deems that some customers with the perpetual license who are covered by a maintenance contract receive Product B, some receive product C, and some customers receive both.  Also, maintenance fees have to be manually adjusted to accommodate the fact that the product packaging was changing. 

A year later, a company merger occurs, and more product packaging with manual processes is done to protect the maintenance revenue.  In some cases, sales discretion is allowed to determine the exact mix of products that customers receive.   All of these changes are accomplished with manual processes because the ERP system (which forms the basis for managing entitlement and maintenance records) was designed around the physical product paradigm of building and shipping a physical product.  Over time, these manual processes become an enormous operational expense to the software company.

At this point, there are weak links between what the customer originally purchased, the information to describe what the customer is currently entitled to run, and what they are actually running.  This is when customers complain about inaccurate license keys; when order management processes remake orders; or when the corporate audit groups try to work with customers to “true up” with no record of truth.

If you don’t believe me, ask your local maintenance renewal representative or order management representative. 

Are Time-Based Models Going to Dominate Software License Sales?

Granted the perpetual license had only a part in this entire chain of events, but companies with time-based license models tend to have less of these types of problems.  The actual right-to-use expires on a regular basis, enabling a re-start to the license and compliance process.

I’ve likened time-based models to a haircut: if you don’t like what you did last time, just wait a little bit and cut it again.

I’d be interested to know if the fictional scenario above is true for your company? Are your software licensing and entitlement processes handcuffed with manual inefficiencies?

Comments

[Yifang Kuo]

Hi Cris,

I absolutely agree with you on the liability issues coming together with the perpetual licenses. Personally I will also prefer a term license model. However, one of the major issues hindering my company using term licensing is the revenue recognition issue. Our finance team told us that if we deploy a term license, the revenue has to be amortized monthly over the license terms. Hence, if I started a 10-year license, the revenue at the 1st month will drop by 119/120, and the 1st year by 90%. Do the other companies see the same issue?

[Acresso Software]

Hi Yifang, I definitely understand your concern. If you separate the maintenance fees from the license term (charge separately), you may be able to recognize the revenue for the software license at the time of delivery, but recognize the maintenance fees over the term of maintenance, which is typically 1 year. Be sure to check with your finance and legal teams to see if this is possible. Each company may adopt slightly different revenue recognition policies.

The following presentation may help a little bit, as it’s from a person roughly in your industry (EDA). See Page 10. It is a bit dated, but speaks to the capability of recognizing revenue up-front for a term license (if maintenance is split out).

http://www.softsummit.com/library/presentations/2004/Motorola_JJones.ppt

Let me know if you have any more questions.

Regards,

Cris Wendt