Best Practices for RLM Integration

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 customer’s 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 Call, 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_stat()) to do anything beyond displaying information to your user.

Installation of Product and Finding Licenses

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:

RLM_LICENSE (or <ISV>_LICENSE) environment variable
Options you provide to your user to specify a license location, and
Licenses present in your product’s binary directory

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 customer’s License Administrator 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.

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 end users. In general, the more fragmented into separate license domains an application becomes, the less end users understand the licensing behavior and the less satisfied they are. In an ideal world (from the end user’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.