6.2.2.5.1 Types of Licenses

While there is a single format for the LICENSE line, the licenses you receive from your software suppliers can have many different meanings. The following licensing attributes are present in all licenses, and define the major meaning of the license itself:

  • Locking (Workstation): Node-locked (counted or uncounted), 
Username-locked (counted or uncounted), or Floating (Network) licenses.

    RLM can lock a license in a variety of ways:

    • A license can be node-locked. A node-locked license can only be used on a single node, as specified by the hostid of the license.
    • A node-locked license can be either counted, uncounted, or single. If it is uncounted or single, then the software only need verify that it is executing on the correct computer, and no license server is required. If it is counted, however, a license server is required to maintain a count of licenses currently in use (Note that single licenses are checked locally to ensure that only one instance is running).
    • To create a node-locked license, add the keyword hostid=.. at the end of the license line. See LICENSE Line for more information.
    • A license can be locked to a user. This is a special case of a node-locked license and is accomplished using the hostid user=.... Note that any white space in a username is converted to the underscore ('_') character.
    • A license can be floating. This license will work anywhere on the network that can communicate with the license server. To specify a floating license, do not put a hostid= keyword on the license.
  • Expiration: Expiring or non-expiring licenses

    All licenses have a expiration date. If the license uses the special expiration date of permanent, they never expire (any date with a year of 0 is also non-expiring, e.g. 1-jan-0).

  • Version: By version number or by product release date

    Each RLM license has a version number, of the form “major.minor”. The version in the rlm_checkout() call must be less than or equal to the version in the license for the checkout to succeed. (Note: This comparison is done in the “normal” way, i.e., 1.2 is greater than 1.10).

    The version can be used in a number of ways:

    • Your ISV could make all your software request version 1.0 with all your licenses issued for version 1.0, and the version would never be an issue, unless and until they wanted to obsolete all the old licenses on a new release.
    • Or, your ISV could put the product's version number in the rlm_checkout() call, then licenses for an older version of the product will not work with a newer version of the product.
    • Or, your ISV can use a date-based version. To do this, they might put the year of release into the rlm_checkout() call, then when you issue licenses, issue them either for this year, or some year in the future. This allows you, the customer, to use products released on or before the year in the license. Alternately, the ISV could make the version be “year.month.”
  • License Count:

    Each license has a count of available licenses. If this count is “0” or “uncounted,” the license count is not enforced. Otherwise, only the specified number of license checkouts are allowed.