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, Digital employs the License Mangement Facility (LMF). 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:

• What is LMF? (See Section 1.1.)

• What is your responsibility in license mangement? (See Section 1.2.)

• What software is affected by LMF? (See Section 1.3.)

• What types of software licenses are available? (See Section 1.4.)

• What are the contents of a Product Authorization Key (PAK)? (See Section 1.5.)

• How does LMF verify product use? (See Section 1.6.)

1.1    What Is LMF?

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

• A License Product Authorization Key (PAK)

  A PAK is a set of license information, such as the name and version number of the product, the product release date, the date after which the license expires (if any), and the amount of use allowed by the license. The PAK is your proof of license, and it should be stored in your files for future reference. For more information about PAKs, see Section 1.5.

• The license database

  The license database stores information about all the licenses registered on your system. LMF creates the license database the first time you register a license.

• The license management utility, lmf

  The lmf utility has commands that allow you to register, load, and maintain licenses on your system. For information about using the lmf utility, see Chapter 2, or the lmf(8) reference page.

• The license management script, lmfsetup

  The lmfsetup script includes an alternative to the lmf utility for registering licenses. For more information about lmfsetup, see the lmfsetup(8) reference page.

• License-checking functions

  License-checking functions are included in each product that has LMF support. They verify that potential users of a product have a valid license to use it.

• License Unit Requirement Tables

  License Unit Requirement Tables (LURTs) specify how many license units you need to run a product on a particular model of Digital hardware. Different models of hardware require a different number of license units to allow a product to run. In general, the more powerful your hardware is, the more license units you need to run a product.

  The license unit is a measure of software use defined by Digital.

  The License Unit Requirement Tables are internal to LMF. You cannot display or modify them.

When you buy a product from Digital, the company issues you 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 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

Digital Equipment Corporation's software products fall into two general categories:

• Software that does not support LMF

  These software products do not use LMF to authorize software use. License information is issued separate from the software.

• Software that supports LMF

  License information is issued on a PAK that must be registered in the license database. These software products contain the LMF license-checking functions that verify your use of a particular software product.

Only software products released after DEC OSF/1 Version 1.2 can support LMF. Prior to Version 1.2, the DEC OSF/1 operating system did not contain the LMF software to authorize the use of products.

Not all software products that run on DEC OSF/1 Version 1.2 (or later) systems 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.

1.4    Types of Software Licenses

When you buy a software product, the software seller issues you a license to use that software. Digital Equipment Corporation issues two main types of licenses for the Digital UNIX 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 a Digital representative, who will probably recommend one of the following:

• A new license that has sufficient license units for the new processor

• Another license for the same product that has additional license units

  If the terms of your license allow it, you can register the two licenses for the same product and combine them to form one larger license. For a complete explanation of license combination, see Section 2.11.

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 a productwith 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 can temporarily 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 a Digital representative, who will probably recommend one of the following:

• A new license with more units

• Another license for the same product that has additional license units

  If the terms of your license allow it, you can register two or more licenses for the same product and combine them to form one larger license. For a complete explanation of license combination, see Section 2.11.

• A different kind of license

  Because some products offer both activity and availability licenses, the representative might suggest changing to an availability license.

1.5    License Product Authorization Keys

A License Product Authorization Key (PAK) is a unique set of data generated by Digital and 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 from Digital 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 Digital's license terms, you must always register a PAK in the license database.

1.5.1    Obtaining a PAK

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

1.5.2    Product Authorization Amendments

Although it does not now do so, Digital might issue Product Authorization Amendments (PAAMs). 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

Digital's 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, Digital might further identify PAK issuers 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, both for you and for Digital. You can use the number for reconciling your records with Digital. 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 Digital, 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 Digital 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.

   Digital does not issue PAKs that specify both a version number and a product release date. Digital might issue PAKs 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.

   Digital does not issue PAKs that specify both a version number and a product release date. Digital might issue some PAKs 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:

    • ALPHA

      The ALPHA Key Option indicates that this license is valid only on the Alpha AXP family of systems.

    • MOD_UNITS

      The MOD_UNITS Key Option indicates that you are allowed to modify the Number of Units field (using the modify command). For a complete description of how to modify the Number of Units field, see Section 2.10.1.

    • NO_SHARE

      The NO_SHARE Key Option indicates that you cannot combine two or more licenses for the product on the same processor.

    • P_FAMILY

      Some licenses might have the P_FAMILY Key Option in this field. However, LMF allocates license units to each executing process for the product, even if several processes belong to the same user.

      Note

      The P_FAMILY Key Option is not valid for DEC OSF/1 licenses.

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 availability 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:

• By LMF when the license details are loaded into the kernel cache from the license database

• By the license-checking functions in the product when a user attempts to run the licensed software

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:

• The field contains CONSTANT=0.

  LMF performs no further checking. This license allows the product to run on any processor. LMF loads the license into the kernel cache.

• The field contains CONSTANT=integer.

  LMF defines the number of license units required to be integer. To run on any processor, the license must have at least integer license units.

  LMF compares the value specified in the Number of Units field on the PAK to integer. If the value is equal to or greater than integer, LMF loads the license into the kernel cache. If the value is less than integer, LMF issues an error message and does not load the license.

• The fields contains a letter, such as M.

  The letter corresponds to a LURT that LMF uses internally. Each LURT contains a list of hardware system models and their corresponding license unit requirements. For example, a LURT might specify that one hardware model requires 1000 license units, while another, more powerful system requires 1500 license units.

  To check the license, LMF determines the hardware system model of the current processor. It then looks at the M LURT to determine the requirements of the hardware system model. Once it has determined the license unit requirement for the current hardware system, LMF compares the requirement to the value in the Number of Units field on the PAK. If the value is equal to or greater than the license unit requirement, LMF loads the license into the kernel cache. If the value is less than the license unit requirement, LMF issues an error message and does not load the license.

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 software has the same product name and producer name as those on the license.

• The version number of the software is not greater than the version number (if specified) on the license.

• The product release date of the software is not later than the product release date (if specified) on the license.

• The current date is not later than the key termination date (if specified) on the license.

• The current date is not later than the cancellation date (if specified) on the license.

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:

• The field contains CONSTANT=0.

  LMF defines the per-user license requirement to be zero (0). Any number of users can run this product simultaneously. LMF loads that information into the kernel cache.

• The field contains CONSTANT=integer.

  LMF defines the per-user license requirement to be integer license units. Each user that runs the product requires integer license units. LMF loads that information into the kernel cache.

• The fields contains a letter, such as K.

  The letter corresponds to a LURT that LMF uses internally. Each LURT contains a list of hardware system models and their corresponding per-user license unit requirements. For example, a LURT might specify that one hardware model requires 25 license units per user, while another, more powerful system requires 50 license units per user.

  To define the per-user license unit requirement, LMF determines the hardware system model of the current processor. It then checks the LURT to determine how many per-user license units the processor requires. LMF loads that information into the kernel cache.

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:

• The software has the same product name and producer name as those on the license.

• The version number of the software is not greater than the version number (if specified) on the license.

• The product release date of the software is not later than the product release date (if specified) on the license.

• The current date is not later than the key termination date (if specified) on the license.

• The current date is not later than the cancellation date (if specified) on the license.

• Enough license units are available to meet the per-user license requirement for the product on the current processor.

  If the product has a valid license in the kernel cache, the license-checking function in the product compares the number of units required for each user to the number of units available. If the number of units available matches or exceeds the license unit requirement for the current processor, the user can run the 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.