Consider your end user and long term support implications when designing your licensing implementation
In this article we attempt to provide a framework for how well-behaved applications use RLM. Adherence to these guidelines will be greatly appreciated by your end-users who will see more consistent implementations across their various RLM ISVs. This will also translate into lower support costs for you, as applications from different RLM ISVs will behave in a more consistent fashion.
Previously, as GLOBEtrotter Software, we supported thousands of ISVs and end-users. This experience taught us that certain design decisions can cause long-term support problems. While we have made every effort to remove options from RLM that cause end-user confusion with little corresponding benefit, there are still things that you can do to make your customers’ installation and on-going support easier.
License by actual Product Name, when possible
The name you use to check out a license from within your product should be as close to the actual marketing name of the product as possible. Users will better understand what they are entitled to when they can relate the product license names to the products that they bought.
Fewer Checkout Calls
Fewer checkouts per product generally promote better end-user support and understanding. 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.
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 just one 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 the things for which you price separately. It seems obvious, but many ISVs have gone far, far beyond that – to the dissatisfaction of their customers.
Reprise Software considers it best practice to:
- Checkout the name from your price list, or a name as close to this as possible.
- Use as few checkout calls as possible to accomplish your licensing strategy. See related paragraphs above.
- If possible, 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. But, when needed, use these fields in a very self-evident way so that end users can understand their meaning and what functions they control.
- Be conscious of license server traffic load. DO NOT USE the rlm_license_xxxx() calls (other than rlm_license_stat()) to do anything beyond displaying information to your user.