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.

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.

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.

RLM v9 Addresses Opportunities in “The Cloud”

The Reprise License Manager (RLM) v9 addresses licensing challenges and opportunities presented in the cloud.

Earlier we wrote a short article about this topic, http://www.reprisesoftware.com/blog/2010/01/are-you-ready-for-cloud-computing/ asking “Are you ready for the Cloud?”  RLM v9 now incorporates features to help software vendors exploit these new opportunities.

The biggest industry players are driving the cloud movement. Platform vendors such as Amazon.com, Google, IBM, Microsoft, and Salesforce.com are leveraging their enormous investments in computing hardware and advanced virtualization software to build on-demand computing infrastructures. Corporate users, tired of paying to maintain in-house iron, are increasingly looking to reduce costs with cloud computing, while at the same time simplifying procurement, decreasing acquisition time, and adding unprecedented throughput potential.

Users can obtain “hardware on the fly” to run any operating system on arbitrarily large servers – “in the cloud.” These virtual systems may persist indefinitely or disappear when no longer needed.  The software on them may be used for only a short burst of time – just enough to get the job done – measured in days or even hours.  Likewise, paying for “cloud-time” is easy, often paying with nothing more than a credit card.

The most common problems facing ISVs who use a software license manager to license their applications in the cloud are the following:
– license keys locked to hostids may become invalid between instances,
– license servers used to enforce concurrent or floating licenses are too complex for cloud customers to manage,
– license models that rely on usage records are too hard to retrieve.

The critical technology change in RLM v9 to accommodate cloud-based software deployment is in the ability for software vendors to easily create and manage license server farms. The idea is that ISVs create these farms on their own servers, and run multiple instances of their ISV server within the farm to serve licenses to all customers who are using cloud-based products.

What problems does this solve?

By being able to run multiple license servers on the same computer, an ISV can eliminate the problems mentioned above. Specifically, licenses deployed in the cloud point back to the appropriate license server in the farm, so no local (cloud) hostids need to be checked and the user no longer needs to set up a local license server. Also, since applications deployed in the cloud must contact one of the license servers in the farm, ISVs can easily gather license usage information used to produce periodic post-use invoices for their cloud-based users.

What’s best is that you don’t have to create a separate “cloud-enabled” version of your application. Your off-the-shelf version will work just fine because this solution is a part of RLM’s  the new v9 license server, and is governed by the license keys that you give your customers.

Of course, the value of this new functionality is not limited solely to users in the cloud.  ISVs who want to simplify the deployment of their floating licenses for their traditional customers can set up license server farms for them as well.

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 [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.

Example:

License File 1:

  • SERVER london any 5053

License File 2:

  • SERVER newyork any 2234

License File 3:

  • SERVER tokyo any 12343

Modifying Licenses in the Field

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.

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.