Don’t paint yourself into the corner – use Policy in the License.
When you think about adding licensing to your software, you want the licensing software to “do the work” of licensing. You don’t want to write special code to handle the various business cases for your licenses. When you put the policy in the license, you remove it from the application code. This makes changes down the road much easier.
RLM allows you to request a license within an application without knowing what kind of policies are present beforehand. You need to do little to no manipulation of the licensing routines themselves.
With RLM, license policy is in the license keys, where it belongs. We call this “Policy in the License”. So when your application requests a license, the license is granted is based on what licenses are found in the customer’s license pool. This allows you to address ever-changing business rules by varying the type of license keys that you issue.
Keeping Pandora’s Box Closed
Legacy license managers open a Pandora’s Box by allowing applications to store arbitrary information in the license key. This is a mistake because it requires special programming in your application to retrieve, decode and process the data. Your application then needs the logic necessary to implement the custom policy which the data specified. More importantly, this unfortunate design decision leads to the proliferation of incomprehensible license strings. Unpredictable license behavior across applications and across ISVs is the result. RLM supports new policies by enriching the syntax of the license to address new yet generally useful license policy options. Here are a couple of examples of Policy in the License:
RLM has a simple yet elegant way to define one RLM license in terms of another. It is used in two common ways.
First, it can enable “token-based” pricing models where each of your products checks out a license for itself which results in license tokens 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 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 sell a certain number of seats of each product. Instead, the user determines the mix based on his needs.
This model also allows you to introduce new products to 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 overdraft situations. 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. And overdraft licenses are reported separately in the report log, so they are accounted for appropriately.
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 share your floating licenses across the globe. For a variety of reasons you may want your licenses used only within a particular geographical area. With RLM, you can assign a “timezone” to the license 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.
Again, no changes to your application are needed to support WAN licensing when you use “policy in the license.”