Advanced Use of Token-Based Licenses

Last time, we discussed how to license all your products as a function of a single base license, by using a Token-Based License.  Today, we will talk about the other 2 uses of token-based licenses:

• create product bundles or packages (much like Package licenses), or
• let a user consume a more-expensive alternative license when a more-common product is unavailable

If you want to create a product bundle called “office”, and that the components of this bundle are “write”, “calc”, and “present”, you would proceed as follows:   your 3 products would each check out the appropriate license (write for write, calc for calc, and present for present). To create the product bundle, you would create 3 token definitions for the 3 individual components:

LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<office 1.0 1>”

LICENSE SOFTWARE_CO calc 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<office 1.0 1>”

LICENSE SOFTWARE_CO present 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<office 1.0 1>”

These token definitions define how the products are packaged together, and don’t vary from customer to customer. Now, when your customer buys the office product, you issue them an office license, like this:

LICENSE SOFTWARE_CO office 1.0 PERMANENT 6 SIG=XXXX share=uh

This license allows 6 copies of the office package to float on your customer’s network.   If the same user uses both write and calc, they still only consume a single license due to the share=uh specification in the office license.

As we said before, 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. No need to create a second version of your product to support Token-Based Licenses – it’s built in.  In each product, check out a license that is specific to that product, for example, “write”.

For another example, let’s say that you sell both write and writerPro licenses, where the writerPro license includes all the functionality of write, plus more.   If your customer has both write and writerPro licenses, they may run into the situation where they are using all their write licenses, and the next user wants to use write, but no licenses are available and yet there are unused writerPro licenses.

If you define a token-based license for write that uses the writerPro license, then your customer can use the more-expensive writerPro license to run write.  That license would look like this:

LICENSE SOFTWARE_CO write 1.0 PERMANENT TOKEN SIG=XXXX  TOKEN=”<writerPro 1.0 1>”

Of course, they would need to have both write and writerPro licenses available for this token definition to do any good since the TOKEN license itself doesn’t authorize any license usage, it is simply a mapping from one checkout request to another.  And in this case, they would want the licenses to be in this order:

• write license
• write token definition
• writerPro license

This order ensures that requests for write first use the write licenses, then if none are available, they would use writerPro licenses.