1    License Management Facility

When every computer system was a single processor, and software products were dedicated to that processor, managing software licenses was relatively simple and straightforward. In a distributed computing environment, system managers face more complexity.

Distributed computing allows a much wider variation in software use than a single processor. Software might be used systemwide, or by just a few users. Who uses software and where it can be used might change depending upon the computer environment.

Because managing software licenses is becoming more complex, the License Mangement Facility (LMF) is employed. LMF is a set of software tools that help you manage software licenses. If a software product has LMF support, LMF also verifies that the use of the product complies with its license.

This chapter introduces LMF by answering the following questions:

1.1    What Is LMF?

The License Management Facility (LMF) is part of the Tru64 UNIX operating system and consists of the following:

When you buy a software product you are issued a license to use the product. The license is described by the PAK you receive. You must enter the license information on the PAK into the license database by using the lmf utility. This process is called registering a license.

Once you have registered a license, you use the lmf utility to load the license into the kernel cache. In doing so, you make the license information available to the LMF's license-checking functions.

Each time a user attempts to run a product that includes LMF support, the product calls the license-checking functions. The license-checking functions check the kernel cache to be sure that the license allows the user to use the product. The license-checking functions allow the user to run the product when the kernel cache contains a sufficient number of license units. For more information about how LMF checks licenses, see Section 1.6.

1.2    Your Responsibility in License Management

When you buy software, the vendor from which you purchase the software issues an agreement called a license. A software license can involve a rental agreement and other complex arrangements. Although the term license can have specific legal meanings, for the purposes of this manual, license refers to the authorization you have to use a product.

The License Management Facility (LMF) exists to help you with the task of license management. However, the responsibility remains with your organization for using the tools in a way that fulfills your record-keeping obligations, and for ensuring that your company honors all license terms.

1.3    Products Affected by LMF

Software products are in two general categories:

Not all software products have LMF support. If the license you receive for a product is not in the form of a PAK, that product does not support LMF. If the license is a PAK, the product supports LMF, and you must register it in the license database. Refer to the product documentation for specific information about its support for LMF.ž .\"LMF is designed to be used by companies other than Digital. Ÿž .\"Other companies can issue PAKs (or have Digital issue them on their behalf) Ÿž .\"and include license-checking functions in their software. Ÿž .\"For clarity, this manual addresses software that is Ÿ

1.4    Types of Software Licenses

When you buy a software product, the software seller issues you a license to use that software. Two main types of licenses are issued for software products that have LMF support. Most products are licensed by either an availability license or an activity license.

The Availability Table Code field and the Activity Table Code field on your PAK determine whether you have an availability license or an activity license. If your license is an availability license, your PAK contains data in the Availability Table Code field and the Activity Table Code field is blank. If your license is an activity license, the PAK contains data in the Activity Table Code field and the Availability Table Code field is blank.

The sections that follow explain how availability licenses and activity licenses limit a user's access to software.

1.4.1    Availability Licenses

Availability licenses (also called capacity licenses) give users unlimited access to a product once its license has been registered and loaded on a particular processor. This type of license allows you to run a product only on certain, specified processors.

Suppose you have two standalone systems, SMALLSYS and BIGSYS. The SMALLSYS system requires a 400-unit license to run a particular product. BIGSYS is a more powerful processor, so it requires a 700-unit license. Once a product is registered and loaded on SMALLSYS or BIGSYS, any number of users can run the product.

Now suppose that you must shut down the BIGSYS system to upgrade its memory. When you shut down the system, you want to move the products it runs to the SMALLSYS system, so the products are still available to users.

You can move the products that run on the BIGSYS system to SMALLSYS. The licenses for the BIGSYS products must be at least 700-unit licenses. Each product on SMALLSYS requires only 400-unit licenses. Because all the products that run on the BIGSYS system have licenses that are larger than than 400-unit licenses, you can run those products on the SMALLSYS system. (You use the issue command, described in Section 2.7, to move the license.)

On the other hand, suppose you must shut down the SMALLSYS system for a memory upgrade. You cannot necessarily move the products that run on the SMALLSYS system to the BIGSYS system. The licenses for SMALLSYS products must be at least 400-unit licenses. Each product on BIGSYS requires at least a 700-unit license. You cannot run any product with a 400-unit license on BIGSYS. (Some licenses running on the SMALLSYS system might be at least 700-unit licenses; these products you could move to the BIGSYS system.)

When a product has a license that has too few license units to run on a particular processor, you might be able to increase the number of license units. When the license PAK contains the MOD_UNITS Key Option, you can use the lmf utility's modify command to increase the number of license units, as described in Section 2.10.1. If the PAK does not have the MOD_UNITS Key Option, contact your support representative, who will probably recommend one of the following:

1.4.2    Activity Licenses

Activity licenses (also called per-user licenses) limit the number of users who can use a product simultaneously. An activity license might allow as few as one user to run a product or as many as several hundred users to run a product at one time. (In this context, user refers to a process, not necessarily a person.)

The number of users who can run a product at the same time is controlled by the number of units for the license. A 400-unit license allows fewer users to run a product than a product with a 700-unit license.

The number of users who can run a product also depends upon the processor on which the product runs. Each processor requires a certain number of license units for each user to run a process. For example, a processor might require 25 license units per user.

Suppose you have two standalone processors. The SMALLSYS requires 25 license units per user to authorize a product, and the BIGSYS requires 50 license units per user to authorize a product.

If you obtain a 1200-unit activity license for BIGSYS, you temporarily can move that license (using the issue command) to SMALLSYS when you shut down BIGSYS for maintenance. The 1200-unit license, which allowed 24 users to run the product on BIGSYS, allows 48 users to run the product on SMALLSYS.

You can move a 40-user, 1000-unit activity license originally intended for SMALLSYS to BIGSYS. However, on BIGSYS, the license allows access to only 20 users.

If you need more activity units for a license and your license PAK contains the MOD_UNITS Key Option, you can increase the number of units on the license by using the lmf utility's modify command. If the PAK does not have the MOD_UNITS Key Option, contact your support representative, who will probably recommend one of the following:

1.5    License Product Authorization Keys

A License Product Authorization Key (PAK) is a unique set of data used by LMF to confirm that a product is licensed.

The PAK is issued to you when you purchase a software license. It is a valuable proof of purchase, represents your license to use a software product, and should be stored in your files. The license information in a PAK is confidential and should not be publicly posted or widely distributed. To comply with the license terms, you always must register a PAK in the license database.

1.5.1    Obtaining a PAK

You obtain both a PAK and the product from the representative who distributes software. You order a PAK just as you might order another product. Before you order a PAK, define your software and hardware requirements to your sales representative so that you get a license of the correct size. You usually will receive a PAK printed on a piece of paper when you buy the software.

1.5.2    Product Authorization Amendments

Although they are not used currently, Product Authorization Amendments (PAAMs) may be issued in the future. A PAAM is similar to a license PAK but includes only the data needed to identify, update, and further authorize product use. For example, you might receive a PAAM if you want to increase the number of units for a license that does not have the MOD_UNITS Key Option. The license for the product should be updated using the amend command, as described in Section 2.10.2.

Note

The current business policy is to not issue PAAMs.

1.5.3    Information on a License PAK

This section describes the information contained in the fields on the PAK. Example 1-1 shows a typical PAK. When you register the PAK in the license database, the lmf utility displays a Comments field that you can use as needed. For information about how to register a PAK, see Section 2.2.

Example 1-1:  Sample License PAK Fields

*************************************************************************
 
                   ISSUER:         DEC [1]
 
     AUTHORIZATION NUMBER:         AWS-PK-88229-2 [2]
             PRODUCT NAME:         ALLSUM [3]
                 PRODUCER:         DEC [4]
          NUMBER OF UNITS:         1200 [5]
                  VERSION:        Version 2.0 [6]
     PRODUCT RELEASE DATE:         1-JUL-1993 [7]
     KEY TERMINATION DATE: [8]
  AVAILABILITY TABLE CODE:         M [9]
      ACTIVITY TABLE CODE: [10]
              KEY OPTIONS: [11]
 
            PRODUCT TOKEN: [12]
             HARDWARE I.D: [13]
                 CHECKSUM:         1-ODKM-NIIO-JEPJ-FCLB [14]
 
*************************************************************************
 

The following list describes the fields on the PAK shown in Example 1-1:

  1. The issuer is the LMF name for the entity that supplies the PAK. Most licenses specify DEC. However, PAK issuers might further be identified by region or department within the company. For example, the PAK issuer string could be DEC-USA or DEC-EUROPE. Other software vendors with products that have support for LMF might also issue PAKs. [Return to example]

  2. The authorization number, together with the issuer, uniquely identifies each license. You can use the number for reconciling your records. This number allows everyone to know, with certainty, which license is being referenced. [Return to example]

  3. The product name is the name used by LMF to distinguish among different software products. The product name that appears on the PAK might be slightly different from the name in the Software Product Description (SPD). This difference is due to field length restrictions imposed by LMF. [Return to example]

  4. The producer is the name of the company producing the software. For all software produced by Compaq, the producer name is DEC. The Producer field is used by LMF to distinguish between products with the same name that are produced by different companies. For example, you might have two FORTRAN compilers, one produced by Compaq and one produced by another company. [Return to example]

  5. The Number of Units field shows how many license units are supplied with the PAK. If this field contains a zero ( 0 ), the license has unlimited size. The license allows unlimited use of the product on any type of processor. [Return to example]

  6. The Version field restricts the use of the PAK to particular versions of a product. This field is not used on all PAKs. For example, if the version number on the PAK is 2.0, the PAK can be used with all versions of the product up to and including Version 2.0.

    PAKs are not issued that specify both a version number and a product release date. PAKs might be issued that are not restricted by version number or product release date. [Return to example]

  7. The Product Release Date field restricts the use of the PAK to versions of the product released before a certain date. This field is not used on all PAKs.

    PAKs are not issued that specify both a version number and a product release date. PAKs might be issued that are not restricted by version number or product release date. [Return to example]

  8. The key termination date controls when the PAK expires. After this date, the PAK no longer represents a valid license for the product. [Return to example]

  9. The availability table code represents the number of units required to give unlimited use of a product on a particular hardware system model. This field contains either a letter or CONSTANT=integer.

    A letter represents the License Unit Requirement Table (LURT). The LURT defines the number of units required for the product to run on each hardware system model. The LURT is internal to LMF; you cannot display or modify it.

    If the field contains CONSTANT=integer, the integer defines how many units the product requires to run, regardless of which hardware system model you have. If your PAK has an availability table code with, for example, CONSTANT=100, it means that the product needs 100 units to run on any hardware system model, regardless of size. [Return to example]

  10. The activity table code represents the number of units required for each simultaneous user of the product. This field contains either a letter or CONSTANT=integer.

    A letter represents the LURT. The LURT defines the number of units required for each simultaneous user to run the product on a particular hardware system model. The LURT is internal to LMF; you cannot display or modify it.

    If the field contains CONSTANT=integer, the integer defines how many units the product requires for each user, regardless of the hardware system model you have. If your PAK has an activity table code with, for example, CONSTANT=25, it means that each simultaneous user of the product needs 25 units to run the product on any type of processor, regardless of size. [Return to example]

  11. The Key Options field might contain one of the following options:

    [Return to example]

  12. The Product Token field is not currently used by LMF. However, you must enter any data that is included in this field when you register the PAK. Otherwise, you receive an error message. [Return to example]

  13. The Hardware I.D. field is not currently used by LMF. However, you must enter any data that is included in this field when you register the PAK. Otherwise, you receive an error message. [Return to example]

  14. The Checksum field shows a checksum that has been generated from the individual data elements on the PAK. The checksum is unique for each PAK. After you have entered the PAK data into the license database, the checksum is calculated to determine that you have entered the information correctly. [Return to example]

1.6    License Checking Performed by LMF

LMF performs license checking for availability licenses and activity licenses. The type of checking performed depends upon the type of license you have.

If you have an a vailability license, LMF checks the license when it loads the license into the kernel cache from the license database. The license-checking functions check the license each time a user attempts to run the product.

If you have an activity license, LMF does not check the license when it loads the product into the kernel cache. However, the license-checking functions verify that each user is allowed to use the product when the user attempts to run the product. The license-checking functions might also check the license at other times while the user is using the product. For example, if the user creates a subprocess, the license-checking functions verify that enough license units are available for the subprocess to run the product.

This section explains the steps LMF performs to check licenses for availability-licensed products and activity-licensed products.

1.6.1    Checking Availability-Licensed Products

A valid availability license makes a product available to all the users on a system. LMF allows a user to run a product if the number of units on the license matches or exceeds the license unit requirement for the current processor. Availability licenses are checked as follows:

These two activities are described in the following paragraphs.

1.6.1.1    Loading a License into the Kernel Cache

When LMF loads an availability license from the license database into the kernel cache, it verifies that the license supplies enough license units to run on the current hardware system model. LMF uses the Availability Table Code field on the PAK to determine how many license units a product needs to run on the current hardware system model. Depending upon the contents of the field, LMF performs the following license checking:

Suppose you buy a fictional product named ALLSUM. The PAK you receive specifies the letter M in the Availability Table Code field. The PAK specifies 1200 license units in the Number of Units field.

Suppose you register the 1200-unit license and attempt to load it on a system named SMALLSYS. When you attempt to load the license, LMF checks the Availability Table Code field. When it finds the letter M, LMF determines the model of SMALLSYS's hardware. LMF looks in the LURT M for SMALLSYS's model. Suppose the table indicates that SMALLSYS requires 1000 license units to run a product. Because your license has 1200 license units, LMF loads the product into the kernel cache.

However, suppose you register and attempt to load the same license on a system named BIGSYS. Suppose this processor requires 1500 license units to load a product. In this case, LMF does not load the product (because the license is 300 license units short of the requirement).

1.6.1.2    Running the Licensed Software

Each time a user attempts to run an availability-licensed product, the license-checking functions in the product check the kernel cache for a valid license for the product. The functions perform the following license checks when a user attempts to run a product:

The license-checking functions do not check the number of license units for the product because any number of users can run availability-licensed products. LMF checks that the PAK has enough license units to run the product when it loads the license for the availability-licensed product into the kernel cache.

If a user attempts to run an availability-licensed product that does not have a valid license in the kernel cache, the product displays an error message and does not allow the user to run it. For details about how each product responds to an invalid license, see the documentation for the product.

1.6.2    Checking Activity-Licensed Products

An activity license defines the number of license units each user of a product needs to run the product. Activity licenses can have access to only a few simultaneous product users or to hundreds of simultaneous product users. The number of users depends upon how many license units the license has and how many license units each user needs to run the product on a particular processor.

The number of license units each user needs is defined when LMF loads the license into the kernel cache. The license-checking functions check the license each time a user runs the licensed product.

1.6.2.1    Loading a License into the Kernel Cache

When LMF loads an activity license from the license database into the kernel cache, it performs no license checking. LMF loads the license details and the per-user requirement for the license into the kernel cache.

LMF determines the per-user requirement by checking the Activity Table Code field on the PAK. Depending upon the contents of the field, LMF defines the per-user requirement as follows:

1.6.2.2    Running the Licensed Software

Each time a user attempts to run an activity-licensed product, the license-checking functions in the product check the kernel cache for a valid license for the product. (In this context, "user" refers to a process, not necessarily a person.) These functions perform the following checks when a user attempts to run a product:

If a user attempts to run an activity-licensed product that does not have a valid license in the kernel cache, the product usually displays an error message and does not allow the user to run it. For details about how each product responds to an invalid license, see the documentation for the product.

Suppose you have registered and loaded a license for a fictional product named ALLSUM. Suppose that on the current processor, the per-user license unit requirement is 25. Each time a user invokes a product, 25 license units must be available on the system. Suppose also that your license for a product has 1200 license units.

In this case, when the first user invokes the product, the license-checking function allocates 25 of the 1200 available license units to that user. As long as the first user is using the product, those 25 units remain allocated, leaving 1175 available in the kernel cache for other users.

When the next user attempts to use the product, the checking function repeats the authorization procedure again. Thus, when the second user invokes ALLSUM, the checking function looks for 25 available license units to authorize product use. Because the ALLSUM license now has 1175 license units unallocated in the kernel cache, the license-checking function again authorizes product use.

In this example, the first 48 concurrent users can run the product, but additional users are denied access.

As each user finishes using the product, the license units allocated to that user become available again.