From For Publishers

Various topics pertaining to the technology of license management, both internal to license managers and the use of license managers in software products.

ISV-Defined Hostids

Defining new Hostids within RLM

RLM comes with a comprehensive set of integrated hostids, but there are times when ISVs need to lock their software licenses to something else. The three most common reasons for ISV-defined hostids are:

  1. Supporting non-Reprise dongles
  2. Tying licenses to peripheral hardware devices
  3. Combining various identifying elements of the computer.

ISV-Defined Hostid

RLM provides the ability to extend the native set of hostids by using your own routines to obtain host identification which is unique to you.

In order to do this, you use the rlm_add_isv_hostid() call in your application. If you want to support multiple instances of your hostid type on a single computer, you would use the rlm_add_isv_hostid_multiple() call.

For more information on ISV-defined hostids, please consult the latest RLM Reference Manual or contact Reprise Software.

RLM License Administration Bundle

RLM License Administration Bundle for License Administrators and End Users

The RLM License Administration Bundle is designed to give license administrators everything they need to maximize their use of RLM-licensed applications, the bundle contains the most-current RLM license server, and a tool, “rlmtests,” to help with license server and network capacity planning.

The RLM License Administration Bundle includes some testing tools that let License Administrators answer questions such as:

  • How fast can my license server service license requests?
  • How many licensed users can my server handle?
  • What will my performance be if I double my current user population?
  • When should I split my license inventory into multiple independent license servers?

‘rlmtests’ is totally self-contained, creating the required test licenses and then starting a license server before it runs the tests, finally reporting the results on the screen. The rlmtests utility performs two categories of tests: checkout performance tests and server capacity tests.

With this utility, license administrators and other end users can be proactive about their hardware requirements, matching available hardware to expected needs and developing a plan for hardware acquisition to match the growth in users of RLM-licensed software.

The RLM License Administration Bundle can be downloaded from the RLM License Admin support page:

How to Produce RLM Report Logs

SUMMARY: RLM license servers can produce detailed report logs of the license activity of your products. By default, these log files are turned off. This article will explain the potential uses of these report log files, what they are and how to tell your RLM license server to start producing them.

User Benefits

Users of products that use RLM license servers for floating or concurrent licenses use report logs for:

  • Proof of internal license compliance
  • Allocating costs across departments who share licenses.
  • Asset and maintenance cost optimization and budget planning
  • Entering into and monitor usage-based software licensing agreements

ISV Benefits

Software vendors benefit from report logs too. They can be used to:

  • Reconcile over-usage
  • Build post-use billing models
  • Produce audit reports to support future product pricing negotiations

How to turn on RLM Report Logs

There is nothing that the ISV needs to do.  The user creates an “options file” for each RLM ISV for which he wants to produce a log file, and adds this line to the file: REPORTLOG +file_path

Also, on the ISV line of the license file, the options file name must be specified.

Format (pre-RLM v9.0): ISV isvname isvname.exe isvname.opt


Format (RLM v9.0+): ISV isvname options=isvname.opt


Other RLM Report Log Features

  • Plain-text format is fully documented
  • Applications can ensure that report logs are capturing usage
  • ROTATE [daily | weekly | monthly | #days ], automatic log file rotation
  • Feature names mapped to “product names”
  • Authentication to ensure report data integrity
  • Anonymized – ensures user privacy
  • ISVs can write their own report log records
  • 3rd party RLM reporting tools are available from Reprise Software partners

For more information about RLM report log and its format specification, please review the RLM End User Manual.

Format (pre-RLM v9.0):

ISV isvname [isv-binary-pathname [options-file-filename [port-number]]]

Format (RLM v9.0+):

ISV isvname [isv-binary-pathname [options-file-filename [port-number]]] [binary=isv-binary-pathname] [options=options-file-filename] [port=port-number]

Reprise Software Announces Software Activation

Reprise Announces Software Activation – RLM Activation Pro

Reprise Software is pleased to announce a new product, RLM Activation Pro.  The new product is ready for beta testing immediately on Linux, Mac OSX and Windows, and it is scheduled to be released during Q2 2011.

RLM Activation Pro offers better performance, scalability, access control, and back-office integration options.

RLM Activation Pro provides all the standard Software Activation features, including:Software Activation

  • secure license rehosting
  • software activation database built on open source MySQL
  • written in open source PHP scripting language
  • supports pagination and sorting of displayed data
  • secured multi-user access privileges (admin, edit, view) through usernames/passwords
  • compatible with existing RLM client activation API call, rlm_activate()
  • database conversion utility provided to upgrade from old RLM Internet Activation product

RLM Activation Pro is a separate product, not simply an upgrade to the older “RLM Internet Activation” product. However, RLM Internet Activation (older product) will continue to be supported and is available for sale to new and existing RLM licensees.

For more information, please see

Please contact Reprise Software to discuss new product details.

Licensing a multi-featured product with RLM

Recently we received a common question from one of our customers looking for some advice.

Q: My application is a suite of programs that can be licensed in various combinations.  What’s the best way to design the licenses in this case?

The answer depends on whether the components are always released on separate schedules or as a group.  If the former, then use a separate LICENSE line for each one.  This allows them to have different attributes, such as version and expiration.

If the components are always released as a group, then they can be licensed with a single LICENSE, with the specific set of components authorized expressed in the “OPTIONS=” attribute of the license (example below).

If you choose the OPTIONS field route, then the value of the OPTIONS attribute can be retrieved using the RLM api call rlm_license_options(). This call returns the contents of the OPTIONS string so that your application can parse it to determine which features should be enabled.

Example: OPTIONS=”pie bar scatter max_points=1000″

RLM License Generation Options

With the release of RLM v9 in December 2010, there are now three basic ways to generate licenses for your customers.  Let’s examine your options in order from the simplest to the most comprehensive.

RLMgen program

RLM v9 introduces a new graphical, web-based program for generating RLM licenses called RLMgen.   RLMgen simplifies license generation by allowing your staff to interactively define products in terms of the kinds of licenses you want to enable them. Separate definitions can be created for eval/trials, periodic pricing models, and permanent licenses. License parameters that are common to most licenses can be defined to apply to all license definitions. Once defined, licenses can be generated by entering the number of licenses, an expiration date, and the customer’s hostid.

RLMgen is especially useful for simple products were there is only one feature per product.

RLMsign Utility

If your products consist of multiple features per license, or if you need to incorporate license generation into your existing automated processes, then using the standard license generation tool provided with RLM could be right for you. This utility program called RLMsign, parses stored license templates then inserts a digital signature into each license that it finds.  The result is a license file that is ready to send to your customer.

Since RLMsign can handle arbitrarily complex licenses in each template, it is particularly well suited to support modular products that are sold in an array of different configurations.

API call rlm_sign_license()

RLM also offers a call in the standard RLM SDK called rlm_sign_license() that signs individual licenses in memory. This call is useful when you need to create a custom application that generates licenses, or to integrate license creation into your existing back office infrastructure, when access at the source code level is required.

RLM Version 9 is Released

Reprise Software is pleased to announce that RLM v9 was officially released on Thursday Dec. 16th, 2010.

RLM v9 contains several significant product improvements. Some highlights:

  • includes an interactive, graphical license generator.
  • allows you to set up an internal license server farm to deploy your applications in the cloud.
  • has a license checkout debugging capability.

Of course, RLM v9 contains much more.  Please contact Reprise Software for more details.

RLM ISV Settings File – Easier Server Upgrades

Summary: The RLM settings files provides a convenient method of upgrading license servers in the field. The settings file consists of the ISV-specific information in the RLM license server making it easier to upgrade your customers. Read on about the example use cases and benefits of using RLM ISV settings files.

The Basics

The server side of RLM consists of two programs: the rlm server and the ISV server.  The rlm server (rlm[.exe]) is generic – in other words, it contains no executable code that is ISV-specific.  The ISV server, on the other hand is specific to an ISV, as it encapsulates at a minimum, the ISV’s name and its public encryption key.  The ISV server’s file name is <ISVname>[.exe].

Settings Files Introduced

Starting with RLM version 6.0, an alternative to the traditional packaging of the ISV server as an executable file became available.  This alternative is the settings file, a small data file (several hundred bytes) containing the ISV’s unique server settings.  The platform-independent settings file is built automatically during the RLM build process and is encrypted and authenticated.  When a settings file is present at server startup instead of an executable ISV server, the generic rlm server spawns a copy of itself.  The spawned copy reads the settings file and takes on the “personality” of the ISV server – it becomes a 100% functional equivalent of the old-style executable ISV-specific ISV server, but with one caveat. If you use ISV-defined hostids, then the actual ISV server binary program must be used – not the settings file.

The Benefits of Settings Files

As we mentioned above, the settings file externalizes the unique elements of the ISV server executable, making the ISV server completely generic.  Consequently, these generic programs are always available on all supported RLM development platforms.  When a server upgrade is necessary, the ISV can more quickly deploy the generic server than ISV-supplied programs because they don’t have to go through the ISV’s usual development/QA/release cycle.  A couple of additional benefits accrue:

  • Because the settings file is platform-independent, the ISV can support server platforms that they do not have in-house.  The ISV still needs to purchase a license for RLM on non-inhouse platforms, but they do not need to actually have those development platforms. This allows ISVs to support server platforms that are requested by their end users without having to actually build RLM on these platforms.
  • Because by default the ISV’s settings file works with any RLM version after v6, the process of upgrading RLM versions on the server side in the field becomes almost trivial. End users simply download and install the latest generic rlm server version.

Usage Example

As an example of easy server upgrades, consider an end-user site running a v7 rlm server and settings file for ISV “abc”.  They run into a bug (P188), which is a case-sensitivity problem with RLM_PROJECT.  This bug is fixed in RLM v8.0.  Since the fix is implemented entirely on the server side and the server side executable is entirely generic due to use of a settings file, the end user can get the fix simply by downloading and installing rlm[.exe] from  There is no need for the end user to wait for the ISV to adopt RLM v8 – the fix is accessible to the end user the same day as v8 is released.

Integrating the Reprise License Manager (RLM) with

Several customers have recently asked us if any software vendors who use RLM for licensing have extended to handle licensing information.  The answer is yes. One of our customers who uses both RLM and other older licensing technologies has written an integrated web service and activation API that ties into

Here’s a quick summary of what one of our customers does:

  • create a new sale in
  • send download instructions to customer with a unique activation code
  • customer downloads/installs software, enters activation code into the application
  • activation server returns generated license, stored locally
  • generated license also stored in transaction record in

This RLM ISV has extended Salesforce and created a new License object (or table) which is associated with a Salesforce Account. When they make a license sale they create a new License record in Salesforce and populate it with parameters pertaining to the product license (node locked / floating, count, licensed modules, expiry etc). When this information is saved an “activation code” is generated and saved along with the rest of the licensing options. The activation code is something unique that can identify this record in Salesforce.

Their support desk sends the activation code to the end customer and he/she downloads and installs the application program.  This activation code can then be entered into the application which connects to the ISV’s own internet license activation service. The information submitted includes the activation code along with hardware information, or HostID. The license service is responsible for connecting to Salesforce and generating the RLM license. For transactional purposes they also store this generated license in Salesforce. The license is returned to the application and saved locally on their machine.

Options and More Options

Using ‘Vendor Defined’ Optional Keywords

Since license policy in RLM is defined largely by license keys, a single binary version of your RLM-based application can support many different license policies. Once RLM is implemented, you can address ever-changing business rules by simply varying the type of license keys that you issue. RLM can support a wide range of licensing options and policies, many of which have been covered in previous articles on this blog under the “technology” heading.

This article briefly discusses a few optional license fields. The following license keywords can be classified as ‘vendor defined’ options as they are not used by RLM to determine policy, but can be accessed by your application to further restrict usage rights or present information to the end-user, such as in a start-up splash screen. These optional fields are factored into the license’s digital signature, so they are not editable by your customers. The fields are described below:

  • Options= if your product has many separately-purchasable sub-features,
    you can list the ones which are licensed in this string. Some examples of how this might used include:  limit the number of database records that can be created or accessed, or the number of accounts that can be open, or the number of ports that can be accessed, etc.? This information can be entered into the ‘options = options_list‘  field and it must be parsed by your application.
  • Contract= can be used to hold the customer’s purchase information or software agreement number. This can be displayed to the end-user to validate a support contract, etc.
  • Issuer= could be used to identify the organization that issued the license, such as a third party distributor, or reseller, etc.
  • Customer= used to identify the name of licensed customer and can be displayed by your application. Displaying this information in an “about box” or splash-screen can be an added deterent to unauthorized use. It is unlikely that Mega South-East Airlines would want to use a license that was issued to Main St. Bank.
  • Type= used to identify the type of license and is a string containing one or more of the values:
    • “beta”
    • “demo”
    • “eval”

For example, type=”beta eval” or type=”eval”. The contents of the license type field are then used by your application to put your software into the appropriate mode of limited operation or usability.