From Licensing Hints

101 License Models – Token-Based License Models

A while ago, we wrote a blog post entitled 101 license models.  Since that time we followed up with posts on unrestricted license modelsnodelocked license models, and floating license models.  In this post, we explore the fourth set of license models described in that post – the Token-Based License Models.

   Token-Based License Models

To review, token-based licenses are a special case of floating licenses which allow aliasing of a license or multiple license checkouts per request.  These are usable by anyone who can contact the license server.  Token-based licenses can have any of the following attributes:

Ways to use Token-Based License Models

Token-based licenses are a special case of floating licenses, and they have 3 main uses:

  • packaging together a number of products and distributing a single license
  • creating an alias from one product name to another
  • allowing newer software to run and consume licenses distributed with older software (a special case of #1)

In the first case, packaging together a number of products, let’s say you have product a, b, and c.  Create static token-based licenses for each of a, b, and c which map to a checkout of “d”.  Now you distribute the “d” license, and all 3 products, a, b, and c can run with this license.  Different modes of operation are possible by changing the sharing attributes on the “d” license.

To create an alias, the token definition maps one license checkout request to a different request.  This is useful to transition a product’s license name.

For the 3rd case, a generic token name is the only license you deliver.  All products have token license definitions which map to the generic license name.  As you add new products, they use licenses which your customer already has, thus creating contention for these licenses (meaning increased sales).  This allows your customers to demo your new products while consuming existing licenses – no more free demos!

 

RLM and RLM Activation Pro – what’s the difference?

RLM and RLM Activation Pro

rlm-and-rlm-activation-pro

Sometimes people are a bit confused by the Reprise product line, in particular, wondering about the difference between RLM and RLM Activation Pro. The two products work together, and both products involve a server component, so that’s the basis for the confusion.

Let’s start with a couple of definitions:

  • RLM (the Reprise License Manager) is a software license manager. You (a software publisher) integrate RLM into your product, and RLM keeps track at runtime who is using your product licenses. RLM can do this entirely within the client library (linked into your application), or, more commonly, your application makes a request of the RLM License Server to “check out” a license. The license server runs either on computers in your customer’s network, or in the cloud if you are using our RLMCloud service. Your application uses RLM every time it runs to verify that the license rights are still present, thus enabling use. RLM, however, never gets involved in the issuing of the actual license files to your customers.
  • RLM Activation Pro, on the other hand, is a Software Activation product. Software Activation’s purpose in life is to generate and dispense the license files for your product to your customers with minimum fuss. Activation Pro also has a server component which we call the activation server. Your application contacts the activation server and supplies a short text activation key, and in exchange, the activation server returns the license which enables your product. Generally, this is done once, right after your customer purchases your software, not every time your software is invoked.

So in summary, RLM provides runtime checking that your application is licensed to run and that the current usage of your application is within the limits you have set, every time your application runs. Activation Pro is used once at the time your customer purchases your software in order to retrieve the license file which is specific to that customer.

Using a License Manager as a Load Balancer

(or, if all you have is a hammer, everything looks like a nail)

Introduction – The ProblemUsing a License Manager as a Load Balancer

At Reprise Software, our main product, the Reprise License Manager (RLM) runs on many different platforms (19 at last count). Since our product is a client-server product with an API, we have a set of regression tests that we run both during development and at each release.

One issue of testing a license manager is the desirability to run tests that both succeed in checking out licenses from a license server as well as tests that fail. Given that our product (RLM) is inherently a network-based product, and also given that clients can broadcast to discover a license server, our experience is that running regression tests on multiple machines on the same network at the same time will result in some number of checkouts succeeding that should have failed.

In the past, we have worked around this problem by timing the starts of our regression tests suites so that the individual tests would not overlap each other and yield incorrect results (in this case, incorrect results from the test environment, not from software faults). While this works fine in a development environment, it is extremely awkward during a release cycle when the goal is to build and test many platforms simultaneously.

The Solution – License Management

Since the regression tests are primarily run by a single user, the solution was to create a set of licenses, one per test, then use the License Manager as a Load Balancer to serve them with a single instance per license, nodelocked to the username of the person running the test. Each test checks out it’s own license, and if the license request is queued, the test waits until granted. Now, the tests synchronize across all platforms with the same test never running on multiple platforms at the same time. Different sets of licenses are served for different network segments.

We serve the licenses using RLMCloud, so that the license server is always available, even when development machines go down.  An extra benefit is that our normal regression tests also test the RLMCloud servers at the same time. Win win.

101 License Models

101 License Models – a license model for everyone.101 License Models

License Managers are known for providing flexibility in how you price and license your software.  This blog post discusses 101 license models available to you with the Reprise License Manager.   These models fall into 5 main categories – Unrestricted, Nodelocked, Floating, Token-Based and Metered License Models.  We have discussed some of these in the past, and will talk about others in future blog posts.

So here we go…

Unrestricted License Models

These license models are not locked to any machine or license server.  In other words, they work anywhere.  Often these are appropriate for demo licenses or if you want to be able to display something about the license in a startup dialog, but allow it to run anywhere. Unrestricted licenses can have any of the following attributes:

  • any
  • customer name
  • demo
  • expiring
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • permanent
  • serial number
  • software version
  • user-locked
  Nodelocked License Models

These license models lock the license to a particular computer, and in addition provides other restrictions.  Nodelocked licenses can have any of the following attributes:

  • uncounted
  • computing environment limited
  • customer name
  • detached demo
  • expiring
  • single
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • permanent
  • platform-limited
  • software version
  • timezone-limited
  • upgrade other licenses
  • user-locked
  • VM enabled
    Floating License Models

Floating licenses are the most common usage of a license manager.  These are usable by anyone who can contact the license server.  The floating license models provide the richest set of license control.  Floating licenses can have any of the following attributes:

  Token-based LICENSE MODELS

token-based licenses are a special case of floating licenses which allow aliasing of a license or multiple license checkouts per request.  These are usable by anyone who can contact the license server.  Token-based licenses can have any of the following attributes:

  Metered license models

Metered licenses provide a “postage meter” type of licensing model. Metered licenses work either with pre-paid or post-use payment.  Metered licenses can have any of the following attributes:

  • per-hour
  • per-invocation
  • per-event
  • computing environment limited
  • customer name
  • expiring
  • license type (beta, demo, eval)
  • maintenance-thru-date
  • options
  • password-protected
  • permanent
  • platform-limited
  • replace other licenses
  • software version
  • timezone-limited
  • user-locked
  • VM enabled

Best Practices for License Management

Best Practices for License Management

Time spent paying attention to best practices for license management will pay dividends down the road in customer satisfaction. Following a few basic guidelines will be greatly appreciated by your end-users who will see more consistent implementations from ISV to ISV.

Let’s dive right in:best practices for license management

The Product name you use to check out a license for a product should be as close to the name of the product you sell as possible. We consider it best practice to use the name of the product from your price list.  This is probably the most important thing you can do in your implementation.

In practice, it’s often quite reasonable for ISVs to use multiple license names in an application – just keep it within reason. A good rule of thumb is to use a new license if you charge separately for that feature.

Fewer checkouts per product are generally better from an end-user support and understanding standpoint. In the early days of license management, companies literally “went crazy” adding license checkout calls to smaller and smaller pieces of their application, which resulted in several licenses required to run one product. Resist the temptation to do this.

Installation of Your Product and Finding the Licenses

When you integrate licensing into your product, you need to think about how you will deliver the licenses for it to operate. A large percentage of support calls occur during the installation of the software application. One way to decrease the support burden is to make the installation of the license file as seamless as possible.

For less complex applications deliver the license via automated Internet Activation, such as Reprise’s Activation Pro.  This can make for a much easier installation experience for the end-user.

For more complex applications manually delivering the license may be the best option. Delivery of the license file via email or downloading it from a web support location may be more appropriate. Make sure that it is clear where the license file should be saved.

It is also critical that the application be able to locate the license file at runtime. When Integrating RLM into your product there are a few ways that your application and license server can locate the licenses they need to operate. We provide a “best practices” section in the RLM Reference manual that outlines the best way to define the parameters for defining the license file location. If you follow this advice, you will have a better end-user experience.

Best Practices for License Roaming

A common floating license option provided to end-users is License Roaming. Increasingly, users want to take their work “on the road.” RLM’s built-in license roaming capability allows users to check out a license from a server, physically disconnect from the server and continue to use the license for a specified number of days on their notebooks or laptops, after which the license is automatically returned to the server. Again, no extra work is required beyond enabling roaming in the license file. As an ISV, you control whether licenses are able to roam, and how long they can be checked-out in the disconnected state.

RLM license roaming was designed to allow ‘disconnected’ use for short durations up to a few weeks.

Best Practices for Product Evaluations/Demos

One compelling value of software licensing is to provide a way to promote and market your application to prospective buyers. You should provide demo or evaluation licenses to your customers. Here is a brief summary of best practices for this scenario that can help increase sales.

  • Expose all functionality to the user – even if you limit scope of use, show the user what could be possible.
  • Show “number of eval days remaining” on the start-up screen – creates user urgency and an expiration date creates timetable for sales follow up.
  • Always remind the user how to buy, even after the eval has ended, by providing a link to information on how to buy
  • Do not require the software to be re-downloaded or reinstalled when upgrading to a paid license – this is one key value of a license manager.

One of the primary goals of software licensing is to increase revenue opportunities. In order to maximize the efficiency of software licensing, it is critical to spend time in planning and design. Various license models can be utilized to increase revenue opportunities and varying degrees of security can be incorporated. It is also important when implementing software licensing, that the end user’s interaction be considered.

A software License manager like RLM is an indispensable tool that can help you to design and enforce pricing models that are right for today’s customers, while giving you the flexibility to quickly adapt to new opportunities as they emerge.

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.

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 uHow many licenses can a license server servese 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.

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.