The Nuances of Token Software Licensing

The Token Software License Model (as a variant to the floating software license model) is a great way to provide flexibility to your customers. By selling tokens that can be used to invoke multiple products, you provide a great deal of flexibility to users who can’t always accurately predict what to purchase.

Implementation & Planning Considerations

The implementation of tokens as a mechanism to control access to products requires some careful thought and planning. Typically, the Token Software License Model is implemented in conjunction with a license manager technology, such as Flexera’s FlexNet Publisher software licensing module and operates something like this: before a product operates, it requests to check-out or consume tokens (non-product specific license keys) from the license manager. Based upon the availability of tokens in the pool at the moment of the action (determined by how many tokens were originally sold to the pool less how many tokens were consumed at that moment), the request is either granted or denied. While the implementation of this token license model is easily accomplished in the software when a license manager is present, there are some important policies that need to be established before an implementation begins:

• How do I determine how many tokens each product requires when it operates? That is, how is a token calibrated to list price? What is the sufficient granularity of value for a token? Is it $500 of list price per token? $1,000 per token?

• How do I handle list price changes to software? For example, if a product is designed to consume 5 tokens when it runs, what happens when the price of the product changes, especially if the software is already installed in the field? Suppose the new list price warrants that 6 tokens are consumed for each invocation, how do I handle customers that have an installed base of software that checks-out 5 tokens, with software that requires 6 tokens?

• How do I measure the usage of actual products when tokens are consumed? License managers typically record all license key request activity in a usage log for subsequent software asset management and usage profile analysis. In a non-token software license model, a product will consume a license key that is specific to a particular product. That way when the usage log is inspected, the usage attributed to a particular product can be understood by looking at the time that specifically-named license keys are consumed. When generic tokens are check-out instead, all usage is attributed to a generic token and it is impossible to understand which particular product consumed the token.

All of these issues can be easily addressed in a design phase, but they must be carefully considered during the planning and implementation phases.

The Temptation of the Token

One of the more seductive aspects of a token is the capability to allow customers to access future products that were not available at the time the original sale was made. For example, at the time of the sale, it’s easy to tell customers that a new, more desirable product will be available in 6 months, and that it will automatically operate with the token system.

While such an assertion is appealing, there is a potentially serious downside—some or all of the revenue associated with the agreement may be deferred until the new technology is available. The topic of revenue recognition was discussed in earlier Subscription Licensing blogs.

It is therefore very important to define and bound the parameters of future technology access whenever customers are provided with such a flexible software licensing model and to carefully consider the impact of revenue recognition.