Using Token-Based Licenses to Increase Licensing Flexibility

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.

So, How many licenses can a license server serve, you ask?

This question “how many licenses can a license server serve” has come up since the beginning of time (or at least since 1988). The answer is, of course, “it depends”.

What does it depend on? Well, for license managers like RLM or FLEXlm (FLEXnet publisher), which use TCP/IP connections for clients, it depends on the configuration of the license server’s OS. The typical answer is somewhere between 6,000 and 15,000.  That is the answer we have given since 1988, and it hasn’t changed much.  This rough sizing has worked well for the past 28 years, when license servers were deployed on-premesis and for larger customers, licenses were split between multiple server instances.  This architecture does not work well when an ISV wants to serve licenses for all their customers in a cloud-based license server.

To support cloud-based license servers, in RLM v9.0 (Dec, 2010) we introduced support for license server “farms”, to allow multiple copies of a license server to run on a single machine.  These license server farms allow the number of clients to scale with the number of license server processes. Also, in RLM v10.0 (Jan, 2013), we introduced support for “disconnected clients”.  While this still uses TCP/IP, the client does not keep the connection to the license server open for the life of the license.  Our tests show that a server can support an order of magnitude more disconnected clients than “traditional” clients.  So 100,000 disconnected clients per server is a good rule-of-thumb.

Of course,  there is also the question of the relationship between the number of licenses installed on the license server, and the number of simultaneous clients using those licenses.   There can be far more licenses installed on the server if the actual usage is a low percentage.

All of this came into focus for us recently during a support interaction with one of our customers.  This customer was hosting a license server for all of their customers; this license server has over 220,000 licenses in over 13,000 distinct “license pools” (representing somewere between 6,000 and 10,000 individual customers).  The point of telling you this is twofold:  first, we would never recommend configuring a single instance of a license server this way, and second, that it actually works, in production, to serve this many licenses for this many clients.

What would we recommend?  Since RLM supports “license server farms” to scale the number of clients, we would recommend putting no more than 1000-2000 distinct customers on an individual license server, and running multiple copies of the license server on the server machine.  So in this case, we would recommend 7-14 separate license servers, and adding more servers as the number of customers grows.  And we would also recommend using disconnected operation so that even if the number of concurrent clients approaches the license limit on the server the number of clients will not get too high.

But at the end of the day, even this heavily-loaded server continues to operate in production for our customer.

Creating Maintenance-Thru-Date Licenses

Many software publishers wish to issue a license to their customers which allows the customer to run (forever) any version of the software which is released before a particular date.  We call this a “maintenance-thru-date” license.  A typical example is that the customer is allowed to run any software released up to 12 months after their original purchase of the software.  If the publisher releases a new version in 11 months, the customer can use this version as well, but they cannot use any version which is released more than 12 months later.

A “maintenance-thru-date” license is implemted with a “date-based” version.  Briefly, you request a version of your software which encodes the release date, and you generate licenses with versions that specify the last release date which can be used.

To implement this in your product, do the following:

• set the version field of the license to a date, in the format yyyy.mm,
• specify the version in your call to rlm_checkout() in the same date format, with a date corresponding to the date of release.
• When you issue licenses, issue them with a version number corresponding to the expiration of their support.

For example, if you want to issue a one-year supported license in May of 2016, you would issue a license of version 2017.05 to your customer. When you release your software in December of 2016, you would request version 2016.12 and the 2017.05 license would work for this version of your software.  When you release again in July of 2017 (with a requested version of 2017.07), your customer will not be able to run that release of your software.

It is certainly possible to use other date formats, however, the format above is used by RLM Activation Pro and it seems as good as any.