Think about dropping your home-brew license manager when you need to re-focus your developers on what makes your software great.
Multiple Independent License Servers
A site may have multiple RLM license servers serving the same licenses, either in a failover scenario or when the site has decided to split its complement of licenses for a given product across multiple servers. The licensed applications need to know which hostnames and port numbers the license servers are on. There are several ways in which this can be done:
The licensed application may provide a configuration utility which allows the user to configure multiple license servers.
The environment variables RLM_LICENSE and <isv>_LICENSE may be set to a list of [email protected] values, for example:
- set [email protected];[email protected];[email protected]
- export [email protected]:[email protected]:[email protected]
Note that the separator character is semicolon on Windows and colon on UNIX.
A separate license file can be configured to reference each license server. Each license file need only contain a SERVER line with the appropriate host name and port number – the hostid field is ignored by RLM on the client side.
License File 1:
- SERVER london any 5053
License File 2:
- SERVER newyork any 2234
License File 3:
- SERVER tokyo any 12343
Using “REPLACE =” and “UPGRADE”
Probably the most basic of all licensing policy methodologies is the ability to control the duration of the license with an expiration date in the license. At times, as in demo or trial modes, you may want your licenses to have a short duration, 30 days or so. Still other times, you may sell usage rights on a periodic basis, monthly or annually, requiring a new license to be issued upon renewal.
In many cases however, you want your licenses to be perpetual, with no expiration date. What happens if over time you want to do a radical overhaul of your license policies or you have negotiated a new contract with a customer that requires issuing of new licenses that would replace the existing licenses? Perhaps you issued licenses that were only good for a defined version of your product and now you are upgrading to a newer version. The permanent licenses do not expire so how do you make the necessary changes?
Replacement and Upgrade Licenses to the Rescue
The way to render ineffective one or more licenses which you have already issued is to use the REPLACE[=product-list] option in the new license. REPLACE= causes RLM to ignore the “replaced” or old RLM license(s).
Upgrading licenses to a new version. There are a couple approaches you can take if you are upgrading existing licenses that are valid for a previous version of your software to a new version release. If you are upgrading all instances of the existing licenses to a new version then the REPLACE= option works very effectively.
But, what if you want to upgrade only a subset of the existing licenses to the new version and leave the rest unchanged? The UPGRADE license type was created for this very situation. Using a an UPGRADE license type, you can upgrade a limited number of the existing licenses to a newer version and the remaining licenses will run under the older version. UPGRADE does not grant any new license rights, it only upgrades the specified number of existing licenses to a new version.
“UPGRADE” and “REPLACE=” are specified in the license file, external to the application, with no modification to the source code being necessary.
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
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.
License sharing is used by software vendors to allow multiple concurrent uses of a single license.
Layman's article about the rationale and purpose of heartbeats.
Adding support for license queuing promotes more efficient use of a user’s inventory of licenses
The RLM license server has the ability to manage a queue of requests for a license when all licenses are in use. If queued for a license, the application is notified by the license server when a license has become available. Queuing occurs in the course of a normal checkout if the application’s environment specifies a value for the variable RLM_QUEUE.
Applications must be made aware of Queuing
The licensed application needs to support queuing, in that it has to react appropriately to the RLM_EL_INQUEUE error status after a checkout attempt, instead of treating it as a hard error. The application should keep checking the license status periodically as long as the user wishes to remain queued for the license. Not all RLM-licensed applications do this, but most do.
Queuing to Multiple Servers is Transparent
The licensed application side of RLM manages queuing in a multiple license server environment transparently. If all licenses are in use on all of the license servers that the licensed application is aware of, RLM will queue for a license on all of the license servers. As soon as a license becomes available on one of the servers, it is granted to the queued application, the application dequeues on the other servers. This is handled transparently to the application, in the RLM library. [ Don’t you wish supermarket check-out lines worked this way? You’d be waiting in all of the lines at once. ]
All Aboard the Express
RLM has the concept of “express” license pools for the purposes of queuing. An express license pool is one where queuing is not on a strictly first-in first-out basis. This is best illustrated by example. Consider a pool of 10 licenses: 8 are currently in use, and 2 are available. Application A requests a checkout of 3 licenses, and specifies that it wants to queue if the request can’t be granted immediately. Its request is queued because only 2 licenses are available. Application B then requests 2 licenses. If the pool is an express pool, Application B’s request is granted immediately. In a non-express pool, Application B’s request would be queued behind Application A’s request. By default, all pools are express pools. This can be changed by the end user on a pool by pool basis, or globally, via the EXPRESS directive in the ISV options file.
Software developers will freely admit that they are not licensing experts. When they asked to evaluate, select and implement a software licensing solution they want one that is robust, yet quick to implement and easy to maintain.
RLM end-users remind me of why software license management is so important to them.
by Cody Crider, Reprise Software, Inc.
We have written many articles about the benefits of software licensing to Independent Software Vendors (ISVs) and how to implement various features within RLM. Of course this is the target audience for Reprise Software’s product, right? That might be where we make our living, but there is a whole other world of software licensing that ISVs should examine more closely, from their customers’ perspective.
I recently had the opportunity to make a presentation to a number of end-users of enterprise-class software products that utilize software licensing including the Reprise License Manager (RLM). These end-users represent some of the largest companies in the world. It was very enlightening to hear about software licensing from the perspective of the folks involved in the day-to-day management of hundreds of applications, and thousands of licenses. The special value of software licensing to this end-user community is one that needs to be continually addressed.
There were the discussions about what end-users commonly want, such as the following:
- Better control over when/where/which users can access software assets
- Unfettered access to usage data and tools to track and allocate costs
- Improved license administration tools
- More predictable and consistent licensing models across vendors
- Transparent policy spelled out in the license key
- Auto-maximized license utilization
- Better control over license queuing
- Better performance measurement tools to plan for and deploy new licensed applications
- Better diagnostic tools
- Simpler Internet-based activation and license installation
We had an opportunity to discuss how RLM address many of the needs outlined above and that the majority of the innovations in RLM are in support of better value for end users while simplifying implementation and deployment for ISVs.
The discussion then shifted a bit when the question was asked, “Does RLM do a good job at ensuring software compliance?” Sure, we talk about a benefit of RLM is to ensure that ‘honest users stay honest’, but this is from the perspective of the ISV who wants to maximize revenues by eliminating unlicensed usage. A light came on to remind me that this is also a critical issue for our end-user community. From their perspective, it is one of the benefits they value most from software licensing. Let’s face it. There are a lot of things that end-users don’t like about software licensing, but it is one of the ‘inconveniences’ that they can tolerate for all the extra benefits derived from it.
The software end-user has a management mandate to stay compliant with their software licensing agreements and to have the information they need to prove this during audits. Software compliance can be less costly for these customers if the software they license includes the proper built in license compliance tools, like RLM.
RLM provides the flexible licensing models and features that can match what is being sold to software end-users. ISVs who support license models matching those described in their software licensing agreement can go a long way to help ensure compliance.
RLM provides the administration tools to monitor and support license compliance reporting. The tools are built into RLM so that the end-user can easily control how the software is utilized in their organization and determine who has the rights to use it. RLM provides detailed license usage report logs that can be used to track and monitor usage across the organization. The RLM Reportlog uses an open and authenticated format that can easily be read for reporting purposes. Reprise works closely with 3rd party vendors such as License Tracker, OpeniT, and RunTime Design Automation that provide tools to help maximize the usage and monitoring of software assets.
All of these features and efforts can help assist the end-user community to ensure that they are in compliance with their license agreements.