License Use Management

IBM License Use Management: Optional Policies

Vendors can enable their products to implement various policy decisions regarding how licenses are managed.

Vendor Controlled Policies

The vendor can implement the license policies: capacity, try-and-buy, multiuse rules, product wait queues, license annotation, custom configuration, bundle, and product-specific program.

Named User

With this policy, reservable licenses can be reserved and unreserved by the administrator in the same manner as for reservable licences (see "Reservable Licenses" for more information). The major difference is that the named user policy always requires you to reserve a license for a specific user. Also, with the named user policy, when a license is requested, only the central registry server is checked for an existing reservation. No communication occurs between the application and the nodelocked license server. Therefore, if you are using this policy, a nodelocked license server does not need to be installed on the client where this policy is in force.

If the central registry license server allows the license to be granted, the license is granted, but the transaction is not recorded. This allows the administrator to unreserve the license at any time, without waiting for the reservation period to expire.

Capacity

With this policy vendors can comply with the terms and conditions of products that are priced based on certain characteristics of the system on which the product is running, not only on the number of users who are using the product. This includes, for example, the number of processors on which the application can run or the maximum size of the physical memory.

In such cases the vendor can specify a capacity type that defines the unit of measure for the internal counter ("capacity units") associated to the license password. The capacity type is an integer value between 1 and 255; some of these values have a predefined value; others may have any vendor specific meaning.

The predefined capacity types are:

• Online processors
• Configured processors
• Physical disks
• Physical memory (in MB)

When you use one of the predefined capacity types, the License Use Management library embedded in the license application can calculate the number of capacity units that are used by the application itself. In the other cases the vendor must calculate them before passing the results to the License Use Management library. In either case, the license is granted only if the capacity type of the password matches the capacity type specified in the request, and the capacity units are not exceeded. This applies to simple nodelock, concurrent nodelock, and concurrent network license types, under either vendor-managed or customer-managed use control.

Note:

Not all the above capacity types are supported on all the platforms (see Using License Use Management Application Developer's Toolkit).

Value Units

With this policy vendors price their products by assigning a value expressed in units to each resource in an environment. All the different metrics (like usage count, system resources or other product-specific indicators) are defined into the same license certificate, as well as the rules and relative weights for their translation into value units. The value units policy can be applied to concurrent and concurrent nodelocked licenses only, or to server based simple nodelocked licenses. See the table below.

Value units are multiplied by the number of resources in your environment and defined in the enrollment certificate. This policy enables you to change your environment to suit your needs, without exceeding the value units assigned.

Try-and-Buy

The vendor can enable a product with a special simple nodelocked license for customers to use during an evaluation period. The evaluation period (with duration that is set by the vendor) starts either when the product is enrolled or when the product is run for the first time.

Multiuse Rules

Multiuse rules define the conditions under which multiple calls of a product require only a single license. These rules are applicable only to concurrent network, concurrent nodelocked, and per-server licenses.

The vendor can enable a product so that after a license has been granted to a particular user, group, node, job ID, or accessor ID, a second call of the product does not require a second license. An accessor ID is a generic string that the vendor can use to further identify the caller of the license request.

For example, if a user calls a compiler repeatedly, a multiuse rule might specify that the second and subsequent calls do not require additional licenses. Multiuse rules may be based on any combination of the following tests that the server performs when a concurrent license is requested:

• The request for a license is associated with the same user as a previous request.
• The request for a license is associated with the same group as a previous request. The vendor can also change the meaning of the "same group" rule to implement a vendor rule. For example, the vendor might implement a multiuse rule that applies when a request is associated with the same display as a previous request. Vendors can also change the meaning of "same group" in other ways, to implement whatever multiuse rules they design. Any vendor-specific rule overrides the "same group" rule.
• The request for a license is associated with the same node as a previous request (applicable to concurrent licenses only).
• The request for a license is associated with the same job ID as a previous request.
• The request for a license is associated with the same accessor ID as a previous request.

Back to top

Product Wait Queues

Some products with concurrent licenses may use wait queues.

When a user calls such a product, and there are no licenses available, the product can be enabled to ask if the user wants to wait for a license. If the user responds affirmatively, the user is added to the wait queue on each License Use Management Runtime network license server that provides concurrent licenses for the product. User names are added to the wait queue in chronological sequence. When a license becomes available, it is granted to the first user in the queue.

License Annotation

License annotation is data that is defined and included as part of the license information when a license is created. When the license is granted, the data is passed to the enabled application for its own use. Licenses of any type can be annotated.

A typical use of license annotation is to create licenses that correspond to different configurations of the same product. Consider an application that has several optional priced features, all delivered as part of the product package. The vendor can create license annotations to define which options the customer has bought and, therefore, which features are accessible to the end user.

License Annotation File

If the vendor requires more annotation than is available using the 255 characters in the license annotation, the vendor can create an additional license annotation file, and refer to it using the -j parameter of the i4lct tool. The maximum size of the file is 32 KB. This file will be distributed with the ECF and must be present on the system during the enrollment step.

Custom License Attributes

Vendor-specific license attributes can be defined and included as part of the license information when a license is created. When the license is granted, the attribute data is passed to the enabled application. Three general purpose attributes can be used in License Use Management Runtime. These are specified with the -A parameter:

1. Custom attribute 1
2. Custom attribute 2
3. Custom attribute 3

These attributes can be exploited by a vendor to enforce any specific policy. License Use Management Runtime only records the attribute and makes it available to the vendor's application upon request.

Custom Configuration

Vendors who want to offer selected combinations of products, tailored more precisely to the needs of users, can define custom configurations by adding functions and products to a base configuration.

You specify the required content of a custom configuration when you order the configuration. You can order a custom configuration for one seat or for a group of any number of identical seats. If you order a configuration for a block of seats, the quantity of each add-on function or product must equal the number of seats in the block.

Each custom configuration, whether for a single seat or for a block of two or more seats, is assigned a separate custom configuration license. A custom configuration license is a special case of a concurrent network license or a concurrent or simple nodelocked license that contains a unique serial number identifying that custom configuration. The single serial number and license for a block configuration helps you to manage your installed licenses more easily.

After initial installation of a custom configuration, you can better manage the evolution and growth of your configurations, by ordering additional "add-on" functions and products, as necessary. To retain a single serial number and license, however, any changes made to the custom configuration must be applied to all seats under that serial number.

Bundle

Sometimes it may be useful to treat a set of products as a unique entity. By defining bundles, licensing system administrators can manage the licenses referring to products as a unit.

The licensing system administrator can view all the bundles in a licensing system and see the licenses that are in bundles. You cannot delete individual licenses in a bundle, but you can delete the bundle.

Also, it is possible to verify the consistency of a bundle if all the licenses in the bundle have been enrolled.

Products in the bundle are linked by a common serial number, but each product is still represented by its own license password. The custom configuration policy, however, provides a way of bundling in which all the products are represented by a single license.

Product-Specific Program

Vendors who need to perform some product-specific actions at the moment of the license enrollment, can define in the license password the name and path of a program that License Use Management Runtime will run as part of the enrollment process. The product is responsible for the existence of such a program on the workstation where the enrollment takes place. If License Use Management does not find the program, the enrollment fails. This policy is available only for simple nodelock licenses under a non-runtime-based enabling.

Back to top

Customer Controlled Policies

The customer can use the license policies hard stop/soft stop, user access restriction, and the per-server/per-seat switch.

Hard Stop/Soft Stop

The vendor can enable a product so that you can choose the behavior of the product when the end user starts it and no licenses are available.

If no license is available, one of two things can happen:

• The product does not start, and there is no way for the end user to go on (hard stop policy).
• The product starts (soft stop policy).

When you enroll a product enabled for hard stop/soft stop, the default is hard stop. To use soft-stop, you must enable a network license server with the correct option. You can use the basic license tool to change the policy to soft stop and back again.

When the soft stop policy is set, License Use Management Runtime keeps track of the high-water mark. The high-water mark is the maximum number of licenses that are ever granted for a given product beyond the number of licenses that are enrolled for that product. You can see this number through the basic license tool, and you can reset it to 0. Use this number to help you decide the number of additional license keys you need. When the hard stop policy is selected, the number of in-use licenses cannot exceed the number of enrolled licenses, so the high-water mark is not maintained.

While for CMU policies the user can exploit the License Use Management Runtime hard stop/soft stop policy, VMU application vendors can decide to have a soft stop policy that is under the full control of the enabled application itself.

User Access Restriction

You can use the user file to control which users have access to licenses for specific products. The user file is a flat American National Standard Code for Information Interchange (ASCII) file that you create using a text editor. For each product in the file, there is a list of users. It lists either those who are allowed to use the product (in which case no one else can use it) or those who are not allowed to use it (in which case anyone else can use it).

In addition to the user file method, the License Administrator can grant or deny usage of a product to specific users or specific groups through the basic license tool graphical user interface or command line. This applies only to concurrent and concurrent-offline products. For concurrent-offline products the authorization can also be based on the end-user machine target ID and optionally secured by a password. Should a certain user be defined with both methods, the user file authorization method overrides the basic license tool method.

Switching from Per-Server to Per-Seat Licenses

Vendors of client/server applications who choose per-server/per-seat licensing provide you with two enrollment certificates:

• The per-server certificate, containing a per-server password;
• The per-seat certificate, containing a per-seat password;

You have the option to start in per-server mode, and switch at any time to per-seat mode, or start directly in per-seat mode. Once the per-seat mode has been activated, it is not possible to go back to per-server mode.

Back to top