From License Models

License Models and techniques to license your software.

Using Dongles with RLM

Using dongles with RLM

The Reprise License Manager (RLM) comes with built-in USB dongle support, meaning that using dongles with RLM could not be easier.  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.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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″

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website

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.

Help for RLM license administration

- view the RLM License Administration Manual here
- Visit our license administration help page here

Written by Reprise Software - Visit Website