A flexible software license model that is gaining some traction in the market is a token software license model. This model is very effective for software vendors who have a wide portfolio of software where the usage patterns of individual software are difficult to predict. This situation often occurs in technical markets, where the portfolio of software is used in a design flow, or to conduct a software experiment. Users may not be able to predict how much software to purchase at the beginning of the purchase cycle as the usage of software may be dependent upon the challenges faces in a particular design. For example, in electronic design, a particular design may require more simulation software than previous designs have required.
From the perspective of the software vendor, it's also an effective way to fortress a market position against point-tool competitors. The token software license model makes it financially easy for the customer to utilize the entire portfolio of software, and not try to buy the best-of-breed for every part of a design flow.
Expiring Concurrent Tokens
The simplest form of token software license model is implemented (and easiest described) as a variant of a floating license model. With the typical floating license model, each time a particular software product or title is run it checks-out a license key from a license server for the duration of operation. For example "Software A" will request a particular license key associated with "Software A" from a license server whenever it runs. If the license server has licenses available, the software is granted a license to run. The software will return the license to the server when the software is exited. Similarly, "Software B" will request a particular license key associated with "Software B" from the license server whenever it runs.
When deployed as a token license, the software vendor creates a generic license key "token" instead of a license key associated with each product – the idea being that products don't check out product specific licenses, but rather, checkout one or more generic tokens – the amount of which is weighed toward the list price of the product. With this software licensing model, the customer downloads the software for a portfolio of software, and then purchases a number of tokens that enable the software.
For example, let's say I download the software for Product A and Product B, and buy 4 tokens. The way the tokens have been designed, "Product A" checks out 3 tokens when it runs (and return the tokens when they are done), whereas "Product B" may checkout 2 tokens when it runs (and then return them when they are done).
With 4 tokens, I can concurrently run 1 copy of Product A (with 1 token un-used), or 2 copies of Product B. However, if I purchase, say, 6 tokens, I could concurrently run 2 copies of Product A, 3 copies of Product B, or, 1 copy of Product A, and 1 copy of Product B (with 1 token unused).
Tokens are typically implemented as a subscription license, which expires at the end of a term such as a year. This provides the software vendor with some revenue upside as a result of offering this increased flexibility.
A pure-play consumptive token, like a gumball machine, is a "use it up" model. In this model, when Product A runs it checks out 3 tokens which are then consumed and then no longer available. This type of software license model applies best when licensing software that is transaction-oriented, and the software vendor wants to charge based upon the total number of transactions. We have seen this license model in the medical equipment market, where a specific number of "treatments" is allowed for a fixed price.
Next Week – More of the Nuances of the Token Software License Model