Reprise Software’s Recommended Software Installation Steps
[Note: This information is in the RLM Reference manual, in the "End-User Installation" chapter, but we felt it was important enough to repeat here.]
Installing your product with RLM should be very straightforward, and should require no configuration of environment variables, etc.
Overview:
On the client side, ie, on the machines where your application is going to run, place the license file in your product hierarchy. For nodelocked licenses, this should be the actual, signed license file, and nothing needs to be done to this license file. For floating, this license file will be used only to locate the license server host.
If you ship floating licenses, install the server binaries and license file on the server node. The server license file doesn't need to be modified.
Nothing in this set of recommendations requires the use of environment variables, and the install-time editing of license files is kept to a minimum (No editing of license files for nodelocked licenses, and only the server hostname needs to be set on the client side for floating licenses).
Details:
During development:
- establish a directory in your installed product tree for license file(s). This could be the same directory where your product is installed.
- Pass the directory from the step above as the first argument to rlm_init().
When you ship a nodelocked license:
- If you are shipping uncounted or single node-locked licenses, put the actual licenses into the license file. Install in the default directory. You're done.
When you ship a floating license:
- If you are shipping floating licenses, use a single HOST line in the license file for the client side. Use the default RLM port (5053) - which means you do not need a port number in this license file, and fill in the hostname with the name of the server computer at installation time. This license file should look like this:
HOST server-hostname
- On the server node, place the rlm binary, your ISVsettings file (or ISV server binary), and the license file in a directory. This license file should have the real, signed licenses. The server hostname in this file can be “localhost”, meaning that it doesn't have to be edited by the end-user. The server license file's first two lines should look like this:
-
- HOST localhost hostid
ISV your-isvname - use the default port (5053)
- use the ISV server settings or binary from the same directory as the rlm binary
By configuring the license file this way, it does not need to be edited by your customer. These lines tell RLM to:
Of course, you would include all your signed LICENSE lines in this file as well.
- Start the rlm server from the directory in the step above
If your customer already has another RLM server running:
- Install your ISV settings or server binary and the license file in the same directory as the other product's copy of the server binaries and license files, and do a “reread” operation on the running rlm. That's it, however:
- If your version of RLM is newer than the installed version, update the installed version to your version, then shut down the running rlm and start the new one.
If you ship new, additional licenses to your customer:
- Put the new license file in the same directory as the old one. If they are nodelocked licenses, put them on the client system. If they are floating licenses, put them into the directory with your other licenses and do an rlmreread on the license server.
Managing Renewable Licenses – A Practical Approach
Using RLM refresh-type activation to support short-term renewable licenses
Consider these licensing system requirements:
- The system must be able to generate a time limited and trial licenses.
- The trial version will automatically become a "full version" when the customer purchases a license.
- Full licenses are also "time limited", i.e. customers can purchase packages of 30, 60, or 90 days.
- Each time the application starts, it must validate that its license has not yet expired.
- The application must be able to operate "off line" for a specified period of time: if the license cannot be reactivated at the expiration of the allowed off-line period, then the license is suspended and the application cannot start.
- Upon first reconnection, if the user still has a valid license (has not been terminated), the license is reactivated, the off-line allowed time is restored and the application can be run again.
Supporting the Concepts
Using the optional RLM add-on product, RLM Activation Pro, a refreshable license is one that is intended to be reactivated frequently and receive a license with a new expiration date with each reactivation. Refreshable licenses are typically of short duration (days). The ISV is assured that the maximum period during which the end user can run the licensed application is the duration of the refreshable license, say 30 days.
For example, if the ISV specifies a 30-day refreshable license, then the license will be good for 30-days after each activation. If the refresh operation fails for any reason, such as the lack of Internet connectivity, then the license is still good until the end of the 30 day period - enough time to resolve any connectivity issues. This allows the customer to operate off-line until the license needs to be refreshed.
Refreshable licenses also give the ISV a way to revoke a license should that user fail to meet contractual obligations, for example. The ISV can simply disable the user's license on the activation server, and refresh attempts of that license will fail from that point forward, or until it is re-enabled by the ISV.
The client side of refreshing can be automated, so it can be performed without an undue burden on the end-user. Reprise supplies a "Refresh API" for license refreshing, which the ISV can use from within the application itself, or within a separate standalone utility. Reprise supplies a generic refresh utility that can be supplied to the end-user by the ISV. The generic utility, "refresh_util", is meant to be set up to run daily as a scheduled task.
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
The 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
or
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.
Licensing a multi-featured product with RLM
Recently we received a common question from one of our customers looking for some advice.
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.
Integrating the Reprise License Manager (RLM) with Salesforce.com
Several customers have recently asked us if any software vendors who use RLM for licensing have extended Salesforce.com 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 Salesforce.com.
Here's a quick summary of what one of our customers does:
- create a new sale in Salesforce.com
- 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 Salesforce.com
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.
Tips for Multi-Server Site Configurations
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 port@host values, for example:
- set RLM_LICENSE=5053@server1;5053@server2;5053@server3
- export reprise_LICENSE=5053@london:2234@newyork:12343@tokyo
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.
Example:
License File 1:
- SERVER london any 5053
License File 2:
- SERVER newyork any 2234
License File 3:
- SERVER tokyo any 12343
Top 10 Reasons why Software Developers prefer the Reprise License Manager (RLM)
Who doesn't love a good Top 10 List?
We've talked to a lot of software developers over the years, a lot. We've found that they all have the following complaints in common: over worked, over scheduled, and under appreciated. The current economic slowdown has heightened the need for getting more from less, and no employees feel that added pressure more than highly skilled software developers.
Most developers who are asked to evaluate, select and then implement a software license management solution would freely admit that they are not experts in software licensing. Many have experience with older license managers (mostly unfavorable, otherwise we probably would not be talking to them in the first place), but it's certainly not their specialty. What they want is a software licensing solution that is robust, yet quick to implement and easy to maintain.
Based on these discussions we compiled a list of the Top 10 Reasons why the Reprise License Manager (RLM) is preferred by today's busy software developers.
1. Simple API with clear and concise documentation: The first contact that software developers have with RLM is with the documentation. The manuals are written by developers, for developers. There's no marketing hype, just the technical information to get familiar with the concepts and to start an implementation. The documentation is sprinkled with real-world examples and sample code. The RLM API is simple and streamlined. Once implementations are complete, they are more easily debugged and maintained.
2. Small footprint: Software developers appreciate that they can retain their own "look-and-feel." RLM does not impose any style of its own. It tries to stay out of the way. Software developers are free to design an interface and installation procedures to reflect their own standards.
3. True cross-platform support: The same API is available on all platforms, in all languages. Developers who write in Java and .Net compatible languages have access to the full breadth of the API as do developers who write in C/C++. Application licensing operates the same regardless of platform and language, saving time with development, testing and deployment.
4. Points for good behavior: Some licensing products require writing into the registry or writing to illegal disk sectors. RLM plays it straight, not even requiring admin privileges to install RLM-based applications. RLM uses plain old TCP/IP to connect clients to the license server. No broadcasts to gum up the user's network.
5. Policy in the license: Software developers can change license policies without changing the code base. RLM is designed so that the application does not need to know what kind of policies are present beforehand. With RLM, license policy is largely removed from the application and defined in the license keys. So, applications request a license, and the license that is granted is based on what type of license is found in the customer's license file. This addresses the ever-changing set of business rules by simply varying the license key issued.
6. Internet connectivity is not required: Relying on getting a software license over the Internet at runtime is risky. RLM licensing does not rely on the Internet. Applications read local license files (digitally signed text files) or connect to a license server that manages concurrent use. There is no forced Internet "phone home" requirement. However, licenses can be optionally obtained over the Internet. License activation over the Internet is merely one way of getting licenses to your customers. Since the license files are merely text files, email is the preferred method for some ISVs.
7. License generation and delivery options: The software developer's job is not over when he is finished integrating software license management into his code. ISVs have to think about how they will generate and manage "software license entitlements." We've found that there is a very wide variation in license generation strategies that ISVs want to employ. So, RLM allows ISVs the maximum amount of flexibility. Licenses can be generated using a license signing utility that works by computing digital signatures for common product license templates. Or, licenses can be constructed using utilities written by the ISV from API calls in the RLM kit. Optionally, a graphical program (RLC) is available to generate licenses for products that are defined in terms of the licenses that enable them.
8. Built-in server admin interface: Software developers rely as much as possible on built-in functionality, none more so than the server administration interface that is pre-wired into the RLM license server. Privileged users point their browser to the server to get status information, and to perform routine server maintenance such as restarts and shutdowns.
9. Built-in diagnostic tools: A rich set of built-in client-side and server-side diagnostics makes the job of troubleshooting easier. Users can easily create useful data sets that help to pinpoint potential license configuration errors.
10. RLM Tech Support comes directly from engineers: When software developers need help, they want to talk to other engineers. At Reprise Software, all support calls are handled by software developers. There is never a maze of inexperienced support techs to wade through that might slow down your development.
RLM was designed and written by software developers with years of experience in this specialized niche, with software developers' time-critical needs in mind.
RLM – A Light Shines
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.
Advanced End User Reprise License Manager (RLM) Administration Tutorial Series
Advanced End User RLM Administration Tutorial Series
Reprise Software continues its series of regular on-line tutorials designed to help users maximize the value of the Reprise License 
Manager (RLM). These sessions are designed for system administrators and ISV tech support people.
This third session will be conducted by Reprise Software's lead software developer, Bob Mearns, who has over 15 years experience developing and supporting license manager software.
The 40-minute session is scheduled for Tuesday October 12th at 8AM PDT (GMT-08). This session will focus on RLM license server administration and optimization in a multi-server environment. It will specifically address:
-
License server administration of multi-server sites
- Connecting to multiple license servers
- Connection and Idle Timeouts
-
Server to Server License Transfers
- License Queuing
- RLM's environment variable settings
For more information about the tutorial series, please contact Mr. Cody Crider at cody@reprisesoftware.com
Search the Blog
Recent Posts
- Activation of a Rehostable license fails with a -148 (NO_REHOST_TOP_DIR) error
- Reprise Software’s Recommended Software Installation Steps
- Failover License Servers – why can’t I have 3?
- Application cannot connect to license server
- My license server won’t start
RSS feed subscription