Previous section.

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


The Software License Use Management (XSLM) specification provides a mechanism for addressing interoperability problems among different license management systems, license certificate formats, and operating environments. XSLM also provides a mechanism for the creation of user-oriented tools to aid in the management of software licenses and application use monitoring.

This chapter provides an introduction to the concepts of software license use management and introduces the XSLM specification components.

Business Requirements

The key factors driving the need for comprehensive license use management are escalating software costs, the high administrative burden of license compliance control, the lack of effective customer control of software usage, and the lack of adequate protection for software publishers.

Customers must deal with multiple products, from multiple software publishers, on multiple platforms, with multiple licensing models. Given this exponential growth in complexity, there is a clear requirement for an overall framework for license use management that is:

The primary goals of this specification are to:

License use management tools, processes, products, and systems must:


There are currently thousands of software products in use that rely upon technical license managers (TLM) to ensure compliance with license terms and conditions.

The existence and widespread use of TLMs must be acknowledged, and in order to become generally accepted, any license use management system such as described in this document must allow for coexistence and an active integration with TLMs.

Today, a technical license manager, in general, does not provide extensive support for license use management as described in this document, especially on an enterprise-wide level. For example, a TLM often does not provide:

An XSLM-compliant licensing system may, of course, provide more function than is specified in this document; this ability will serve as a way for licensing system publishers to differentiate themselves, thereby providing customer choice.

Implementation Guidelines provides additional detail about implementation-specific areas.


This specification defines the functional components of a complete license use management system, and the rules by which those components interact with one another and with programs lying outside the framework domain (that is, programs that request XSLM services). The framework does not specify how the XSLM components are internally designed or implemented.

In general, the XSLM specification provides a vehicle for the implementation of the policy, not the enforcement of it. That is, the system provides an application with sufficient information about the policy to let it make an informed decision about whether or not to allow itself to be used. However, it is up to the application (and, thus, the software publisher) to enforce the license policy; the XSLM-compliant system should be viewed as a trusted vehicle by software publishers and customers, providing a repository for usage data supplied by the applications.

The XSLM-compliant system will manage licenses and license use policy information across multiple platforms in a consistent manner. The customer will be able to view policy information and administer software licenses from a single vantagepoint, even in cases of an application running on various platforms or multiple servers.

The key issue addressed by the license use management specification is consistency from the points of view of the application and manager clients, rather than that of the end-user. Achieving such consistency demands that licensing system publishers adhere to a strict set of interface rules. The specific solution implementation is irrelevant, providing that it adheres to a common, software publisher-independent set of interface protocols that preserves the clients black box view of the system. Adherence to this consistency will enable software publishers and customers to achieve the goals described in the Business Requirements section of this document.

During the development of this specification there have been many functions discussed and evaluated, some of which, while important, are not critical to the first release of the specification. Some of these functions, such as component licensing, network computing and server-to-server communications are to be included in the next release. Futures discusses these functions in more detail.

XSLM Specification Overview

This specification establishes the points at which a program may request services of and receive responses from a licensing system component, and the external protocols for doing so. A licensing system component implementation that conforms to, and enforces, these external protocols complies with the licensing system specification, and is therefore said to be XSLM-compliant (or just compliant).

This specification facilitates coexistence among multiple TLMs from the same or different software publishers on the same or different platforms, and allows for emerging technologies. Compliance with this specification will ensure software publishers that their intellectual properties are protected against misuse.

The XSLM-compliant system provides for a separation of data between different software publishers. Therefore, the specification requires that each publisher of an application has a unique identification. Each software publisher must assign its own product-codes or product-numbers within the publisher-code. Once the terms and conditions of a license have been agreed upon between a software publisher and a customer, those terms and conditions are provided to the XSLM-compliant system so that they can be used to issue licenses.

The XSLM specification is extensible so that it can be implemented on virtually any kind of hardware or software and can encode virtually any kind of terms and conditions. This document includes a list (see License Types) of several license types, such as maximum number of concurrent users, that XSLM-compliant licensing systems must support. The XSLM-compliant system does not restrict a software publisher and a customer from negotiating any unusual license, such as the application can only be used on the first and third Monday of each month, by providing an escape mechanism, under which the policy data can be made available directly to the application, complementing any rule-based decision-making normally done by the XSLM- compliant system. The extensibility features of the specification will provide protection for software publishers in the evolving world of property-right legislation and enforcement.

Briefly, the XSLM software license management process is:

  1. The customer and the application software publisher agree to license terms and conditions.

  2. The application software publisher translates these terms and conditions into machine readable policies embedded in a license certificate, which is delivered to the customer along with the application program, into which are embedded calls to the XSLM licensing system.

  3. The licensing system supplies the logic to interpret the license certificate, the logic to determine whether an application request to execute should be accepted, and a secure secret-sharing mechanism to ensure confidence in the validity of both the request and the response.

This combination of the license certificate, the enabled application and the licensing system provides the customer with:

Main Specification Components

The specification addresses four areas, all of vital concern in a software license use management system:

This specification defines the API syntax and semantics. It does not specify the method used to implement the API functions. This is left to the discretion of the licensing system publisher.

This specification does not specify the communications protocol to be used between an API implementation and its corresponding licensing server implementation.

A Common License Certificate Format

A central part of the XSLM specification is the concept of a license certificate specified in a common license certificate format. A license certificate is the encoding, into a standard format, of the terms and conditions that are contained within a license agreement governing the use of a particular product. This holds true, no matter how the product is licensed, whether via a direct negotiation between software publisher and customer (in which case there often exists a license agreement specific to a particular transaction), or as a shrink-wrap license.

The common license certificate format is such that an external license certificate can be created on a platform different from that where the license certificate will be installed (that is, the location of the license server), and different from the platform where the licensed application actually will be running. There is no requirement that the tools used to create a license certificate and to install it into a license server are provided by the same licensing system software publisher. The only requirement is that the tools used by both licensing system software publishers and customers can create and accept the same external representation, that is the common license certificate format.

A license certificate will contain sufficient security and integrity data (such as digital signatures) to ensure that tampering is detectable by the XSLM system, or directly by the application when it requests a license.

License Certificate Format specifies the format of a license certificate and explains how application publishers can define their own, private data elements. Data Elements contains a list of all predefined data elements, both required and optional.

The Application API

The Application API (XAAPI) defines the interface that any licensing system-enabled application would use to interact with an XSLM-compliant license server, to include license verification and to handle all the activities associated with it. The intent is to standardize the way in which common functionality provided by existing licensing systems can be accessed. These API functions allow software publishers to enable applications in a way that is independent of the underlying (XSLM-compliant) licensing system.

Although there may be many physical servers, the application product communicates with just a single, logical license server that is embodied in the API library. Application products direct requests to a library that provides the XAAPI interface, not directly to a physical server.

The main goals for the XAAPI are to:

The XAAPI functions fall into two sets: a basic API and an advanced API. The basic set includes the minimum function required to provide support for a basic, yet complete, licensing activity. The advanced set includes and extends the functionality of the basic set. It provides the application developer with more flexibility and options in support of a more complex licensing scheme.

The Management API

The Management API (XMAPI) is the component that enables license use management systems provided by multiple software publishers to be managed as a single logical licensing system.

The XMAPI provides license management applications with an implementation independent means of:

This specification does not prescribe the physical structure of the data, or the means by which an implementation chooses to store the data it collects and maintains. It does, however, define the logical structure of the data passed to, and received from a license server, via the XMAPI. This logical (self-defining) data structure is defined in License Certificate Format. This specification also defines the persistency requirements for data transmitted to the licensing system across selected management API functions.

This self-defining data architecture provides for additional implementation specific data to be transmitted across the XMAPI. To permit this flexibility while maintaining compatibility with other compliant licensing systems, XSLM mandates that each implementation ignores any data received across the API that does not carry that implementations unique publisher identification.

The Recording and Logging Services

A crucial function of an XSLM licensing system is to collect and record data about the usage of the licensed products and about relevant events related to license management. A compliant XSLM system will maintain three types of information: certificate data, status data, and historic (or logged) data.

The certificate data is the combination of information provided by the application software publisher (embodied in the license certificate), which cannot be modified by the licensing system or by the administrator; information provided by the customer's license administrator (to complement or override, when allowed, the licensing policy specified in the license certificate); and information created and maintained by the licensing system itself.

The status data is maintained by the licensing system while it is running, and at each point in time it provides information about the licenses presently in use, and the value of the meters maintained by the licensing system. Some applications can be licensed based on the count of some units whose meaning in general is known only to the application, and the licensing system keeps track of the units to be counted, acting as a "record keeper". The updating of the meter will be explicitly requested by the application with an API call. A change in the status information is triggered by external (to the licensing system) events, such as the request for a new license, or a change in policy setting (e.g. the administrator switching from soft stop to hard stop) or the expiration of a timer.

The historic data is the persistent log of events relevant to license management. All events related to license administration actions will always be logged, as they can constitute an audit trail (e.g. the addition or deletion of a certificate to/from the license database). The logging of events related to license usage (e.g. an application requesting or releasing a license, or a meter being updated) will usually be under administrator's control.

A Logical View of the Specification

Conceptually, this specification describes a single, logical, licensing system running on a single computing system. This logical view is independent of how a particular system is implemented. An actual implementation may provide capabilities for defining multiple, logical, and customer-defined domains that can be controlled independently of each other.
Figure: Logical View of a License Use Management System

Coexistence and Integration with Technical License Managers

There are several existing software technical license managers (TLMs) in common use today, each of which is based on a proprietary set of protocols defined solely by the TLM publisher. It is an XSLM goal to make it practical for these existing proprietary license managers to be adapted to form compliant implementations of this specification.

XSLM compliant licensing systems can always coexist with other XSLM and non-XSLM compliant licensing systems running on the same computer system, although there are no practical license management related benefits realized by doing so.

Providing XSLM Compliance

XSLM provides for several levels of compliance.

Legacy Functional Level compliance requires support for the Basic XMAPI API and the Basic XCLA data architecture - the Base Function Set1. A Legacy Functional Level compliant license manager is visible to XSLM-compliant license use management tools. This enables users to view license use information in an enterprise-wide systems management context; that is, as part of a single logical licensing system comprised of (potentially) multiple physical license servers from (potentially) multiple license system publishers.

Additional compliance levels require support for one or more of the documented optional functional towers, as defined in Function Sets and Functional Towers.

Special Notes for LSAPI-Enabled Licensing Systems

Some licensing systems in common use today provide support for the licensing system protocols and APIs described by the LSAPI 1.1 specification (see referenced document LSAPI). This specification addresses the basic application requirement to acquire, validate, and release a software license through one of an unknown (to the application) set of licensing system servers.

The basic XSLM API is defined so as to make it possible for any TLM that has implemented the LSAPI specification to be easily transformed, at the application API level, into one providing equivalent functionality that is XSLM-compliant. However, to be labeled XSLM-compliant an existing licensing system must implement, in addition to the basic application API set, the appropriate XSLM management API set.

Providing Non-XSLM Defined Functionality

Licensing systems electing to operate at the Advanced compliance level can reasonably expect to represent most, if not all, existing TLM functionality in terms of XSLM defined APIs and related logical data structures. However, it is acknowledged that application publishers may require specific functionality offered by an existing proprietary TLM, but where it is not appropriate to define that functionality as part of a general license use management specification.

The XSLM specification addresses the potential requirement for implementation specific function and related data by providing for licensing system specific extensions. An application that depends on such extensions will be restricted to using only compliant licensing systems that implement those extensions. Even in the case where one or more applications require such extensions there are customer benefits to XSLM compliance; the principal benefit being the ability to generate, distribute, install, and manage standard XSLM-defined license certificates and related licensing system resources.

An XSLM-defined license certificate may contain licensing system specific information. This information is encoded in the form of an architected licensing system publisher specific section of the certificate, identifying that specific publisher. The licensing system publisher data itself appears within the licensing system section and is defined information encapsulated in XSLM-format license certificate data elements. The presence of a licensing system publisher specific section restricts the license certificate to being installed only in a license system server whose published id matches that identified in the license certificate. When multiple licensing system publisher sections appear in a certificate, the certificate may be installed in a license server whose id matches any one of those contained in that certificate.

An application publisher can thus distribute a standard XSLM-defined license certificate that conveys licensing system specific information to one or more specific licensing system server implementations. This in turn provides an existing TLM with the ability to offer extended (not defined by XSLM) services to those applications that require them, yet remain XSLM compliant. Similarly the XSLM defined data architecture provides existing TLMs with the means to expose implementation specific software license management data through the standard XSLM-defined management APIs.


See Function Sets and Functional Towers for additional information.

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