Token-Based Licenses

Using Token-Based Licenses to Increase Licensing FlexibilityToken-Based Licenses

Once you have mastered the basic license models that all license managers provide, it might be time to take a look at some of the more advanced models.  Token-Based Licenses provide advanced license options that aren’t available any other way.

In prior lives, we invented “Package” licenses, but these turned out to have many problems, most of which are solved by Token-Based Licenses.  In addition, Token-Based Licenses enable functionality well beyond the old Package license.   In particular, a Token-Based License allows you to:

  • create product bundles or packages (much like Package licenses), or
  • define all your product licenses as multiples of a single base license, or
  • let a user consume a more-expensive alternative license when a more-common product is unavailable

Today, we’ll discuss the idea of licensing all your products as a function of a single base license.

If you define a single base license then use multiples of that base license to enable all your products, this gives your customer the ability to mix and match different products from your catalog up to the total limit of the number of base licenses purchased.  This has the additional advantage of allowing your customer to use new products before they have gone through the purchasing cycle for them – the ultimate “try before you buy” experience, since they are using actual purchased licenses to evaluate your new products, and can do so without even contacting a salesperson.

The best part is that you don’t have to do anything special to start using Token-Based Licenses.  You implement the RLM API as you would for any supported license model.  If this is already done, great!  No need to create a second version of your product just to support Token-Based Licenses – it’s built in.  In each product, check out a license that is specific to that product, let’s call it “write” for example.

Next, when you create licenses for your customers, you would create some number of the base licenses.  We will call them “base” for this example.

Finally,  you create a token license that relates a “write” request to “base” licenses.  Typically, this mapping would be generic (ie, the same for all your customers), although you can make the definition customer-specific as well.

You may decide that a v1.0 request for “write” requires 3 v1.0 “base” licenses.  If this is the case, you would use a license line like the following to define the token mapping:

LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<base 1.0 3>”

This license tells RLM that when a v1.0 “write” license is requested, it should instead check out 3 licenses of the “base” v1.0 license.

Be sure to also include in the customer’s license file the appropriate number of “base” licenses.  For example, if your customer wants to be able to run 2 copies of “write” at the same time:

LICENSE SOFTWARE_CO base 1.0 PERMANENT 6 SIG=XXXX

In the above example, the customer will consume three “base” licenses for each instance of “write” that they run, up to a concurrent limit of 6 “base” licenses, or two concurrent instances of “write”. Additional products can be defined in terms of “base” licenses as well.

Next time, we will talk about other ways to use Token-Based Licenses.

Leave a Reply

Your email address will not be published. Required fields are marked *