"The Policy is in the License"
RLM's Simple API Makes Adding Licensing to your Applications Fast and Easy

When developers think about adding a licensing mechanism to their software, they want the licensing software to "do the work" of licensing. They don't want to be in the business of writing special code that handles the various business cases that their license policies are designed to represent.

RLM is designed to allow the software developer to request a license within an application without knowing what kind of policies are present beforehand. He needs to do little to no manipulation of the licensing routines themselves.

With RLM, license policy is largely removed from your application. License policy is defined in the license keys. So, your application requests a license, and the license that is granted is based on what type of license is found in the customer's license pool.  This allows you to address ever-changing business rules by simply varying the type of keys that you issue - not by changing your source code.

Keeping Pandora's Box Closed

Legacy license managers often opened a sort of Pandora's Box by allowing a generic mechanism to store arbitrary information in the key. This proved to be a mistake because it required special programming in your application to retrieve, decode and process the data, and to perform the logic necessary to implement the custom policy that the data in the license string is meant to convey. More importantly, this unfortunate design decision has lead to the proliferation of incomprehensible license strings and unpredictable license behavior across applications and across ISVs. RLM supports new policies not by way of a "catch-all" mechanism, but by enriching the syntax of the license to address new yet generally useful license policy options.  Here are a couple of examples of license policies that are determined solely by the licenses themselves:

Token-Based Licenses

RLM has a simple yet elegant way to define an RLM license in terms of another. It is used in two common ways.

First, it can be used to enable "token-based" pricing models where each of your products checks out a license for itself which also results in license tokens being checked out from a common pool - each product checks out a number of tokens equal to its relative value. Any number and combination of products can be used so long as the maximum number of concurrent tokens in the pool is not exceeded.

This model works especially well for companies that sell suites of related products that are used to various degrees during a project. As the project advances from one phase to another (Design, Test and Simulate), the mix of products used reflects the demands of that phase of the project. So, you don't have to sell a certain number of seats of each product.  You can let the user determine the mix based on his needs.

This model also allows you to introduce new products into your customers easily since the new products consume the same licenses (tokens) that are already installed.
 
The other main use of token-licensing is to enable license alternates. This is the case where you sell a single product that consists of many separately licensable components (product and sub-product model).  If you sell product bundles at a special discounted price, then customers can purchase a combination of both the bundles and the components of the bundles in order to match their requirements. If a component license is unavailable, then a higher priced bundle license, if available, can be checked out to satisfy the request, as a last resort.

A token-based strategy can also address an overdraft situation. In this case, when all the regular licenses are in use, overdraft licenses are consumed instead. If required, the overdraft licenses can have shorter term expiration dates so that they can be used only during a predetermined time window. Remember that overdraft licenses would be reported separately in the report log so that they can be accounted for appropriately.

Remember, no changes to your application are needed to support token-based licensing... "the policy is in the license."
 

 
WAN Licenses - use time zones to increase pricing options

 

 

Your biggest customers usually connect their geographically dispersed sites via a WAN. When they do that, they can potentially share your floating licenses across the globe. For a variety of reasons (exclusive territory assignments, increasing pricing depth, etc), you may want your licenses to be used only within a particular geographical area. With RLM, you can assign a "timezone" keyword to allow use of your software only in those zones. You could charge a higher fee for licenses that cover a wider geographical range, and less for restricted licenses.

Remember again, no changes to your application are needed to support WAN licensing... "the policy is in the license."

For more information on RLM's feature set click here.