by Sergiu S. Simmel and Ivan Godard
ABSTRACT
This paper describes the licensing and metering capabilities of Kala[1], a persistent data server. Kala offers a suite of low-level primitives for constructing both simple and sophisticated licensing (pay-per-user) and metering (pay-per-use) models. Kala allows the licensing and/or metering of access to any software facilities, both data (passive resources) and executable code and associated services (active resources). A few examples model concrete business needs, bridging the gap between technologically motivated mechanism and business motivated policies.
INTRODUCTION
This section motivates the work on economic grounds. It also introduces several terms used throughout the paper.
Components, Subassemblies and Applications
It is natural to think of software as being an assemblage of components. Software structure starts with small-grain components such as functions, classes, and data values. These are grouped in subassemblies, such as a library or a subsystem. Successive composition finally yields what we all think of as applications — a conventional packaging of functionality.
The basic distinction between components, subassemblies and applications is that of granularity. In electronic hardware the analogous entities are electronic components (such as integrated circuits and passive components), boards (usually ready to be plugged into bus connectors), and systems (such as personal computers).
For simplicity, we will use the term component to mean both components and subassemblies. We will use the term subassembly only if there is need to distinguish them from small-grain components.
Both program components and data components exist. The former includes such examples as operating system subsystems, runtime libraries, specialized classes, etc. The latter includes font collections, clip-art sheets, economic indicators, and so on.
Components, subassemblies, and applications go through an economic cycle which includes two mechanisms relevant to our discussion: the distribution mechanism and the revenue collection mechanism.
Distribution is the mechanism by which a component is made available to another component or final consumer (end-user). Several distribution techniques are conventionally used throughout the industry: embedding (static linking), runtime linking, and runtime loading.
Revenue Collection is the mechanism by which payment for a component is made to reach the producing vendor, regardless of the context in which the component is actually used. Conventionally, revenue collection is done at the time the component is distributed.
The Economics of Components
Markets for software applications have been established for some time. There is a market for subassemblies as well, although substantially smaller and with much less potential for growth and diversification. The market for small-grain components is very small, although a great many are given away free or bundled with larger units.
Many analysts attribute the relative lack of an open market for components to the tight coupling between delivery and revenue collection. The reasons include, among others:
- Hard to Control Scarcity. Distribution cannot be effectively controlled because information is easy to duplicate. This leads to large percentages of fraudulent use.[2] Since the software industry needs to collect enough revenue to pay its own bills, the result is higher prices paid by a small fraction of users, with a secondary effect of diminishing market sizes.
- Hard to Select. It is difficult and inconvenient to “test-drive” software components and applications, because users are asked to pay the high price of acquisition before being able to determine whether the software is of adequate quality or even needed.
- Hard to Get Fair Revenue. It is difficult to predict actual distribution volumes at the time redistribution arrangements are made. For simplicity, many such arrangements are based on a flat fee. Inevitably, many end up being unfair to one of the parties, with negative effects on the entire industry.
An unprofitable component market deprives the software industry at large of:
- Well Crafted Components. Components should be produced by the best specialists in the relevant technology. However, there is no incentive for them to enter this market, since there is little chance that their efforts would pay off.
- Higher Quality Infrastructure. Most of the industry’s focus is on producing applications — the only merchandise one can make real money on. This strong bias has negative long-term effects on the quality of the software infrastructure and the specialized components out of which the industry builds these applications.
- Slower development of technology. Fewer quality components leads to less reuse and more reinventing the wheel.
The natural solution to all of these problems is to decouple delivery and revenue collection: make the delivery mechanism direct, easy, and largely free, and then use a separate mechanism that insures collection and proper allocation of revenue. The only charges at distribution time should be to cover media manufacturing (including printed documentation, if any), and physical transportation, if any. These charges can also be eliminated in many (but not all) instances through delivery via high-speed networks.
A simple solution, indeed. Why has it not happened? Reasons are multiple, including:
- Cultural Barriers. We’ve done business in one way for over 40 years now. The basic methods were established in an era where mainframe software was the predominant product. Additional techniques were added with the advent of standalone personal computers. While most of the software (by revenue) to be sold over the next decade will not fall into either of these categories, the culture that generated the practices is still strong.
- Opposition by Monopolies. The large monopolies perceive change that may establish a fairer way of compensating value, emphasizing quality, and encouraging the small but highly skilled producer to be not in their best immediate interest. While one could argue that this is just a matter of perception, and that in fact change is in everybody’s best long-term interest, the perceptions remain and strongly influence the attitude of many of the larger participants in this industry.
- Absence of Supporting Infrastructure. To actually effect such a change, a simple, secure, flexible, and general purpose infrastructure must exist and support the new manner of collecting revenue well. In its absence, the discussion remains academic.
While we recognize the importance and seriousness of the first two barriers listed above, we are not addressing them here.[3] This paper is about the third barrier. Our thesis is that such a technological infrastructure now exists. We are presenting both a model and a concrete, industrial-quality, commercial implementation of it, as part of the Kala technology and persistent data server product.
Revenue Collection
To be useful in practice, the revenue collection mechanism must satisfy several requirements:
a. Be safe.
- The mechanism must address safety very seriously, so that it seen as truly solving the revenue loss problem, as opposed to replacing it with another variant of it. Thus, the mechanism must be foolproof against major fraud.
b. Be recursive. The mechanism must not only allow the collection of revenue, but also the allocation of some portion of it to subsidiary suppliers. This reflects the components-made-out-of-components structure of software.
c. Be flexible. The mechanism must be just that: a mechanism. It should allow the component vendor the maximum flexibility to establish policies and reflect business arrangements and special cases.
d. Be efficient. The mechanism must introduce very little, if any, overhead to the normal functions of the components and applications it supports.
e. Be invisible. The mechanism must be largely transparent, and simplify customers’ lives, rather than become a nuisance like dongle chains.
There are two principal arrangements possible between the producer and the consumer of a component:
- Pay-per-use. This is an arrangement whereby the consumer pays the producer for as much of the producer’s software as the consumer’s software actually uses. The measurement of use is specified as part of the arrangement. This technique is often referred to as metering.
- Pay-per-user. This is an arrangement whereby the consumer’s software is permitted to use the producer’s software for a fixed period of time in return for a fixed fee, independent of whether or how much the consumer’s software actually uses the producer’s software. This technique is usually known as licensing, and sometimes referred to as pay-per-copy.
The pay-per-user technique is certainly the dominant one in today’s software industry, but the pay-per-use technique is hardly unknown. Pay-per-use is used extensively by utilities (your gas and electricity consumption is metered, and so is most of your telephone use), postal services (through the now widespread postal meters), city services (parking meters), music industry (jukeboxes), etc.
In the information industries, pay-per-use is employed extensively by information database providers (e.g., reference searches, legal databases, medical databases), bulletin board operations, and consumer information providers (e.g., CompuServe, Prodigy).
For component distribution and revenue collection purposes, we submit the following additional requirement:
f. Provide Dual Technique.
- Both pay-per-use and pay-per-user arrangements must be supported; metering becomes the default mechanism in the absence of any pre-paid license.
We motivate this requirement with an example involving end-users and an application. Similar examples can be constructed to involve software components only.
Suppose that you are the manager of a medium-size software development group, say 30 people. You have 25 software engineers and 5 technical writers. Your platform is a network of Unix workstations. You must purchase an authoring system to be the technical writers’ main tool, and also to be used occasionally by the software engineers. Typically, you’ll be presented with products based on floating licenses.
You know that your writers will use the system every day, intensively. You also know that your engineers will rarely use it, but once a month they will all want to use it simultaneously to write their status reports to the management. The question is: how many floating licenses should you buy?
If you buy 5, then either no engineer will be able to use it, or they will constantly fight over licenses with the writers. This decision will waste you time, energy, and perhaps even people!
If you buy 30, then everybody will be happy, except for your CFO: you will end up with 25 licenses sitting around unused for most of the time. This decision will waste you quite a bit of money!
If you buy any number between 5 and 30, you’ll still waste purchasing money and still have to force people to come to work at odd hours to abide by their licenses.
You don’t have to worry about any of the above if the application offers both pay-per-user and pay-per-use. You buy 5 licenses to satisfy the predictable, steady use by the writers. You also pre-pay some amount of use, and have the application run off the meter any time more than 5 people try to use it. If you run out of meter, you call your vendor with your credit card and buy more. Problem solved: save both headaches and money at the same time with a simple but flexible approach.
THE RESOURCE MODEL
This section introduces the resource management conceptual model of metering and licensing. We introduce several new notions, including resource, vendor, account, etc. We also explain in detail the concept of acquiring a resource, and the resource acquisition algorithm.
Resources and Sub-resources
A resource is an abstraction representing access to a software component, such as:
- software subsystem (e.g., a math library, a persistence library, etc.), or
- data (e.g., a font family, an encyclopedia entry, a stored movie, etc.), or
- generally, an object or cluster of objects.
The relationship between a resource and the related software component is such that one can only access the component via the associated resource.
Accounts, Vendors and End-Users
Each resource has an account, which contains the current balance, measured in meter units. If the account has a negative balance, the resource owes units to one or more resources. If the account has a positive balance, the resource is owed units by one or more resources.
Meter units are the currency in which all transactions between resources take place. Meter units are converted to cash when revenue is distributed to or collected from vendors.
Each component and the corresponding resource is owned by a vendor. The vendor can be the manufacturer of that component, an agent for the manufacturer, or anyone who has acquired the legal right to sell access to that component.
For accounting purposes, end-users are also represented by resources. Thus, each end-user’s resource has an account. This account is debited any time the end-user uses metered resources, and credited any time the end-user purchases more meter units for cash. The end user may be a real person (based on whatever the local system uses for user identifier), budget pseudo-people (virtual users set up simply as means to implement budgeting classifications), or an installation as a whole if finer grain accounting is not required.
Periodically payments are made to the vendors whose resource’s accounts had positive balances.
In summary, resources deal in meter units, while vendors (and users) deal in monetary currency (e.g. U.S Dollars, Deutsche Marks, etc.).
The Structure of a Resource
A software component uses other software components to implement its functionality. Correspondingly, a resource uses other resources, which become its sub-resources. In Figure 1, resource A uses resources X, Y, and Z, which are its sub-resources.
Each resource is identified by a resource identifier (or a rid). Resource identifiers are universally unique, so that accounting integrity is preserved.
Thus, conceptually, a resource has the following components:
- a resource identifier,
- a set of sub-resources,
- an account with a balance, and
- an associated software component.
Resources are implemented as persistent objects, subject to the same persistence and visibility properties as any other object in the Kala system.
Licensed vs. Metered Use
The use relationship between a resource and any of its sub-resources can be based either on a license or on a metered basis. The subsections below explore in detail each of these two alternatives.
Licensed (“pay-per-user”) use
A license is a deal between a grantee resource M and a grantor resource N whereby N grants to M’s component access to N’s component for a certain period of time, in return for a pre-negotiated license fee (see Figure 2).
In this context, the license fee is the monetary exchange between the vendors that own the two resources M and N, or between an end-user represented by resource M and the vendor that owns resource N.
A license is implemented as a persistent object in the system. The mere existence of a license object implies that the license fee has been paid. The connection between the existence of a license object and the actual payment for the license can be enforced by the software under certain circumstances, explored in more detail in the Section on “The Architecture”.
The license duration is the time for which a license exists. License durations can be expressed either as elapsed time (measured in days) or as a fixed date, denoting the license’s expiration time. A perpetual license is a license whose duration is infinite. A temporary license is a license whose duration is finite, and usually shorter than the usefulness of the granting component.
Thus, a license consists of:
- Grantor. This is the rid (resource id) of the resource granting access to its component.
- Grantee. This is the rid of the resource whose component gains access to another component. This may be wildcarded, i.e. `any using resource’ or specified by predicate.
- Duration. This is the time validity of the license.
A licensed use engenders a fee regardless of whether or not the licensed resource (the grantor) is used or not. Through a license, the grantee gains access to the grantor’s associated component without additional charge, but the grantee need not actually access it.
Metered (“pay-per-use”) Use
A metered charge is an exchange between a grantee resource M and a grantor resource N taking place at execution time, whereby N grants to M’s component access to N’s component in return for a metered fee.
- The potential grantor’s provisional charge. Each resource defines charges (in meter units) that it will ask for if its component is requested. A provisional charge is an object that specifies both a potential grantor and a potential grantee, thus allowing different charges to be applied to different requestors. These party specifications can be wildcarded. The model does not specify how the charge is defined, what are the terms, etc. This is a matter of policy, left to the users of the resource manager to negotiate and define.
- The potential grantee’s acceptable provisional charge. Each resource defines a method by which it decides whether it will accept a charge or not. While the model allows this definition to be associated with a resource, it does not specify how this acceptance should be determined. This is a matter of policy, left to the users of the resource manager to define for their resources.
The metered use involves a runtime provisional charge acceptance step. Once the potential grantee accepts the potential grantor’s provisional charge, the access is granted. Thereafter, metering engenders a fee only if the granted resource is actually used. Upon access (use), the resource manager debits metered units from the grantee’s account and credits them to the grantor’s account.
The transfer is done by the resource manager after completion of all use of the granted component, according an actual charge definition presented by the grantor resource and accepted by the grantee. This actual charge is checked for error and inconsistency against the provisional charge and acceptance is recorded during the resource acquisition phase prior to the grant of access.
The Resource Graph
For both licensed and metered use relationships between resources and their sub-resources, the totality of resources that make up an application form a directed graph, called the resource graph. The resource graph is not a tree because some components may be independently used by several different components that enter into the making of an application.
For the purposes of the model detailed in this paper, we assume the resource graph to be static. That is, its structure is determined at a time prior to the execution of the application. For example, this could be at static linking time, or at application definition time.[4] In other words, for simplicity we assume that the knowledge of all components that could be potentially used by an application is present before the application is actually launched.
The model is easily extended to allow for a dynamic resource graph. This provides for the general case in which the set of components potentially used by an application is not known at application launch time.
The resource graph has a root node, corresponding to the resource associated with the application. In the example in Figure 4, the root node is A. The set of all nodes in the graph is obtained by the transitive closure of the use relationship.
The example in Figure 4 shows the resource U corresponding to the end-user who runs the application. It also shows B and C having self-pointing arrows. These arrows indicate that both B and C add value beyond the value acquired from their own sub-resources (K in C’s case, none in B’s case), and therefore their own use is not free.
Acquiring a Resource: The Basic Algorithm
Acquiring a resource is a recursive process, starting from the root of a resource graph and working its way down until all resources have acquired all their sub-resources. There are three kinds of information that are used in the process:
- the resource graph,
- the existing license objects, and
- the provisional charge and charge acceptance definitions associated with each resource.
When an attempt is made to acquire a resource X, the following algorithm is followed:
Step 1: For each of X’s sub-resources Y: 1.a Attempt to acquire Y. 1.b If successful, then go to next sub-resource, if any. 1.c If Y requests a charge, and there is a license from Y to X or any parent of X, then acquire Y with license. 1.d If Y requests a charge, and there is no license for Y, then accumulate charge. Step 2: Add local added value to accumulated charge. Step 3: If X’s parent has a license for X, then 3.a Accept provisional charges from all X’s sub-resources, and remember to pay all charges to X’s sub-resources from X’s account. 3.b Return success. Step 4: If X’s parent has no license for X, then propose to charge accumulated charge to parent. Step 5: If X’s parent accepts provisional charge, then 5.a Accept provisional charges from all X’s sub-resources, and remember to pay all charges to X’s sub-resources from the actual charge received from X’s parent. 5.b Return success. Step 6: If X’s parent refuses the provisional charge, then return failure.
As the algorithm shows, negotiations take place between a resource and each of its sub-resources. The negotiations take place entirely outside the resource manager, which is totally unaware of the nature, methods, and means of these negotiations. A negotiation may be a complex dialog between the two resources, or may be empty (no negotiation at all).
However determined, the result of the negotiation is communicated to the resource manager by both parties. The potential grantor communicates to the resource manager a provisional charge (in Step 4), while the potential grantee communicates a provisional acceptable charge (in Steps 3a and 5a).
The resource is able to acquire the sub-resource if it either has a license for it or is ready to accept metered charges, based on the provisional description of the charges presented by the sub-resource. If neither of these happens, the resource is unable to acquire the sub-resource, and the entire algorithm fails, all the way up to the root of the resource graph. In other words, an application can execute if and only if it is able to acquire all resources in its resource graph.[5]
When proposing or accepting a provisional charge, the resources inform the resource manager of the fact by supplying a pair of two numbers (a range). The lower number represents the provisional minimum charge: if the provisional charge is accepted then the grantor resource’s account will be credited at least that many meter units, whether or not the grantee accepts the final actual charge (see Section on “Charging and Disbursing”). The provisional minimum charge may be zero, but not negative.
The upper number represents the provisional maximum charge. It means that the grantor resource’s account will be credited no more than that many meter units (see Section on “Charging and Disbursing”). If the final actual charge exceeds the provisional maximum charge, the resource manager considers this an error (a sign of potential run-away charges), credits the grantor’s account with only the provisional minimum charge, and refuses to acquire the grantor resource for the grantee resource until the bug is fixed. The provisional maximum charge may be infinity, but not smaller than the provisional minimum charge.
Charging and Disbursing
After having successfully acquired all the resources it needs, an application can now execute. As it runs, some resources are actually used. Some resources may never be used.
As they are used, those components that have been acquired on a metered basis (as opposed to a licensed basis) tally their running charges using their internal algorithms and internal data structures to hold the running tallies. At the same time, those components which acquired other components on a metered basis may also keep a tally of the charges they are expecting to eventually receive from those components based on the actual pattern of usage. This tally too is performed entirely by internal algorithms, possibly based upon information about the grantor resources which was obtained during the negotiation phase.
At the end of the application execution, the grantor resource presents the accumulated actual charge tally and the grantee resource presents the accumulated expected charge tally (as an actual acceptable charge) to the resource manager, which compares them to each other and against the provisional charges specified by the grantor and provisional limits accepted by the grantee resource.
If the actual charges conform to the agreement represented by the agreed provisional charges, the resource manager transfers the amount of metered units actually charged from the account of the grantee resource to the account of the grantor resource. The same process occurs for all components which were provided on a metered basis. These transfers are known as actual charges. They may include charges to the end-user’s account.
The tally by the grantee of expected actual charges is intended to provide a check on the veracity of the grantor beyond the rather broad limits of the provisional agreement. The grantee presents the expected actual charge to the resource manager in the form of a range, and so need not be exact in its calculation of the expected actual charges. Indeed if the grantor is trusted, the grantee may omit the expected tally altogether and present the resource manager with an expected actual charge range of zero to infinity, effectively taking the grantor’s word for the actual charges.
Accounting
Periodically, the resource accounts must be converted into cash, so that the corresponding vendors can be paid cash for the use of their components. This can be done at specific times (such as whenever end-users refill their own resource accounts), or regularly (for example, on a quarterly basis).
The resource accounts conversion is an activity of summarizing the balances of all resources in a resource manager installation, communicating the summary to the agency that does the conversion (the equivalent of the bank), the agency paying the corresponding vendors the equivalent amounts of cash, and finally resetting the paid accounts to zero, ready for the next cycle.
The resource accounts conversion can be carried out manually or mechanically. A manual process involves running a batch program at the installation site, which will create an accounting dump file; sending the accounting dump file to the metering agency (the resource manager vendor); and finally reinitializing vendor account balances at the site.
The same activity can be carried out entirely mechanically over a modem or other transmission line. The activity can be manually started or could even be started automatically (by the resource manager itself), thus making it largely transparent to the end users.
A RESOURCE ACQUISITION EXAMPLE
To provide a simple example, this section traces the execution of the basic resource acquisition algorithm presented in Section on “Acquiring a Resource: The Basic Algorithm” .
The Resource Graph
The example involves four resources: A (the root resource, likely standing for the application), B, C, and K. The resource graph is shown in Figure 5.
We also assume that A has a license for C, and that there are no other licenses. Let’s assume that K submits a provisional charge with a minimum of uK meter units and a maximum of infinity (with the actual charge computed on usage), and that B’ proposes a provisional charge with a minimum of uB units and a maximum of uB units as well (fixed fee).
Tracing Through a Resource Acquisition
The execution of the algorithm in Section on “Acquiring a Resource: The Basic Algorithm” to acquire resource A entails the following sequence of events:
- The end-user attempts to run the application, i.e. the end user’s resource attempts to acquire the application’s resource A.
- A attempts to acquire B (cf. A’s step 1).
- B has no sub-resources, but has a local charge of a minimum uB meter units (cf. B’s step 2).
- B proposes the provisional charge (uB, uB) back to A (cf. B’s step 4). This provisional charge is accumulated by A (cf. A’s step 1d).
- A attempts to acquire C (cf. A’s step 1a).
- C attempts to acquire K (cf. C’s step 1a).
- K has no sub-resources, but has a provisional local charge of (uK, [[infinity]]) which it proposes to C (cf. K’s step 4).
- C has accumulated provisional charges of {(uK, [[infinity]])} (cf. C’s steps 1 and 2), and proposes them up to A.
- A has a license for C, and presents it in response to C’s provisional charge (cf. A’s step 1c).
- C accepts K’s provisional charge, but must commit to pay out of its own account (cf. C’s step 3a).
- Since C accepted K’s provisional charge, K returns success (cf. K’s step 5b).
- C has successfully acquired all its sub-resources, and it returns success (cf. C’s step 3b).
- A still has an accumulated provisional charge (from B) of {(uB, uB)}, and it asks the end-user resource whether it accepts this provisional charge (cf. A’s step 4).
- The end-user resource accepts, either by silent pre-specified provisional acceptance of the charges or interactively by responding “Yes” to the “Accept charges?” dialog box (cf. A’s step 5).
- A accepts B’s provisional charge of (uB, uB) meter units (cf. A’s step 5a).
- B receives the acceptance to its provisional charge and returns success (cf. B’s step 5b).
- A has acquired all its sub-resources, and it returns success (cf. A’s step 5b).
- All components of the resource graph have returned success, and so their respective components have been acquired. A proceeds with execution of its associated component.
- During execution, K internally accumulates the actual charges for the actual use made of its component (as opposed to the provisional charges used during resource acquisition). B need not do this as it is using flat fee charging.
- At completion of execution (signaled by A) B and K present their final bills based on actual usage to the resource manager. B presents a uB* actual charge equal to the uB provisional. K presents a uK* actual charge, greater than or equal to the provisional charge uK.
- The user resource, which knows that it is expecting a uB charge from B, presents an acceptance of a {(uB, uB)} actual charge to the resource manager. C, which has been keeping rough track of the use it has been making of K, presents an acceptance of a {(uK, uK)} actual charge to the Resource Manager, where uK is somewhat larger than the uK* computed by K but low enough to catch any error or cheating by K.
- After verification, the Resource Manager debits uB* units from the user (resource U) and credits them to B, and uK* units from C and credits them to K. The transaction is complete.
Resulting Charges
Since the charge contracts between A and B, and between C and K involve metered usage, the balances of the U (end-user), B, C, and K accounts are modified:
- U’s balance was debited uB* meter units, to pay for the use of B (there was no license for B, nor was there one for any of its ancestors up the chain to U).
- B’s balance was credited uB* units.
- C’s balance was debited uK* meter units, to pay for the use of K (C had to pay this itself, because A had a license for C, and so C could not ask A for payment).
- K’s account was credited uK* units.
THE ARCHITECTURE
This section provides an overview of the architecture supporting the main activities of the resource model.
Three Activities
The resource management model involves three distinct activities and related sets of objects:
- The Definition Activity. This activity creates and modifies resource and license objects. This activity is described in detail in the Section on “The Definition Activity”.
- The Resource Acquisition and Charging Activity. This activity takes place every time an application executes for an end-user. This activity is described in detail in the Section on “The Resource Model”.
- The Accounting Activity. This activity takes place periodically, both at each installation and at the account agency site. This activity is described in the Section on “The Accounting Activity”.
The Definition Activity
Definition is the activity by which resources are defined, licenses are installed, and meters (resource accounts) are filled with meter currency. While the times and frequency of the resource definitions differ from those of installing licenses and filling up meters, the notions are related and share several common properties:
- They all involve interactions between a customer, using one or more applications based on Kala’s resource manager, and a vendor, able to provide the customer with both the application and related licenses and meter currency.
Note that by “vendor” we don’t necessarily mean a vendor of software — ultimately, it is not software that’s being sold here. By vendor, we mean any agency that has acquired the legal right to sell and administer licenses and meter currency for various components and applications. This may be a software distributor, a software manufacturer, an Independent Software Vendor (ISV), an independent licensing and metering authority, or the manufacturers of the resource management software itself.
- They all reflect cash transactions between the customer and the vendor. The cash exchanges don’t necessarily have to mimic the definition actions. However, each such definition action is related to either a past, a concurrent, or a future cash exchange between the vendor and the customer.
- As a consequence of the previous item, they all must be totally safe, thus offering trusted protection against fraud. The Kala Resource Manager insures this safety through a cookie exchange protocol described below.
The Cookie Exchange Protocol
The “Cookie Exchange Protocol” is a mechanism designed to insure the safe and unforgeable definition of resources, installation of licenses and filling of meters at the customer sites. The mechanism is based on the exchange of “magic numbers” between vendors and customers. These magic numbers are also known as cookies.
For each definition action, two cookies are involved:
a. The Customer Cookie.
- This cookie is generated by the customer on the customer computer, and transmitted (either manually or mechanically) to the vendor. The customer generates the customer cookie using the Cookie utility program or a version of it embedded in the application itself. The customer cookie encodes information that makes it unique, reflecting this particular customer site (specifically, this particular Kala-based resource manager instance). The customer cookie identifies the customer uniquely throughout the subsequent activity.
b. The Vendor Cookie. This cookie is generated by the vendor in response to a customer cookie and to information the vendor has about the associated cash transaction (such as whether the customer’s check cleared or the credit card transaction went through). The vendor cookie encodes the originating customer cookie, the vendor’s identity, and the action to be performed on the basis of customer payment. It is generated by the vendor, using a unique per-vendor copy of the NewCookie program. It is passed back to the customer, who uses it to perform the definition action.
The cookie exchange protocol is safe against fraud as long as:
- The vendor’s NewCookie program is safeguarded by the vendor. Since the vendor has material interests in preventing fraud, we assume that it will take good precautionary measures to insure the program’s safety (for example, installing it only on a physically protected, standalone (un-networked) machine.
- The customer’s site is able to generate customer cookies that uniquely identify the site. Satisfaction of this requirement is guaranteed by the mechanism Kala uses to guarantee universal uniqueness of identifiers [6].
- Valid cookies from NewCookie only work on sites which generated the original customer cookie.
- Invalid cookies don’t work at all.
The application developer may embed the customer cookie generation in the application itself, so it can benefit from the already existing Graphical User Interface (GUI), communication facilities, etc. This is done by calling the Kala Cookie API function, which returns a datum of type cookie. The datum can then be either displayed to the end-user (for manual communication to the vendor), or embedded into a message silently sent to the vendor via some communication link (e.g., modem connection, electronic mail, etc.).
Defining Resources
The sub-activity of defining resources is part of the process of “installing” the software on the customer’s computer from the delivery medium (e.g., diskettes, tapes, network, CDs, etc.). A resource is defined in the Resource Manager for each installed component.
To define a resource, the installation program calls DefineResource, a function that is part of Kala’s API. For example, the following defines the K in the example resource graph in the Section on “The Resource Graph”. This resource has a resource identifier K, no sub-resources, and represents some given component. The definition is controlled by a vendor-supplied magicNumber.
rid K = …; cookie magicNumberK = …; DefineResource (K, nilRow, magicNumber, component, state);
The following code fragment defines the C resource in the same example in the Section on “The Resource Graph”:
rid C = …; cookie magicNumberC = …; DefineResource (C, Only (K, 1), magicNumberC, componentC, stateC);
Defining Charges and Acceptable Charges
Once a resource is defined, one can define the provisional charge the resource would present to a potential grantee (another resource attempting to acquire this resource) using the DefineProvisionalCharge function. For example, the following defines the charge presented by the K resource defined above (see the section on “Defining Resources”):
span uK = …; DefineProvisionalCharge (K, Range (uK, maxInt), magicNumberK);
Note that DefineProvisionalCharge (like DefineResource) is controlled by a vendor cookie. The same is true for the next function, DefineProvisionalAcceptableCharge.
This defines an acceptable charge that a grantee (using) resource can accept when charged back by any of its sub-resources:
DefineProvisionalAcceptableCharge ( C, K, Range(uK, maxInt), magicNumberC);
Installing Licenses and Refilling Meters
Finally, an application’s code can install licenses or refill meters using two additional Kala API functions: InstallLicense and RefillAccount. They both require a vendor cookie to operate.
For example, the following installs 2 one-year licenses of resource C to resource A:
rid A = …, C = …; InstallLicense (A, C, 2, 365, magicNumberC);
To refill U’s account with 100,000 meter units, you call:
rid U = …; cookie magicNumberU = …; /* from meter vendor */ RefillAccount (U, 100000, magicNumberU);
The Accounting Activity
The accounting activity has three parts; the first and the last take place at the customer site, and the middle takes place at the accounting vendor’s site:
a. Balance Information Collection.
- This activity takes place periodically. It consists of (i) summarizing the account balances (their magnitude, not the actual units or money) for all resources defined at the customer site, and (ii) communicating this data to the accounting vendor. The communication can be either manual (via paper, removable magnetic media, etc.) or mechanized (via modem and telephone lines, high-speed network, etc.).
b. Accounting. This activity takes place at the accounting vendor site. The balance for each resource is merged with the corresponding accounts for the same resource from other customers, and those with net positive balances trigger cash payments to the corresponding vendors.
c. Balance Reinitialization. Upon successful delivery of balance summary information (per step a. above), the balance of each resource account at the customer site is brought to zero.
The Resource Acquisition and Charging Activity
This activity was described in detail in the Section on “Acquiring a Resource: The Basic Algorithm”. Here, we need only mention two Kala API functions called in the process. The first is the function that starts the resource acquisition activity: AcquireResource. This function is called by the application as part of its initialization. For example, if the application’s resource id is r, the following call acquires the application component on behalf of the end-user:
p = AcquireResource (r, ResourceOfClient (myCid), 1);
The call above makes use of the second relevant Kala API function: ResourceOfClient. Given a client identifier (for example, myCid, the well known wildcard identifier of the calling client process itself), ResourceOfClient returns the resource identifier associated with that client.
If resource acquisition (and all sub-acquisition) was successful, AcquireResource returns a pointer to the component associated with the acquired resource. The Resource Manage automatically loads the component from the persistent store. If the resource acquisition activity fails, the pointer is nil. Because the components are kept on protected and inaccessible persistent store by Kala, the application has no way to get at any of the components other than through a successful AcquireResource.
COMMON BUSINESS MODELS
The resource management model and its implementation as part of the Kala technology is useful in practice only as long as it is able to support useful and desired business models. A good test is to explore its support for a few simple ones in wide use.
While this section only explores a few simple models, many more can be implemented atop Kala’s resource management primitives, opening the doors to creative business deals that are both mechanically and legally enforceable, and inexpensive to administer.
Perpetual Floating Licensing
Contemporary software implemented on network computers commonly employs perpetual floating license schemes. These schemes allow up to a specific number of users to use the application concurrently. The number can be increased by purchasing more licenses. Once purchased, a license never expires. If a site has N licenses and the (N+1)[th] user attempts to access the application, she gets a message informing her that the system is temporarily out of licenses, and that she needs to wait until one of the current users logs off this application.
Such a perpetual floating licensing scheme can be implemented trivially using Kala’s resource management mechanism. Perpetual licenses are implemented as Kala licenses with infinite durations (represented as maxInt values). For each application (or component) subject to such a licensing scheme, a resource will be created as part of that application’s (or component’s) installation.
We assume that Kala’s own installation (the coldKala program) installs the K resource. The application’s own installation program contains the following code fragment:
rid A = …; mid midOfAnEntryPoint = …; DefineResource (A, Only (Account(K,0)), receivedCookie, midOfAnEntryPoint, nilMid);
In the fragment above, midOfAnEntryPoint is the identifier of application A’s entry point segment, to be loaded into memory from the persistent store and branched to for execution upon a successful acquisition of A’s resource.
The application has a user interface (e.g., part of its GUI) that provides the application administrator the means to:
- generate customer cookies to request additional floating licenses,
- add new (paid for) licenses, using vendor cookies, communicated either by telephone (voice), or mechanically via some form of connection between the application site and the vendor’s site (e.g., modem connection over regular phone lines), and
- inquire about the status of licenses and meters, such as how many licenses are currently installed, etc.).
The application can run either with or without a license for Kala. In the former case, no further exchange takes place between A and K. In the latter case, the meter units consumed by application execution will be debited from A’s account and credited to K’s account when application execution ceases.
A typical user site scenario is:
a.
- The application administrator (likely the same person who administers networks, etc.) clicks on the application’s menu item reading “Add another license”.
b. The application presents the administrator with a dialog box. The application administrator fills out the quantity desired (defaulting to 1) and the credit card number and expiration date (no default, for privacy reasons). Then he clicks on the OK button.
c. The application silently sends electronic mail to the vendor, containing the above information and a locally generated client cookie.
d. The vendor silently responds with a vendor cookie.
e. The application receives the electronic mail from the vendor and issues a call to
DefineLicense (A, installation, 1, forever, vendorCookieA);
to install the license to A.
f.
- If the agreement between A’s vendor and Kala’s vendor specified that each sale of a license for A will also include a sale of a license for Kala (one of the many possible arrangements), then a license to Kala is also installed:
DefineLicense (K, A, 1, forever, vendorCookieK);
- Note that a perfectly valid alternative is to assume that licenses for Kala are obtained through a completely separate channel. For example, Kala may already be installed on that network computer in support of other applications, and blanket licenses (that is, licenses to Kala for anyone who needs them) may already exist.
g. The application sends e-mail to the application administrator, notifying him that the license(s) have been successfully installed.
There are many variations and extensions of the perpetual floating license scheme, both with respect to what is being licensed and to how the licenses are administered. The example above suggests a more mechanized, transparent and easy-to-use approach, involving a minimum amount of effort on the customer’s side and a minimum amount of labor on the vendor’s side. Indeed, a win-win situation.
Flat Annual Royalty Arrangements
Another commonly practiced licensing scheme is that of a flat annual royalty. In this scheme, if an application A uses a component B, A’s vendor obtains the permission to dispense an unlimited number of licenses to B in return for a flat annual fee. Other legal limitations may occur, and some may be enforceable through software. However, we will ignore them here for simplicity. We also assume that A’s vendor sells its application under a perpetual license agreement.
When A’s vendor pays B’s vendor the agreed-upon annual fee, B’s vendor gives A’s vendor a NewCookie module that generates cookies for 1-year licenses from B to A. A’s vendor delivers the B upgrade module to its own customers as part of an annual upgrade of the A application. The B upgrade module silently installs up-to-date licenses to B, so A’s customers can continue to use the embedded B without charge (they may actually not be even aware of the existence of B!).
This scheme assumes an explicit module upgrade. While these upgrades of B-to-A licenses are not relevant to A’s customers, they can be hidden inside other kinds of upgrades of A, such as annual A software releases, etc.
If the customer does not install the upgrade, A will continue to run even though the local (sub)license from B to A has expired, so long as the B component was written to fall back to pay-per-use. Absent a license, B will run off a meter so long as the end-user’s resource accepts the provisional and actual charges. This inconvenience can be avoided by providing the customer with strong enough incentives to upgrade.
If A’s vendor (who has sold perpetual licenses to its customers) fails to buy and deliver to its customer the necessary B module upgrade (so that the customer can use B as part of A without charge), then the customer has the same legal complaint against A as for any other failure to deliver contracted upgrades. This presents an incentive to A’s vendor to provide the necessary upgrades.
As in the example in Section on “Perpetual Floating Licensing”, the process can be made quite smooth by employing silent transfer mechanisms such as electronic mail or direct connect via modems over phone lines. Since most sites (organizational and residential) are now equipped with such devices, and since the amount of data to be transferred is fairly modest, these options are now more practical than ever.
Metered Use of Kala as a Repository
Another simple application occurs where passive objects are provided under a metered arrangement. For example, a vendor of clip art may place an entire clip art collection on a Kala-managed CD-ROM (see [7],[8] for more information on Kala’s persistent store functionality).
The vendor distributes the collection for no or low cost (perhaps enough to cover manufacturing costs in part). The arrangement is that each clip is paid for on a usage basis: a small amount is charged every time a drawing program loads a clip and inserts it into a drawing.
The drawing program is implemented so that it cannot be used to make any further copies of the clip. Kala’s Resource Manager doesn’t really enforce this if the clip is to be truly passive, i.e. usable by a lot of applications. The application must have an internal (memory) representation for the art clip, and Kala has no means to prevent the application from writing out the internal representation and reusing it. Here, the actual protection comes from the fact that commercial drawing package developers will have no incentive to allow such loopholes — it is in their best interest to protect the economic interest of clip artists, so that they can continue to supply them with high quality clip art.
An individual programmer may find ways to break this protection; however, if the cost of clips is low enough, it would be too much trouble for what it was worth. Pricing strategy plays an important role here. The vendor of a clip art library should price the product such that if every clip was referenced once, the total meter credit would be more than what he would sell an unlimited license for anyway.
In the implementation, Kala holds clips as persistent data. Access to these clips is securely controlled using Kala’s data visibility functionality. Drawings using these clips can also be held as Kala data.
Each clip has a resource object associated with it. Each “handle” to a clip is set up to acquire the clip’s associated resource. The model supports embedded clips as well.
The end-user (or the site, if accounting is on a site basis) periodically fills up his account with some quantity of meter currency. The end-user resource accepts charges as long as its account balance is positive.[6]
When a clip needs to be loaded into a drawing, if the proposed charge is accepted by the end-user resource, the actual charge is credited to the clip’s resource account. Periodically (for example, on a quarterly basis or when the customer purchases more meter currency), the accumulated accounting information is sent to the vendor.
Clip art may be supplied by many artists. The clip art vendor can, using the detailed accounting data received from the customer, distribute the proportional revenues to the clip artists. Thus, the small but highly skilled contributor can get actual revenue from his or her work, without placing an excessive burden on the revenue collection system — a simple accounting computation. The underlying mechanism is very similar to the one ASCAP uses to convey a portion of each coin in a jukebox to the author of the song played.
Free (Unlicensed) Use
A degenerated use of the model occurs when a component is offered for free use to anyone who needs it. In this case, the code fragment that installs such a “nil license” for a resource X is:
DefineLicense (X, anyone, maxInt, forever, aCookie);
Here, a virtually unlimited number of users can use component X indefinitely.
SUMMARY OF THE API
This section summarizes Kala’s resource management interface. The interface (API) is shown as C function declarations, although other language interfaces will be supported.
Resources, Relationships and Accounts
DefineResource defines a resource and its “use” relationship to a suite of other resources, expressed as a row of resource. It associates a resource with a component.
void DefineResource (rid resource, rowRid subResource, cookie magicNumber, mid component, mid state);
InstallLicense defines one or more pay-per-user (license) relationships between a grantor resource and a grantee resource, based on a cash payment. The license is for a given number of seats, and has a given time validity, measured in days.
void InstallLicense (rid grantor, rid grantee, span seats, duration validity, cookie magicNumber);
RefillAccount credits a resource’s account with a given number of meter units, based on a cash payment.
void RefillAccount (rid resource, span units, cookie magicNumber);
Provisional and Actual Charges
DefineProvisionalCharge states that a resource can allow access to its associated component (see DefineResource in the Section on “Resources, Relationships and Accounts”) in return for an expected charge. A provisional charge is defined to be a range, indicating a minimum and a maximum (see the Section on “Resources and Sub-resources”).
void DefineProvisionalCharge (rid grantor, rid grantee, urange charge, cookie magicNumber);
DefineAcceptableProvisionalCharge states that a grantee resource is willing to accept an indicated provisional charge.
void DefineAcceptableProvisionalCharge (rid grantor, rid grantee, urange charge, cookie magicNumber);
Charge allows a grantor resource to present a grantee resource with a given actual charge, measured in meter units.
void Charge (rid grantor, rid grantee, span units);
AcceptCharge allows a grantee resource to accept an actual charge from a grantor resource. The accepted actual charge is given as a min/max urange (range of unsigned integers), so that the match does not have to be exact.
void AcceptCharge (rid grantor, rid grantee, urange charge);
Acquiring Resources
AcquireResource acquires a resource for a potential grantee resource (the caller of this function). If successful, it secures access to the resource’s component for the grantee’s component. It can acquire the resource a quantity number of times. If successful, it returns a pointer to the grantor component, now in memory.
pointer
AcquireResource (rid resource, rid grantee, span quantity);
ResourceOfClient returns a client’s associated resource, expressed by its identifier (rid). The client is identified by its client unique identifier (cid).
rid ResourceOfClient (cid client);
Cookies
Cookie generates a new local installation cookie, to be passed to the vendor, along with some request and cash payment.
cookie Cookie (void);
Accounting
CreateAccountingSummary computes the summary of accounts in an internal format and uses Kala facilities to create a new Kala persistent datum to hold the summary. The newly created datum is pointed to by a Kala handle located at <kin, basket>, using usual Kala addressing [7]. The resulting datum can thereafter be copied to a file, sent to the vendor site via electronic mail, or moved between Kala installations using regular Kala facilities.
mid CreateAccountingSummary(kid kin, bid basket);
CONCLUSIONS
In the Section on “Revenue Collection” we outlined a few requirements for a practical revenue collection mechanism independent of the software distribution mechanism. To conclude this brief overview of Kala’s resource management functionality, we are reviewing how Kala meets these requirements.
a. Be safe.
- Kala meets this requirement by a combination of several factors: (i) the resource model requires components to be accessible
only
- via their resource objects; (ii) Kala provides a secure storage of data, whereby applications have full control over who can see what and when, via the data visibility primitives (see [7] for a complete discussion of Kala’s main data visibility mechanism, the Kala Basket); and (iii) the dual cookie device permits rights to be communicated between vendors and customers without the need for expensive or cumbersome communication safety provisions.
b. Be recursive. Kala’s resource management model meets this requirement by recognizing that, with respect to licensing or metering, arbitrary components are no different from applications which are no different from passive data. The model explicitly calls for resource graphs.
c. Be flexible. Kala’s model does not impose any policies. It imposes no practical restrictions on how the business deal is structured, how the licenses or the meters are administered, what mechanism is used to communicate between vendors and customers, etc. As long as a policy does not violate the other requirements discussed here (for example, the safety requirement), it is implementable using Kala’s resource management primitives. This feature sharply distinguishes Kala from all other license managers (commercial or research). The immediate effect is simplicity and interface economy.
d. Be efficient. Kala’s model was designed to minimize the number of communications between the application/component code and the resource manager. The result is an implementation that brings very little overhead, unnoticeable in practice.
e. Be invisible. Kala’s toolkit approach makes it possible to fully integrate all license and meter management with the application (and under some schemes even hide them inside).
f. Provide Dual Techniques. Kala provides support for both the “pay-per-user” and “pay-per-use” approaches, and does so by linking them together, so that “pay-per-use” becomes the default in the absence of available licenses.
A restricted version of this model has been part of the Kala persistent data server product since its 2.2a version. This model is part of Kala’s 3.x version. Extensions to it are also expected.
NOTES
1. Kala is a Trademark of Penobscot Development Corporation. Portions of the technology described herein are covered by pending US and international patents.
2. Many have pointed out that there is more software and information being used without payment than there is legitimate use.
3. We are, however, encouraging everyone to explore these topics and devise ways to overcome these serious barriers.
4. Application definition with respect to the component repository, i.e., at application installation.
5. This restriction can be relaxed in the case of a dynamic resource graph.
6. It is possible to allow account balances to become negative. This corresponds to extending some amount of credit to a customer, much as a charge account bank would do.
BIBLIOGRAPHY
[1] Cox, Brad, What if There Is A Silver Bullet, Journal of Object Oriented Programming, June 1992. [2] Hemnes, Thomas M.S., Esq., Software Revenue Generation in Network Environments, Ropes and Gray, Massachusetts Computer Software Council Annual Legal Update Program, November 1992. [3] Miller, Mark, On Software Pay-Per-Use, private conversations, June 1992 and January 1993. [4] Mori, Ryoichi and Maraji Kawahara, Superdistribution: An Overview and The Current Status, Technical Reports of the Institute of Electronics, Information, and Communication Engineers, Volume 89, Number 44. [5] Penobscot Development Corporation, The Kala Archives, available via anonymous ftp from world.std.com at ~ftp/pub/kala. Send mail to kala-request@world.std.com for more information. [6] Penobscot Development Corporation, The Kala Forum, by free on-line subscription only. Send requests to kala-request@world.std.com. [7] Simmel, Sergiu S. and Ivan Godard, The Kala Basket — A Semantic Primitive Unifying Object Transactions, Access Control, Versions, and Configurations, Proceedings of OOPSLA’91, October 1991, pp. 240-261. [8] Simmel, Sergiu S. and Ivan Godard, Objects of Substance, BYTE, December 1992, Volume 14, Number 17, pp. 167-170. [9] Simmel, Sergiu, Software Licensing and Metering with Kala — Infrastructure for a New Economics of Software, Hotline on Object-Oriented Technology, Volume 3, Number 4, pp. 3-7.GLOSSARY OF TERMS
account — constituent of a resource, holding a balance of meter units
actual charge — the amount of meter units a grantor resource asks a grantee resource to pay for its actual use of the grantor’s services during an execution
actual acceptable charge — he amount of meter units a grantee resource expects or is willing to be charged by a grantor resource for its actual use of the grantor’s services during an execution
component — small-grain constituent of a software system
customer cookie — magic number generated by the customer on the customer computer, and transmitted (either manually or mechanically) to the vendor
definition — activity by which resources are defined, licenses are installed, and meters (resource accounts) are filled with meter currency
distribution — mechanism by which a component is made available to another component or final consumer (end-user)
end-user — real person (based on whatever the local system uses for user identifier), budget pseudo-people, or an installation as a whole if finer grain accounting is not required
license — deal between a grantee resource M and a grantor resource N whereby N grants to M’s component access to N’s component for a certain period of time, in return for a pre-negotiated license fee
license fee — monetary exchange between the vendors that own the two resources M and N, or between an end-user represented by resource M and the vendor that owns resource N
license duration — time for which a license exists
licensing — see pay-per-user
meter units — currency in which all transactions between resources take place
metering — see pay-per-use
pay-per-use — arrangement whereby the consumer pays the producer for as much of the producer’s software as the consumer’s software actually uses
pay-per-user — arrangement whereby the consumer’s software is permitted to use the producer’s software for a fixed period of time in return for a fixed fee, independent of whether or how much the consumer’s software actually uses the producer’s software
provisional charge — a formulation of the amount of meter units a grantor resource may charge if the resource is used
provisional acceptable charge — a formulation of the amount of meter units a resource M would accept to be charged for the use of another resource N
resource — abstraction representing access to a software component
resource accounts conversion — activity of summarizing the balances of all resources in a Resource Manager installation, communicating the summary to the agency that does the conversion (the equivalent of the bank), paying the corresponding vendors the equivalent amounts of cash, and finally resetting the paid accounts to zero, ready for the next cycle
revenue collection — mechanism by which payment for a component is made to reach the producing vendor, regardless of the context in which the component is actually used
resource graph — the graph of resources related by the user relationship, with the application’s resource as the entry node (root)
rid — resource identifier
subassembly — medium-grain constituent of a software system
vendor — manufacturer of a component, an agent for the manufacturer, or anyone who has acquired the legal right to sell access to a component
vendor cookie — magic number generated by the vendor in response to a customer cookie and to information the vendor has about the associated cash transaction (such as whether the customer’s check cleared or the credit card transaction went through)
BIOGRAPHY
Sergiu S. Simmel, President and Co-Founder of Penobscot Development Corporation, has been involved in the KALA project since 1987. He holds a Master’s Degree in Computer and Information Sciences from University of Minnesota. He has been working in the computer industry as a software engineer and technical manager since 1981. His areas of expertise include CASE systems, hypermedia document management, and object oriented databases.
Ivan Godard, Chief Technologist, is Kala’s main designer and implementor, being the main force of the KALA project throughout. Mr. Godard has been involved in the computing industry since 1968 as a scientist, engineer, consultant, and entrepreneur. He contributed to the Aldo168 Revised Report and the design of the Ada Language (the “green” version). His areas of expertise include language design, translation technologies, and object oriented databases. Mr. Godard has taught computer science at graduate and post-graduate level at several universities including Carnegie-Mellon University and University of Maine.
The authors can be reached at:
Penobscot Development Corporation One Kendall Square, Building 200, Suite 2200 Cambridge, MA 02139-1564 voice: (617) 267-KALA fax: (617) 859-9597 Internet: infor@Kala.com
Copyright (c) 1993, Penobscot Development Corporation