 |
Claims  |
|
|
What is claimed is:
1. A method operating in a computer system for managing execution of
licensed software items in said computer system, comprising the steps of:
maintaining by said computer system a store of license authorizations for
said software items; each license authorization including an indication of
license management policy for a software item, said indication being in
the format of an encoded document of a data type consisting of an ordered
sequence of three elements, the three elements including a document
descriptor, a document header and the document content;
accessing by said computer system said store to retrieve information from
said license authorization for said software item, in response to a
request from a client, and comparing said client request, including
identification of said client and said software item, with said retrieved
information, to produce a grant or refusal of said request.
2. A method according to claim 1 wherein said document descriptor includes
an encoding method version number, an encoder-identifier and an
encoder-name.
3. A method according to claim 1 wherein said document header includes a
title, an author, a version and a date for the software item.
4. A method according to claim 1 wherein said document content includes at
least one of the following:
a product-use-authorization;
a license-use-requirements-table;
a group-definition;
a key-registration;
a delegation.
5. A method according to claim 1 wherein said document content includes a
license-data-header, and said license-data-header describes parties to
said license authorization, a term of said license authorization and any
constraints that have been placed on management of said license
authorization.
6. A method according to claim 1 wherein said document content includes
management-info, where the management-info includes at least one of the
following:
an assignment;
a reservation;
a delegation;
a backup delegation;
an allocation;
a registration date;
a registrar;
a comment;
a termination-date.
7. A method according to claim 1 wherein:
said document descriptor includes an encoding method version number, an
encoder-identifier and an encoder-name;
said document header includes a title, an author, a version and a date for
the software item;
said document content includes a license-body comprising at least one of
the following: a product-use-authorization, a
license-use-requirements-table, a group-definition, a key-registration,
and a delegation;
said document content further includes a license-data-header comprising an
identification of parties to said license authorization, a term of said
license authorization and constraints that have been placed on management
of said license authorization; and
said document content further includes management-info comprising at least
one of the following: an assignment, a reservation, a delegation, a backup
delegation, an allocation, a registration date, a registrar, and a
comment.
8. A method according to claim 1 wherein said store is maintained by a
license server, said request is sent to said server, and said accessing
and comparing are performed by said server, and wherein said server and
said client are nodes on a distributed computer network.
9. A method according to claim 1 wherein said request is in the form of a
remote procedure call, and said grant or refusal sent to said client is a
return of said procedure call.
10. A method according to claim 8 wherein said license authorization is
received by said server from an issuer.
11. A method according to claim 1 including the steps of:
sending a request by a client to obtain permission to use one of said
software item; said request identifying a user and said software item;
sending said grant or refusal to said client.
12. Apparatus operating in a computer system for managing execution of
licensed software items in said computer system, comprising:
means for maintaining a store of license authorizations for said software
items; each license authorization including an indication of license
management policy for a software item, said indication being in the format
of an encoded document of a data type consisting of an ordered sequence of
three elements, the three elements including a document descriptor, a
document header and the document content;
means for sending a request by a client to obtain permission to use one of
said software items; said request providing an identification of said
client and said software item;
means for accessing said store to retrieve information from said license
authorization for said software item, in response to said request, and
comparing said client request, including identification of said client and
said software item with said retrieved information, to produce a grant or
refusal of said request;
means for sending said grant or refusal to said client.
13. Apparatus according to claim 12 wherein said document descriptor
includes an encoding method version number, an encoder-identifier and an
encoder-name.
14. Apparatus according to claim 12 wherein said document header includes a
title, an author, a version and a date for the software item.
15. Apparatus according to claim 12 wherein said document content includes
at least one of the following:
a product-use-authorization;
a license-use-requirements-table;
a group-definition;
a key-registration;
a delegation.
16. Apparatus according to claim 12 wherein said document content includes
a license-data-header, and said license-data-header describes parties to
said license authorization, a term of said license authorization and
constraints that have been placed on management of said license
authorization.
17. Apparatus according to claim 12 wherein said document content includes
management-info, where the management-info includes at least one of the
following:
an assignment;
a reservation;
a delegation;
a backup delegation;
an allocation;
a registration date;
a registrar;
a comment;
a termination-date.
18. Apparatus according to claim 12 wherein:
said document descriptor includes an encoding method version number, an
encoder-identifier and an encoder-name;
said document header includes a title, an author, a version and a date for
the software item;
said document content includes a license-body comprising at least one of
the following: a product-use-authorization, a
license-use-requirements-table, a group-definition, a key-registration,
and a delegation;
said document content further includes a license-data-header comprising an
identification of parties to said license authorization, a term of said
license authorization and constraints that have been placed on management
of said license authorization; and
said document content further includes management-info comprising at least
one of the following: an assignment, a reservation, a delegation, a backup
delegation, an allocation, a registration date, a registrar, and a
comment.
19. Apparatus according to claim 12 wherein said store is maintained by a
license server, said request is sent to said server, and said accessing
and comparing are performed by said server.
20. Apparatus according to claim 12 wherein said request is in the form of
a remote procedure call, and said grant or refusal sent to said client is
a return of said procedure call.
21. Apparatus according to claim 12 wherein said license authorization is
received by said maintaining means from an issuer.
22. Apparatus according to claim 12 wherein said server and said client are
nodes on a computer network.
23. A method of storing software license documents by a server for a
software license management system, comprising the steps of:
maintaining a store of license documents for software items; each license
document including an indication of license management policy for a
corresponding one of said software items, said indication being in the
format of an encoded document of a data type consisting of an ordered
sequence of three elements, the three elements including a document
descriptor, a document header and the document content;
accessing said store to retrieve information from one of said license
documents corresponding to one of said software items selected in response
to a request, and referencing said indication of license management
policy, to produce a grant or refusal of said request.
24. A method according to claim 23 wherein said document descriptor
includes an encoding method version number, an encoder-identifier and an
encoder-name.
25. A method according to claim 23 wherein said document header includes a
title, an author, a version and a date for the software item.
26. A method according to claim 23 wherein said document content includes
at least one of the following:
a product-use-authorization;
a license-use-requirements-table;
a group-definition;
a key-registration;
a delegation. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
RELATED CASES
This application discloses subject matter also disclosed in the following
copending applications, all assigned to Digital Equipment Corporation, the
assignee of this invention:
Ser. No. 697,652, filed May 8, 1991, now abandoned by Robert M. Wyman, for
LICENSE MANAGEMENT SYSTEM;
U.S. Pat. No. 5,204,897, issued from Ser. No. 07/914,040, filed Jul. 14,
1992, by Robert M. Wyman, for MANAGEMENT INTERFACE FOR LICENSE MANAGEMENT
SYSTEM, which was a continuation of Ser. No. 07/722,840, filed Jun. 28,
1991.
U.S. Pat. No. 5,260,999, issued from Ser. No. 07/946,009, filed Sep. 15,
1992, by Robert M. Wyman for FILTERS IN LICENSE MANAGEMENT SYSTEM, which
was a continuation of Ser. No. 07/723,657, filed Jun. 28, 1991.
BACKGROUND OF THE INVENTION
This invention relates to methods of operation of computer systems, and
more particularly to a method and system for managing the licensing of
software executed on computer systems.
In U.S. Pat. No. 4,937,863, issued to Robert, Chase and Schafer and
assigned to Digital Equipment Corporation, the assignee of this invention,
a Software Licensing Management System is disclosed in which usage of
licensed software may be monitored in a computer system to determine if a
use is within the scope of a license. The system maintains a database of
licenses for software products, and stores a unit value indicating the
number of licensing units for each product. When a user wishes to use a
licensed product, a message is sent to the central license management
facility requesting a license grant. In response to this message, the
facility accesses the database to see if a license exists for this
product, and, if so, whether units may be allocated to the user, depending
upon the user's characteristics, such as the configuration of the platform
(CPU) which will execute the software product. If the license management
facility determines that a license can be granted, it sends a message to
the user giving permission to proceed with activation of the product. If
not, the message denies permission.
While the concepts disclosed in the U.S. Pat. No. 4,937,863 are widely
applicable, and indeed are employed in the present invention, there are
additional functions and alternatives that are needed in some
applications. For example, the license management system should allow for
simultaneous use of a wide variety of different licensing alternatives,
instead of being rigidly structured to permit only one or only a few. When
negotiating licenses with users, vendors should have available a wide
variety of terms and conditions, even though a given vendor may decide to
narrow the selection down to a small number. For example, a software
product may be licensed to a single individual for use on a single CPU, or
to an organization for use by anyone on a network, or for use by any users
at terminals in a cluster, or only for calls from another specific
licensed product, or any of a large number of other alternatives. A vendor
may have a large number of products, some sold under one type of license
and some under others, or a product may be a composite of a number of
features from one or more vendors having different license policies and
prices; it would be preferable to use the same license management system
for all such products.
Distributed computing systems present additional licensing issues. A
distributed system includes a number of processor nodes tied together in a
network of servers and clients. Each node is a processor which may execute
programs locally, and may also execute programs or features (subparts of
programs) via the network. A program executing on one node may make remote
procedure calls to procedures or programs on other nodes. In this case,
some provision need be made for defining a license permitting a program to
be executed in a distributed manner rather than separately on a single
CPU, short of granting a license for execution on all nodes of a network.
In a large organization such as a company or government agency having
various departments and divisions, geographically dispersed, a software
license policy is difficult to administer and enforce, and also likely to
be more costly, if individual licenses are negotiated, granted and
administered by the units of the organization. A preferred arrangement
would be to obtain a single license from the software producer, and then
split this license into locally-administered parts by delegation. The
delays caused by network communication can thus be minimized, as well as
budgetary constraints imposed on the divisions or departments. Aside from
this issue of delegation, the license management facility may best be
operated on a network, where the licensing of products run on all nodes of
the network may be centrally administered. A network is not necessary for
use of the features of the invention however, since the license management
can be implemented on a single platform.
Software products are increasingly fragmented into specific functions, and
separate distribution of the functions can be unduly expensive. For
example, a spreadsheet program may have separate modules for advanced
color graphics, for accessing a database, for printing or displaying an
expanded list of fonts, etc. Customers of the basic spreadsheet product
may want some, none or all of these added features. Yet, it would be
advantageous to distribute the entire combination as one package, then
allow the customer to license the features separately, in various
combinations, or under differing terms. The customer may have an entire
department of the company needing to use the spreadsheet every day, but
only a few people who need to use the graphics a few days a month. It is
advantageous, therefore, to provide alternatives for varied licensing of
parts or features of software packages, rather than a fixed policy for the
whole package.
Another example of distribution of products in their entirety, but
licensing in parts, would be that of delivering CD ROMs to a customer
containing all of the software that is available for a system, then
licensing only those parts the customer needs or wishes to pay fees for
rights to use. Of course, the product need not be merely applications
programs, operating systems, or traditional executable code, but instead
could also include static objects such as printer fonts, for example, or
graphics images, or even music or other sound effects.
As will be explained below, calling and caller authorizations are provided
in the system according to one feature of the invention, in order to
provide technological support for a number of business practices and solve
technical problems which require the use of what is called "transitive
licensing." By "transitive licensing" is meant that the right to use one
product or feature implies a right to use one or more other products or
features. Transitive licenses are similar to group licenses in that both
types of license consist of a single instrument providing rights of use
for a plurality of products. However, transitive licenses differ from
group licenses in that they restrict the granted rights by specifying that
the licensed products can only be used together and by further specifying
one or more permitted inter-product calling/caller relationships. Some
examples may help to clarify the use and nature of a transitive license:
the examples to be explained are (1) two products sold together, (2) a
give-away that results from narrow choices of licensing alternatives, (3)
a client licensing method in a client/server environment, (4) impact of
modular design, and (5) the impact of distributed design.
A software vendor might have two products for sale: the first a mail
system, and the second a LEXIS.TM.-like content-based text retrieval
system. Each of these products might be valued at $500 if purchased
separately. Some customers would be satisfied by purchasing the rights to
use only one of these products. Others might find that they can justify
use of both. In order to increase the likelihood that customers will, in
fact, purchase both products, it would not be surprising if the software
vendor offered his potential customers a volume discount, offering the two
products for a combined price of $800. The customers who took advantage of
this combined offer would find that they had received two products, each
of which could be exploited to its fullest capabilities independently from
the other. Thus, these customers would be able to use the content based
retrieval system to store and retrieve non-mail documents. However, from
time to time, the vendor may discover that particularly heavy users of
mail wish to be able to use the content based retrieval system only to
augment the filing capabilities provided by the standard mail offering. It
is likely that many of these potential customers would feel that $800 is
simply too much to pay for an extended mail capability. The vendor might
then consider offering these customers a license that grants mail users
the right to use the content-based retrieval system only when they are
using mail and prohibits the use of content based retrieval with any other
application that might be available on the customers system. This type of
license is referred to below a "transitive license," and it might sell for
$600.
Another example is a relational database product (such as that referred to
as Rdb.TM.) designed for use on a particular operating system, e.g., VMS.
This relational database product has two components: (1) A user interface
used in developing new databases, and (2) a "run-time" system which
supports the use of previously developed databases. The developers of the
database product might spend quite a bit of effort trying to get other
products made by the vendor of the database product to use it as a
database instead of having those other products build their own
product-specific databases. Unfortunately, the other product designers may
complain that the cost of a run-time license for the database product,
when added to the cost of licenses for their products, would inevitably
make their products uncompetitive. Thus, some mechanism would be needed
that would allow one or another of the vendor's products to use the
run-time system for the relational database product in a "private" manner
while not giving unlicensed access to products of other vendors. No such
mechanism existed, prior to this invention; thus, the vendor might be
forced to sell the right to use its run-time system for the database
product with its proprietary operating system license. Clearly, this
combined license would make it possible for the vendor's products to use
its database product without increasing their prices; however, it also
would make it possible for any customers and third-parties to use the
database product without paying additional license fees. However, had the
system of the invention been available, the vendor could have granted
transitive licenses for the run-time component of its database product to
all the vendor's products. Essentially, these licenses would have said
that the database run-time could be used without an additional license fee
if and only if it was used in conjunction with some other of the vendor's
products. Any customer wishing to build a new relational database
application or use a third-party application that relied on the vendor's
database product would have had to pay the vendor for its database
run-time license.
A proposed client/server licensing method provides yet another example of a
problem which could be solved by transitive licensing. Typically, a client
is only used by one user at a time, while a server can support an
arbitrary number of clients depending on the level of client activity and
the capacity of the machine which is supporting the server. While
traditionally, server/client applications have been licensed according to
the number of clients that a server could potentially support, this may
not be the most appropriate method for licensing when the alternatives
afforded by the invention are considered. The business model for the
proposed client/server method requires that each client be individually
licensed and no explicit licensing of servers is required to support
properly licensed clients. Such a licensing scheme makes it possible to
charge customers only for the specific number of clients they purchase.
Additionally, it means that a single client can make use of more than one
server without increasing the total cost of the system. The solution to
this transitive licensing problem would be to provide a mechanism that
would allow the clients to obtain license unit allocations and then pass a
"proof" of that allocation to any servers they may wish to use. Servers
would then support any clients whose proofs could be verified to be valid.
On the other hand, if a client that had not received a proof of allocation
attempted to use a server, the server would obtain a license allocation
for that client session prior to performing any services. Such a solution
has not been heretofore available.
As the complexity and size of the software systems provided to customers
increases, it is found that the actual solution provided to customers is
no longer a single product. Rather, customers are more often now offered
solutions which are built up by integrating an increasing number of
components or products, each of which can often stand alone or can be part
of a large number of other solutions. In fact, a product strategy may rely
almost exclusively on the vendor's engineering and selling a broad range
of specialized components that can only be fully exploited when combined
together with other components into a larger system. Such components
include the relational database runtime system mentioned above, mail
transport mechanisms, hyperinformation databases, document format
conversion services, time services, etc. Because these components are not
sold on their own merits, but rather on their ability to contribute to
some larger system, it is unlikely that any one customer will be receiving
the full abstract economic value of any one of the components once
integrated into a system. Similarly, it can be observed that the value of
any component once integrated into a larger system varies greatly from
system to system. Thus, it may be found that a mail transport mechanism
contributes a large part of a system whose primary focus is mail, however,
it will contribute proportionally less of the value of a system that
provides a broader office automation capability. As a result of these
observations, the job of the business analyst who is attempting to find
the "correct" market price for each component standing on its own, is more
complex. In reality, the price or value of the component can only be
determined when considering the contribution of that component to the full
system or solution in which it is integrated. Attempting to sell the
components at prices based on their abstract, independent values will
simply result in overpriced systems.
Transitive license styles are particularly suited to dealing with pricing
of modular components, since component prices can be clearly defined in
relation to the other components or systems which they support. Thus, a
vendor can charge a price of $100 for the right to use a mail transport
system in conjunction with one product, yet charge $200 for the use of the
same mail transport system when used by another product.
In addition to the "business" reasons for wanting to support transitive
licensing, there is also a very good technical reason that arises from the
growing tendency of developers to build "distributed products" as well as
the drive toward application designs that exploit either tightly or
loosely coupled multiprocessor systems; the availability and growing use
of remote procedure calls has contributed to this tendency. This technical
problem can be seen to arise when considering a product which has a number
of components, each of which may run in a different process space and
potentially on a different computer system. Thus, there might be a mail
system whose user interface runs on one machine, its "file cabinet" is
supported by a second machine and its mail transport system runs on yet a
third machine. The simple question which arises is: "Which of the three
components should check for licenses?" Clearly it must be ensured that no
single component can be used if a valid license is not present. Thus, the
answer to the question will probably be that all three components should
check for licenses. However, the question is then presented: " Where are
the licenses to be located?". This can become more complex.
Increasingly, the distributed systems being built are being designed so
that it is difficult to predict on which precise machine any particular
component will run. Ideally, networks are supposed to optimize the
placement of functions automatically so that the machine with the most
available resource is always the one that services any particular request.
This dynamic method of configuring the distribution of function servers on
the network makes it very difficult for a system or network manager to
predict which machines will run any particular function and thus very
difficult for him to decide on which machines software licenses should be
loaded.
Even if a system manager could predict which machines would be running the
various application components and thus where the license units should be
loaded, the situation would still be less than ideal. The problem arises
from the fact that each of the components of the application would be
independently making requests for license unit allocations. This behavior
will result in a difficult problem for anyone trying to decide how many
license units are required to support any one product. Given the mail
example, the problem wouldn't exist if it were assumed that all three
components (i.e., user interface, file cabinet, and transport system) were
required by the design of the mail system to be in use simultaneously. If
this were the case, it could be simply assumed that supporting a single
activation of the mail system would require three units. However, in a
real mail system, it will be inevitably discovered that many users will
only be using just the user-interface and file-cabinet components of the
system at one time. Thus, there will be some unused units available which
could be used to authorize additional users. This situation might not be
what is desired by the software vendor.
The problem of providing license support to multi-component products which
are dynamically configured could be solved by viewing each of the product
components as a distinct licensable product and by treating the problem as
one of transitive licensing, but a mechanism for accomplishing this has
not been available. Essentially, a single license document would be
created that stated that if any one of the components had successfully
obtained a license to run, it could use this grant to give it the right to
exploit the other components. Thus, in the example above, the user might
start the mail system by invoking its user interface. This user interface
code would then query the license management facility for a license
allocation and once it has received that allocation, it would pass a proof
of allocation to the other mail components that it uses. Each of the other
components would request that the license management system validate that
the "proof" is valid prior to performing any service; however, none of the
other components would actually require specific allocations to be made to
them. In this way, the complexity of licensing and managing networks of
distributed applications can be significantly reduced.
SUMMARY OF THE INVENTION
In accordance with one embodiment of the invention, a license management
system is used to account for software product usage in a computer system.
The system employs a license management method which establishes a
management policy having a variety of simultaneously-available alternative
styles and contexts. A license server administers the license, and each
licensed product upon start-up makes a call to the license server to check
on whether usage is permitted, in a manner similar to that of U.S. Pat.
No. 4,937,863. The license server maintains a store of the licenses,
called product use authorizations, that it administers. Upon receiving a
call from a user, the license server checks the product use authorization
to determine if the particular use requested is permitted, and, if so,
returns a grant to the requesting user node. The license server maintains
a database of product use authorizations for the licensed products, and
accesses this database for updating and when a request is received from a
user. While this license management system is perhaps of most utility on a
distributed computer system using a local area network, it is also
operable in a stand-alone or cluster type of system. In a distributed
system, a license server executes on a server node and the products for
which licenses are administered are on client nodes. However, the license
management functions and the licensed products may be executing on the
same processor in some embodiments.
The product use authorization is structured to define a license management
policy allowing a variety of license alternatives by components called
"style", "context", "duration" and "usage requirements determination
method". The style may be allocative or consumptive. An allocative style
means the units of the license may be allocated temporarily to a user when
a request is received, then returned to the pool when the user is
finished, so the units may be reused when another user makes a request. A
consumptive style means the units are deducted from an available pool when
a user node makes a valid request, and "consumed", not to be returned for
reuse. The context value defines the context in which the use is to be
allowed, such as on a particular network, by a particular type of CPU, by
a particular user name, by a particular process, etc. The duration value
(used in conjunction with the style component) concerns the time when the
license units are to be deducted from the available pool of units, whether
at the time of request, after a use is completed, etc. A usage
requirements determination method may be specified to define or provide
information concerning the number of license units charged in response to
a license request from a user node; for example, some CPU platforms may be
charged a larger number of license units than others. A table may be
maintained of usage requirements, and the determination method may specify
how to access the table, for example. The important point is that the user
node (thus the software product) can only make a request, identifying
itself by user, platform, process, etc., and the license management
facility calculates whether or not the license can be granted (that is,
units are available for allocation), without the user node having access
to any of the license data or calculation. There is a central facility,
the license server, storing the license documents, and, upon request,
telling the licensed products whether they can operate under the license
terms.
An important feature of one embodiment is that the license administration
may be delegated to a subsection of the organization, by creating another
license management facility duplicating the main facility. For example,
some of the units granted in the product use authorization may be
delegated to another server, where the user nodes serviced by this server
make requests and receive grants.
The license management facility cannot create a license itself, but instead
must receive a license document (a product use authorization) from an
issuer of licenses. As part of the overall license management system of
the invention, a license document generator is provided which creates the
product use authorizations under authority of the owner of the software,
as negotiated with customers. Thus, there are three distinct rights in the
overall license management facility of the invention: (1) the right to
issue licenses, (2) the right to manage licenses, and (3) the right to use
the licensed products. Each one of these uses the license document only in
prescribed ways. The license issuer can generate a license document. The
license manager (or license server as referred to herein) can grant
products the right to use under the license, and can delegate parts of the
licensed units for management by another server, as defined by the license
document; the way of granting rights to products is by responding to
certain defined calls from the products. And, the licensed products can
make certain calls to the license server to obtain grants of rights based
upon the license document, inquire, or report, but ordinarily cannot
access the document itself.
As explained above, transitive licensing is an important feature of one
embodiment. This is the provision of a mechanism for one user node to get
permission to use another software product located on another user node;
this is referred to as a calling authorization and a caller authorization,
using a "calling card," and these are examples of the optional features
which must be specifically permitted by the product use authorization. A
user node must obtain permission to make a procedure call to use a program
on another node; this permission is obtained by a request to the license
server as before, and the permission takes the form of a calling card.
When a calling card is received by a second node (i.e., when the procedure
call is made), a request is made by the second node to the license server
to verify (via the product use authorization) that the calling card is
valid, and a grant sent to the user node if allowed. In this manner, all
nodes may have use of a program by remote calls, but only one consumes
license units.
Another important feature of one embodiment is a management interface which
allows a license manager to modify the license policy components of a
license document maintained by at a license server in its database.
Usually the license manager can only make modifications that restrict the
license policy components to be more restrictive than originally granted.
Of course, the management interface is used to make delegations and
assignments, if these are authorized.
The license document interchange format is an important feature, in that it
allows the license management system to be used with a wide variety of
software products from different vendors, so long as all follow the
defined format. The format uses data structures that are defined by
international standards.
An important function is the filter function, used in the management
interface and also in the client interface to select among elements in the
data structures.
BRIEF DESCRIPTION OF THE DRAWINGS
The novel features believed characteristic of the invention are set forth
in the appended claims. The invention itself, however, as well as other
features and advantages thereof, will be best understood by reference to
the detailed description of specific embodiments which follows, when read
in conjunction with the accompanying drawings, wherein:
FIG. 1 is a diagram in block form of a distributed computer system which
may be used to implement the license management operations according to
one embodiment of the invention;
FIG. 2 is a diagram of the content of a license document or "product use
authorization" generated by the license document generator and stored by
the license server in the system of FIG. 1;
FIG. 3 is a diagram of the alternatives for license | | |
