Previous section.

Systems Management: Software License Use Management (XSLM)
Copyright © 1999 The Open Group

Licensing Workflow and License Types

There are always at least two, and often more, independent entities-software publisher and customer-involved in the process of licensing software, and it is important that these processes are clearly understood in order to fully comprehend the issues involved with software license use management.

This chapter provides an overview of the software licensing process and underlying license types as seen by the software publisher, the customer, and the licensing system publisher. A workflow model is used as the means of introducing the activities required to both enable and use a compliant software license use management system. This model is used to validate that this specification addresses the requirements of all the parties involved.

The Licensing Process

Application Software Publisher's View

In this context, an application software publisher is defined as an individual or company that both develops and licenses one or more commercially available software products, owns the software and generally sets the terms and conditions of the licensing on that software. The application software publisher may also manufacture, market and distribute the software.

Application software publishers have a need to protect their software assets. At the same time, they need the ability to be as flexible as possible when negotiating licensing terms and conditions with their customers. Figure 2-1 illustrates the license use management workflow and tasks from the application software publishers perspective.

A responsibility of the application software publisher is to decide which sales models are to be used and to translate these models, in conjunction with the negotiated terms and conditions of the business contracts, into machine-readable policies called license certificates.

By itself, the license certificate does not protect the publisher's software assets. Nor does it provide a useful management tool for the customer. The application software publisher enables these capabilities allowing the application to function according to an agreed upon contract by embedding calls to the XSLM-compliant licensing system as part of the product program logic.

The XSLM specification is comprehensive enough to satisfy the needs of most application software publishers, but does not include all the functions provided by all existing licensing systems. Consequently, an XSLM-compliant license use management system product may include non-XSLM functions. These additional capabilities are referred to as publisher-specific functions.

Use of publisher-specific functions by application software publishers will limit compatibility with XSLM-compliant licensing systems.

Once an application software publisher has enabled a product to work with an XSLM-compliant licensing system, a reliable product distribution and installation process must be developed that delivers the product code, a customer-specific (or generic) XSLM license certificate and, sometimes, an XSLM licensing system.

Finally, the application software publisher bears primary responsibility for providing customer support. If, for any reason, the XSLM-compliant licensing system rejects a publisher-provided license certificate, or incorrectly denies a customer access to the application software publishers product, the application software publisher must be able to quickly identify the source of the problem, regardless of which XSLM-compliant licensing system is in use at the customer's site and, in resolving the problem, potentially work directly with the XSLM-compliant licensing system publisher.

Figure: Licensing Workflow from the Publishers Perspective

Customer's View

The customer is the named licensee: a person or entity that acquires software. In this context, a customer is the person or persons responsible for installing and maintaining the XSLM-compliant licensing system and the application software publisher-provided products as well as monitoring use of those products to ensure adherence to pre-negotiated terms and conditions. Generally, the administrator within the customer's organization would handle these functions.

Customers will have a standard, easy to use method of allowing the use of products while maintaining strict adherence to the terms and conditions. Customers also will have tools that provide them with information that allows them to diagnose license use problems, and to monitor and determine patterns of license and product use. A properly implemented license use management system will be transparent to the end-user of the products whose licenses it manages, with the possible exception of allowing the application to tell the user when no license is available.

Licensing Workflow from the Customers Perspective illustrates the license use management workflow and tasks from the customer's perspective.

In order to use a product, a customer must first be able to install it. Installation consists of loading the product on the customer's system, and in installing the associated license certificate (perhaps as simple as loading a file into a directory) into an already installed XSLM licensing system. Therefore, an XSLM licensing system accepts a valid license certificate from a software publisher provided product installation tool, loading the license certificate into the licensing system as part of the normal product installation process.

When explicitly permitted by the license certificate, a customer will have the ability to assign licenses subject to the terms and conditions embodied in that license certificate. In other words, customers will have the ability to make the license policy for a given product more restrictive than the terms and conditions of the license agreement.

In addition to proactive license use data analysis, customers will be able to integrate license use management into their existing automation processes. This means, for many customers, choosing a licensing system that provides alert information which can be directed, via standard instrumentation interfaces, to one or more installed automation systems. Alerts in this context refer to informational reports such as license not available, license about to expire, licensing system terminated, and the like. In an ideal situation, the customer will be able to configure the automation system to automatically respond to most common alerts. For example, a license about to expire might result in an automatically generated electronic mail directed to the department responsible for negotiating/renewing license agreements.

Finally, in a "run time" context, a customer will be able to operate in a disaster recovery scenario. Many customers have off site computing facilities to be used in the event of a disaster where their primary computing resources are unusable. A license use management system should not prevent the customer from conducting business in a disaster recovery (real or test) situation, allowing grace periods or alternate-server capabilities, for instance.

A compliant licensing system will maintain a machine-readable log of significant licensing events, for example, license shortages. The customer will be required to manage one or more log files (for example, to archive a log file). During the normal course of use, customers need to be able to detect license shortages, to dynamically adjust license use policy (when permitted), and to diagnose problems where the license-use management system denies a user product access for reasons which are not evident. The customer will also need, on occasion, to communicate with the licensing system to perform unusual recovery procedures such as reclaiming a license known by the customer to be reclaimable.

Figure: Licensing Workflow from the Customers Perspective

Customers will have the ability to view product license information, extract that information to external media (for safe keeping and/or off-line analysis), and to generate real-time or batch reports on historical and current license use. This information will be used by the customer to analyze usage patterns for purposes such as determining the need to acquire additional licenses, detecting products which are no longer being used, and providing statistical data to be used when negotiating new license agreements.

Licensing System Publisher's View

The third partner in this scenario is the XSLM licensing system publisher: the provider of the product or function which accumulates the information from the calls embedded in the application product, compares it to the terms and conditions evident in the license certificate, and responds with direction to the application product.

the XSLM licensing system must consider and resolve platform dependencies. For instance, not all operating systems provide access control, and signal alarms are not common across all platforms.

Therefore, the specification clearly defines what functions the XSLM licensing system must accommodate.

An XSLM-compliant licensing system may provide more function than is defined as the basic set; for instance, an enhanced reporting capability or alternative common logging facilities may be provided. The specific implementation of most required management functions is not defined only the requirement that these functions must be available.

License Types

As mentioned earlier in the Licensing Process section, sales models along with terms and conditions are translated into license certificates. A subset of the license certificate contains the license type, which is defined as the scope of the use of a specific product. It specifies the restrictions that are defined in the agreement between the customer and the software publisher. This section defines the minimum number of license types which have to be supported in order to allow the implementation of the wide variety of licensing terms and conditions (many of which are commonly known). The license types are listed in License Types.

In the technical implementation of these specifications, a license system publisher may view these unique license types, which define the behavior of the licensing system, as either reusable or non-reusable, and modifiable by time, capacity, count and/or naming conventions. Reusable or non-reusable can also be modifiers. It is more useful in this document to define these license types in terms more commonly used in the customer community as follows:

Each license type is modifiable by time. For instance, a DEMO implementation option might be a BASIC license that is useful only for 30 days from the date of installation or until a defined expiration date. These time attributes might be "start date/time," "end date/time," or "duration," for example.

A reusable license is one that, when its no longer required, is returned to the licensing system and becomes available for re-issuance against another license request; in contrast a non- reusable license type is one that once used, or counted, is not retrievable or reusable.

This license type is the base line. It represents a license for which there are no restrictions. In contrast, all the other license types define restrictions within which the application is licensed and the customer is to abide.
This license type compares the capacity of the operating environment against a predefined table, for instance, to assure the application is running in a machine whose computing capacity is not larger than that for which the product is licensed.
This is a license type for which the charges are based on counting the number of simultaneous demands or uses of a product, independent of who or what user is using the application quite the opposite from the Named concept. Further, these license uses are reusable: when the license use is no longer required it is returned to the licensing system and becomes available for re- issuance against another license request. The number and defined unit of measure may include a minimum or maximum number permitted per request. For instance, a Concurrent license may require that whenever a license request is made, five units of the defined measure (users, for instance), must be requested as a minimum.
This is a license type for which the charges are based on counting the defined units executed, perhaps over a specified period of time, against those licensed. Of principal importance with this license type is that a license count once used is not retrievable or reusable. As with Concurrent licensing, the number and defined unit of measure may include a minimum or maximum number permitted per request. For instance, a Consumptive license may require that whenever a license request is made, five units of the defined measure (blocks of time or gigabytes of storage, for instance), must be requested as a minimum. This license type might be useful in a peak use situation.
This is a license type for which the charges are based on counting a defined unit of measure against the number of units of that measure which were licensed. While Cumulative licensing merely accumulates the defined units of measure, as with Consumptive licensing, once used these units are not retrievable, or reusable. This license type might be useful in a post-pay term and condition.
This is a license type which compares name or serial number or ID or node address (for example) against those licensed. The Named license type implies pre-definition of the name. However, to build the registered or named "authorization list," the Named license type can also allow for a "first come-first served" concept where license requesting users (for instance) are registered (accepted/defined) until the number of users licensed is reached.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index