Previous section.

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

Futures

The discussion is this section pertains to those items that have been reviewed, analyzed and evaluated by the XSLM specification team and have been deferred to the next release of the specification.
Note:
The discussion in this Appendix represents an indication of current thinking only. It is not an expression of commitment to adopt and deliver this functionality in a future version of this Technical Standard.

Network Computing and Component Licensing

The world of network computing presents a number of new challenges to license use management.

As the software industry moves toward the adoption of distributed object and component technologies it becomes less and less clear as to what constitutes (from the customer's point of view) a product, and what exactly is being licensed. A customer consumable product may be comprised of objects and components that themselves are licensed (from other software publishers) by the product developer.

When objects or components are statically bound into a single customer product entity, or shipped in their entirety as a single customer product, there is no real problem. However, when these components/objects are dynamically acquired by a product from a network of distributed object/component servers the product packages containing the objects and components themselves become individually licensable products. As a result a customer consumable product may in fact be comprised of several sub-products, each requiring its own license. These sub-licenses are, in a well-defined way, ultimately tied to the customer product license.

There is high customer value in being able to maintain a single copy of a given distributed component or object that can be shared by multiple products, potentially from multiple software publishers, across a single logical computing network. This fact when considered in conjunction with Java's promise of true binary portability across disparate computing platforms, would tend to indicate there is a reasonably high probability that the aforementioned multiple-license-to-one-product problem will become a very real licensing issue in the not too distant future.

Performance is always a key concern in a distributed computing network. Network distributable objects and components (including Java applets and beans) represent a formidable performance challenge to those who would like to individually license those entities. Questions such as when and how often these entities should interact with a software license use management system quickly arise.

Mobile Computing

The mobile (also known as nomad or "disconnected") computer user represents a unique challenge with respect to license use management. This is due to the fact that these users are not continuously connected to the corporate/office network. While this specification is not intended to address the software licensing needs of unmanaged computers (that is, computers which are never connected to a network), the mobile computer users most definitely fall within the domain of interest.

When connected to the network a mobile user possesses all the attributes of a standard desktop computer user. However, when disconnected from the network a mobile user must be able to retain all non-network related application functionality in absence of a network connection. It is this basic difference that presents an interesting set of problems to software license use management systems.

Server-to-Server Interaction

This specification assumes that all license servers taking part in a licensing system are, somehow, interconnected so that certain actions taken on one server are reflected to other servers. For example, a license certificate should only be installable once within a licensing system (even though it may possibly be installed on more than one physical server to provide redundancy, if the particular implementation supports this). While this requirement is clearly stated, this version of the specification doesn't fully provide the definitions needed for such an interaction between different implementations.


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