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.
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.
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.
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.
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.
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.
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.
| Contents | Next section | Index |