When do I need the RLM License Server?

The Reprise License Manager product is capable of supporting many license types. Some are appropriate for standalone, single-user licensing models and others are used to support more complex network licensing and pricing scenarios. Determining when a license server must be installed is not always clear.

So, let's spend a few minutes talking about the various jobs a license server performs, and when it is needed to support various license types.

Uncounted v. Counted Licenses

The biggest factor that determines whether a license server is required is whether licenses are counted or uncounted.  Counted licenses require a license server because it must "count" concurrent licenses. Counted licenses are used whenever the ISV wants to limit or record concurrent license usage. Counted licenses can be identified by a positive integer in the "count" field of the license.

Uncounted licenses, on the other hand, do not require a license server because there is no need to count usage. Uncounted licenses can be identified by the word "uncounted" or or the number "0" in the license count field of the license. Each uncounted license must be node-locked to a hostid. For ease of administration at larger sites, uncounted licenses for multiple computers may reside in a license file that is managed by a central license server, but this is not required.

The other license type that does not require a license server is the "single" license type. This is also a node-locked license, but it can be used by only one user at a time (concurrent count of "1"). The enforcement of "single" licenses is done via file locking, not by license servers.

The RLM License Server

The basic job of the RLM License Server is to service license requests from RLM-enabled client applications over the network. Based on the needs of the application, the license server redirects license requests to the ISV-specific license server which actually grants or denies the request based on what is specified in the license and on the current usage conditions.

License servers also manage "roaming," named-user, and token-based licenses. They manage held and shared licenses, and offer an admin interface, diagnostic tools, and are responsible for writing debug and report logs.

Licensing Mobile Users with RLM

Using Dongles with RLM

Supporting dongles with the Reprise License Manager

The Reprise License Manager (RLM) comes with built-in USB dongle support.  That means that dongles purchased from Reprise can be used as a standard "hostid" to which licenses can be locked.  The principal advantage of using dongles is to provide a convenient way for your customers to transfer licenses when machines are replaced or upgraded. Software applications, with a valid license, can be used on any machine as long as the dongle specified in the license is attached.

ISV-Defined Hostids

ISVs who prefer to support their own dongles with RLM can do so by way of an ISV-defined host ID.  ISVs can choose a simple, low-cost dongle because RLM needs only the dongle's serial number at runtime. ISVs then write a routine to retrieve the dongle's ID and include that routine within the RLM libraries so whenever a license is tied to the dongle, RLM knows how to call the ISV's routine to obtain the dongle serial number. Example code is provided with the standard RLM SDK to show how ISV-defined hostids can be integrated into RLM.

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.

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.

Licensing by Longitude

Can you gain by restricting your software licenses to certain regions of the globe?

Independent software vendors (ISVs) are often reminded of how interconnected their customers are. For instance, they may receive a support call from someone in India using a license on a server in Indiana.

Depending on the ISV, this may not be the original intent of the license. For a variety of reasons, some some them wish to restrict usage to the location into which the license is sold.

Why restrict by location?

The primary reason to restrict licenses to certain geographies is to try to maintain price discipline across territories and to provide lower price points for more tightly bound licenses. For instance, ISVs who sell to large multi-national customers may want to encourage regional use of licenses with lower per-seat prices, and charge a premium for licenses that span the globe. Also, ISVs who sell through a reseller channel may want licenses to be deployed locally in order to avoid unproductive price competition between regions.

Creating Geo-Aware Licenses

With the Reprise License Manager (RLM), licenses can be generated to restrict the timezones within which the licenses can be used. The mechanism is relatively straightforward. Simply add the keyword TIMEZONE=timezone-spec to any license.

The value assigned to the TIMEZONE keyword is a bitmap representing the client's time zones, relative to GMT, within which the licenses are valid. In other words, it allows the specification of a set of valid timezones for the client machine that performs the license checkout. The timezone-spec is a 24-bit HEX number, with one bit set for each timezone you wish to be valid. Bit 0 represents GMT and each bit to the "left" of bit 0 represents one timezone (one hour) west of GMT. Thus bit 5 would be EST, bit 8 would be PST, bit 23 would be one hour east of GMT, and so on.

TIMEZONE Keyword Examples:

North America (GMT-5 through GMT-8): 0000 0000 0000 0001 1110 0000, TIMEZONE=1E0

Europe (GMT-0 through GMT+2): 1100 0000 0000 0000 0000 0001, TIMEZONE=c000001

Japan (GMT+9): 0000 0000 1000 0000 0000 0000, TIMEZONE=8000

Hold on to that License

Using RLM keywords "HOLD=" and "MIN_CHECKOUT="

Many valuable software tools that require floating licensing run for only a short time.  These include various solvers, development and design tools, and other specialty software products that are designed to perform very specific tasks very quickly.  Unlike typical interactive or desktop applications, these short-burst applications typically do not have a GUI of there own, and are often launched by other applications within a product suite.

The "Short Duration" Licensing Challenge
The licensing challenge for these applications is based on the fact that a floating license is a shared license.  When a floating license is used it is unavailable until it is returned.  But, short duration tools consume licenses for only a short time, so a single license could potentially be shared by a large number of users.

The "Short Duration" Pricing Challenge
The licensing challenge is really a pricing challenge.  In other words, how do you set a price for a single floating license that is low enough for small sites to afford while at the same time scaling your pricing so that larger sites that use more of your software pay you more for that use?  How do you prevent large sites from satisfying their requirements by licensing only a single floating copy of your software?

Extra Hold Time: HOLD=
One way to handle this problem is to implement an extra "hold time" on the floating license.  This instructs the license servers to hold the license for an extra number of seconds after it is released by the client, regardless of how long the license was actually used.  So, for example, if the application uses the license for 20 seconds, upon termination of the program the license is "held" for an additional 300 seconds, say, for a total of 320 seconds.  The effect is that the floating license can be shared by fewer users because it is "held" this extra amount of  time each time it is used.  This encourages customers to order more licenses to satisfy their user population.  But, some customers may object to the license being unavailable for such a long time.

Minimum Checkout Time: MIN_CHECKOUT=
Another similar method is to enforce a "minimum" license checkout duration.  Instead of extra time being added to the end of a licensing session as in the above example, a license would be held for at least a specified minimum amount of time.  So, a license with the minimum checkout time set to 300 seconds would add 280 extra seconds to a license that was in use for only 20 seconds.  Licenses used for more than 300 seconds would not be affected.

Both "extra hold time" (HOLD=) and "minimum checkout time" (MIN_CHECKOUT=) keywords are specified in the license file, external to the application, so that the same executable can use either method without modification to the source code.

Stayin’ Alive, Stayin’ Alive

Heartbeats play a vital role in software licensing

Heartbeats are messages sent from a licensed application to the license server while the application has one or more licenses checked out from the server. The license server acknowledges the receipt of each heartbeat by sending a message back to the application. In this way, each side can know that the other side is up, running, and healthy, or take appropriate action if the other side is not healthy.

Heartbeat messages ensure that the license server has an accurate count of the number of concurrent client licenses in use.

When to use Heartbeats

Not all licensed applications use heartbeats, and by default they don’t. The application developer must make specific RLM functions calls to make use of heartbeats. Typically short duty cycle applications – those that run only for a short period of time, like compilers – don’t use heartbeats. It would be pointless to use heartbeats in an application whose duty cycle is on the order of a couple of minutes or less.

Note that if a licensed application (client) crashes or exits without checking in its licenses, the license server detects this and returns any licenses used by the crashed or exited application to the pool of available licenses. However, if the client operating system crashes or the network between them is segmented, the server is unaware of this and the client’s licenses remain checked out until the server times the licenses out or human intervention is taken.

The ISV server keeps track of how long it has been since it has received a heartbeat from each client. The end user can set up a TIMEOUT (per product) or TIMEOUTALL (all products) in the ISV options file. For each client with a license checked out, if the server hasn’t received a heartbeat within the specified interval, it decides that the client is no longer active, and returns its license(s) to the available pool. By default the ISV server doesn’t have any timeout. The ISV may specify on a per-license basis the minimum timeout that may be specified iby the end user. This is done with the “min_timeout=n” optional license attribute.

If a TIMEOUT interval is set too low and an active client’s license is returned to the available pool, an appropriately-coded client will attempt to reacquire the license without interruption of service.

Using Heartbeats in the Client

The licensed application developer has the choice between using automatic heartbeats, manual heartbeats, or no heartbeats at all (the default). With automatic heartbeats, RLM creates a thread to perform the sending of heartbeats and tracking of responses. With manual heartbeats, the client calls an RLM function periodically which checks for the acknowledgment of the previous heartbeat and sends another one. Automatic heartbeats are a good choice where the application can afford for RLM to create a thread. Where the application needs all available threads for itself, manual heartbeats are the logical choice.