Category: License Models

License Models and techniques to license your software.

Client-Side Caching Improves Licensing Performance

Cloud Computing Highlights the Need for Client-Side Caching

An increasing number of software vendors are hosting license servers in the Cloud for their end customers. The longer physical distance between client and the license server introduces more network latency.  License checkout times may be slower over these longer distances compared with those over a local area network. Applications with short duty-cycles or massively parallel applications that require frequent checkouts over a short period of time are affected the most. To address this challenge RLM supports “license caching” on the client.

Since v10.1, RLM lets software vendors create licenses that specify a “cache time” in seconds so that when licenses are checked out, RLM will create a cached license on the local client machine.  If the same user on this host subsequently checks out the license before the cache time expires, then the local cached license is used, avoiding a connection to the license server.

To use caching, the license must specify the keyword “client_cache=N” where N is duration of the cache period in seconds. Any license with a client_cache specification is treated by the license server identically to a license with a min_checkout specification.

For a more detailed technical description of this feature, please refer to the RLM Reference Manual section entitled “Client-Side License Caching.”

Token-Based Licenses

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.

The Floating License

The Floating License – The most common license model

Last time we discussed the nodelocked and nodelocked counted licenses, which are license grants that allows your software to be used on a particular computer, and on that computer only.  A far more common license is the floating license.  The floating license is what made license managers famous, and it is supported by all major license managers. A floating license allows a specified number of independent instances of your application to run anywhere on your customer’s network so long as that number does not exceed the predefined limit specified in the license.

The floating license was originally made popular when we developed FLEXlm at GLOBEtrotter Software; in particular, Sun Microsystems’ use of floating licenses for their compilers made most software developers aware of the power of this license model. 

As we discussed in our blog post describing the nodelocked license, having several license models in your price book allows you, as a publisher, to price differently depending on your customer’s situation, which allows you to capture the optimal amount of revenue for a particular customer.  Nodelocked uncounted licenses may be appropriate for some of your products, while floating licenses are more appropriate for others.  A mixture of floating and nodelocked licenses can help maximize revenues depending on your customer’s situation.

If your application is meant to be used collaboratively, you might want to use floating licenses.  If you support both nodelocked and floating licenses, then you can usually charge a price premium for the floating license because its usage terms are less restrictive.  Price premiums can range from as little as few tens of percent to a factor of three or more, depending on the usage profile of the software and how it is shared. In general, it’s best to offer multiple license types because it helps you to expand your account penetration by reaching more users.

To implement floating licenses in RLM, specify a license server with the SERVER line, and set the count field of the license to a positive integer.  The license itself has no associated hostid, meaning that it will run anywhere. The license server (specified by the SERVER and ISV lines) keeps track of the number of instances in use.  A floating license always requires a license server, so it is the next step up in complexity from nodelocked licenses.   RLM-Embedded does not support floating licenses.

Next time:  token-based licenses.

Software Trials without the Internet

Creating Software Trials without the Internet

Most software vendors offer trial copies of their software to potential customers for short-term evaluations.  The trial may run in full or reduced-functionality mode, but only for a short time, 30 days or so.  Sometimes, they want to create software trials without the Internet being available.

Ideally, the evaluation/trial starts when the user is ready, not when he/she first requests the evaluation.  While it’s possible to use an on-line activation system to implement the “start when I’m ready” functionality, that of course requires an Internet connection.

Commonly, vendors use an Internet activation system such as Reprise’s Activation Pro to authorize trials. This works well when the customer has an Internet connection, but what do you do when there is no Internet connection? For instance, what happens if the user is flying at 35,000 feet, or simply has no Internet connection?

RLM offers a capability called “detached demo” to handle this case. Through RLM, your application creates a short-term license that authorizes your product to run for ‘n’ days… without an Internet connection. After the demo period ends, RLM ensures that the user can’t reinstall the demo on the same machine. It allows one demo period only.

The benefits to this approach are clear – when the user is ready to test your software, he gets access for the full n-day period, even when disconnected from the Internet. This experience creates higher customer satisfaction, reducing the common claim: (“I couldn’t find the time to test, can you please send me a new eval key?”) and should result in a increased sales.

How many licenses can a license server serve?

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.

NodeLocked Counted License

Another simple license model – the NodeLocked Counted License.

Last time we discussed the nodelocked license, which is a license grant that allows your software to be used on a particular computer, and on that computer only. The typical nodelocked license is uncounted, meaning that if the software is running on the specified computer, any number of concurrent copies of the software are allowed to run. There is a variation of the nodelocked license called a nodelocked counted license. This license allows the software to be run on a single computer only, but it limits the number of concurrent copies of the software that can be run on that computer.

The nodelocked counted license was originally made popular in the Electronic Design Automation software market.  However, a nodelocked counted license is suitable for situations where your software usually runs on a server-class computer, since a nodelocked uncounted license on such a system can provide far more value than a typical nodelocked license locked to a workstation or PC.

RLM supports two flavors of nodelocked counted licenses: single and counted.    The single license is a special case of a node-locked counted license which does not require a license server, so it is as simple to administer as a nodelocked uncounted license.  The general case of a nodelocked counted license does require a license server.

As we discussed in our blog post describing the nodelocked license, having several license models in your price book allows you, as a publisher, to price differently depending on your customer’s situation, which allows you to capture the optimal amount of revenue for a particular customer.  Nodelocked uncounted licenses may be appropriate for some of your products, while nodelocked uncounted licenses are more appropriatre for others.  A mixture of floating and nodelocked licenses can help maximize revenues depending on your customer’s situation.

To implement nodelocked counted licenses in RLM, set the count field of the license to either “single” or a positive integer, and specify the hostid of the computer in the actual license. A nodelocked single license does not require a license server, so it is as simple as a nodelocked uncounted license to deploy. A nodelocked counted license with a count (even if the count is 1) does requrire a license server, so it is the next step up in complexity. 

Next time:  floating licenses.

Maintenance-Thru-Date Licenses

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.

 

Which RLM Edition is best?

Three Editions of Reprise Software Licensing Toolkits – which RLM Edition is best for you?

Reprise Software now offers three licensing toolkit editions addressing the software licensing needs of cost-conscious ISVs.  This article compares the three editions to help you decide which RLM edition is best for you.

Reprise Software offers “RLM”, “RLM-Embedded”, and “RLM-ez.”  Each edition is a complete solution with tools for integrating license enforcement  into your applications, and for generating licenses to enable them. They all are based on a common set of licensing apis. How do they compare?

RLM

Reprise Software’s flagship product is RLM.  It contains all of the bells and whistles that users have come to expect from the best in enterprise class software license management.  RLM was designed by the same team that brought you FLEXlm, so in a sense RLM is the next generation of software licensing solutions.  RLM is used by hundreds of independent software vendors who deliver millions of licenses to users, worldwide.

RLM supports a wide array of software licensing models including floating or concurrent user, named user, and many others. RLM includes the RLM License Server that supports a full built-in admin interface.  The RLM License Server produces reports logs that are easy to parse into usage and billing reports using 3rd party tools, or tools that you write using the well-documented, open report log format specification. Reprise Software’s Activation Pro product supports Internet activation for RLM licenses.

First introduced in May of 2006, RLM supports the widest selection of platforms.

RLM-Embedded

Like RLM-ez, RLM-Embedded as a toolkit that supports node-locked licenses only, but with a rich api to support an unlimited number of products, and optional Internet activation via Activation Pro. RLM-Embedded uses the very same api as RLM, so if you upgrade to RLM, then you need to make no source code changes.

As you would expect, RLM-Embedded is offered at a much lower price point that the full RLM product.  In addition to supporting Windows, Linux, and Mac, RLM-Embedded supports some Unix platforms as well.

RLM-Embedded was first released in September, 2009.

RLM-ez

RLM-ez addresses simple node-locked licensing styles only.  If you simply want to make sure your software can run only on authorized computers, then RLM-ez is a good choice.  It uses industry standard digital signature technology so that you can deliver tamper-proof text-based licenses that are locked to your customer’s computer.

The RLM-ez API is very simple, with only a handful calls.  A typical use case for RLM-ez is when you want your customers to freely download your application for a trial period without you having to get involved.  This works well for low cost software where special hand-holding for licensing would be cost prohibitive.  When your customer wants to buy, he sends you his hostid, you generate a license, and email it back. Done.

RLM-ez pricing is a small one-time fee, per product, per platform. RLM-ez is supported on all the major desktop platforms, including Windows, Linux, and Mac.

RLM-ez was first released in March, 2014.

Please contact the Reprise Software Sales Team for more information and detailed pricing.