Best Practices for Integrating RLM

Our experience supporting thousands of ISVs and license administrators has taught us that certain design decisions can cause long-term support problems. While we have made every effort to remove options from RLM which cause license administrator confusion with little corresponding benefit, there are still things that you can do to make things easier for your customer’s installation and support.

In this section, we attempt to provide a framework for how well-behaved applications use RLM. Adherence to these guidelines, while not strictly mandatory, will be greatly appreciated by your license administrators who will see more consistent implementations from ISV to ISV. This will also translate into support savings for you, as applications from different ISVs will behave in a more consistent fashion.

Product names

The 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. Fewer checkouts per product are generally better from an license administrator support and understanding standpoint. In the early days of license management, companies literally “went crazy” adding 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. If your product is a schematic editor, you probably don’t need checkout calls to license the code that reads and writes the data files. You might, but probably not.

Reprise Software considers it best practice to:

  • Use the name from your price list in the rlm_checkout() call, or a name as close to this as possible.

  • Use as few rlm_checkout() calls as possible to accomplish your licensing strategy. Why? See Use Few Checkout Calls, below

  • AVOID THE USE of license text fields (such as customer, contract, etc.) to control how your application behaves, other than presenting this data to the user.

  • DO NOT USE the rlm_license_xxxx() calls (other than rlm_license_akey(), rlm_license_count() and rlm_license_stat()) to do anything beyond displaying information to your user.

Installation of your product and finding the licenses for it to operate

When you integrate RLM into your product there are issues concerning delivery of your product and the licenses for it to operate. As you already know from the chapters on Integrating RLM Into Your Product, and The License File, there are a few ways that your application and license server can locate the licenses they need to operate:

  • Licenses present in your product’s binary directory.

  • Options you provide to your user to specify a license location.

  • RLM_LICENSE (or <ISV>_LICENSE) environment variable.

Reprise Software considers it best practice to:

  • AVOID using RLM_LICENSE or <ISV>_LICENSE as part of your installation scripts or adding definitions of these variables to your user’s environment. If you want to set a default license file, you should do this by locating the license file (or a link to the license file) in the directory with your binaries, or by using the optional license location in the first parameter to rlm_init().

  • ALWAYS leave RLM_LICENSE and <ISV>_LICENSE environment variables unset - so the license administrator can override any defaults you have specified.

  • ALWAYS provide the path to your binary as the second parameter to rlm_init(). In this way, your license administrators will know that they can put the license file (or a link) in this directory and it will be the “last resort” license file to be used.

  • If you are not using an ISV-defined hostid , ship the ISV server settings file rather than the ISV server binary. Using the settings file means that your server-side executables are completely generic, and your customers can upgrade RLM versions and get bug fixes via a download from Reprise, and you have no ISV server build-test-release cycle to go through.

  • Include a folder for licenses in your installed product folder tree. In this folder, if you ship floating licenses, you would create a license file with a single HOST line similar to the following:

    HOST myserver any 5053

Note

This HOST line does not need a valid hostid, only a correct port# and hostname). At runtime, your application passes the path to this directory as the first argument to rlm_init(). Then any license you ever issue - an expiring demo license, a production nodelocked license, or a license file simply containing a HOST line as described above - goes in one or more .lic files in that licenses folder. Given that you have passed the path to that directory to rlm_init(), your application will always be able to find the licenses.

Use Few Checkout Calls

The recommendation to use as few checkout calls as possible is made in response to our experience in talking with many license administrators. In general, the more fragmented into separate license domains an application becomes, the less license administrators understand the licensing behavior and the less satisfied they are. In an ideal world (from the license administrator’s point of view), an application would need to check out 1 license in order to run, and the name of that license would be the name of the application.

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 distinct licenses for things you charge extra money for. It seems obvious, but many ISVs have gone far, far beyond that - to the dissatisfaction of their customers.