This chapter provides an introduction to the concepts of software
license use management and introduces the XSLM specification
components.
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:
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.
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.
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
Briefly, the XSLM software license management process is:
This combination of the license certificate, the enabled application
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.
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
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
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
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 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.
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.
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
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.
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.
| Contents | Next section | Index |