🚀 go-pugleaf

===========================================================================
  DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT 
===========================================================================

               Software Licensing & Metering with Kala
           Infrastructure for a New Economics of Software

                        By SERGIU S. SIMMEL

---------------------------------------------------------------------------
            Copyright (c) 1992 Sergiu S. Simmel
---------------------------------------------------------------------------
 For: Hotline on Object-Oriented Technology, Volume 3, Number 4, Feb 1993
---------------------------------------------------------------------------

  In an industry that is furiously embracing object based 
technologies at an increasing rate, one might have predicted that 
the software trade would correspondingly migrate towards a world 
where small to medium software components and aggregates of such 
become a dominant form. Instead, we are experiencing very little if 
any change from the tradition. The products traded continue to be 
the very large, monolithic software conglomerates we call 
applications, platforms, and environments. Why? What happened to the 
object-based technologies' promise of encapsulation, modularity, and 
reuse? Why haven''t they broken and restructured the shape, size and 
economics of software products themselves? Why has the popularity of 
object-based technical principles, languages, and architectures not 
yielded a similar growth in the market size for software components?

  Brad Cox attributes this phenomenon to the fact that "we have 
never developed a commercially robust way of buying and selling 
easily copied intangible goods like electronic data and software" 
[1]. And he is right. We still sell software like potatoes. We 
forget that while potato growers have a good handle on how many 
potatoes there will be on the market (it takes two years for a 
potato to germinate and yield another potato), software "growers" 
don't have a clue: It only takes a few computer instructions and a 
bit more disk space to clone a piece of software.

  As Miller [5], Cox [1], and a few others [7] [8] have pointed out, 
the key to the solution to this economic problem is to decouple 
revenue collection from software distribution. That is, turn the 
ability to easily clone software from a liability into an asset. 
This amounts to distributing the software itself either freely or 
for a very low price (merely to cover media, manufacturing, and 
shipping costs), and charging the customer for its use only.

  Charging for use (sometimes referred to as pay-per-use, metered 
use or meterware) is a new concept in the software industry, but not 
a very new one in general. Other industries have employed it for a 
long time. Your gas company installs a meter in your basement, reads 
the meter every couple of months, and charges you only for the gas 
you actually used. Your telephone company does the same with your 
long distance calls. The City Hall collects parking fees from meters 
(both as voluntary charges and as fines). Even the U.S. Postal 
Office does a similar thing when it fills up your postage meter, 
except that it charges you ahead of time - more like your local gas 
station!

  In many industries pay-per-use has been established as a major and 
often dominant method. However, even there pay-per- use was not 
always the preferred method. However, one can notice that the 
adoption of pay-per-use has been a sign maturity and economic 
realism [8]. We believe that the same evolution is now taking place 
in the software industry.

  Cox refers to this approach of distributing software distribution 
and collecting revenues as "revolutionary" [1]. Throughout the rest 
of this article, I will try to suggest that this approach can 
actually be made as evolutionary as you'd like by complementing it 
with the more familiar "floating licensing".

  The mechanism used to implement this approach is critical to its 
success. In practice, the mechanism required is very similar to that 
used to manage persistent data. It is another facet of the general 
management of visibility of data and services. Vitally, the 
mechanism must be constructed so it leaves policy entirely in the 
hands of software manufacturers. This is necessary so that business 
and market considerations and not technical impositions are the main 
factors determining policies. Throughout, we will be using examples 
drawn from the Kala Persistent Data Server - a software component 
product from Penobscot Development Corporation - which has provided 
an implementation of these "new" concepts for several years now.

-------------------------
Kala and Metered Software
---------------------------------------------------------------------------

  Kala is a persistent data server. It is a software subassembly 
with two areas of functionality:

      managing the storage and retrieval of arbitrary data
      in a high-performance, compact, recoverable, shared,
      secure, distributed, and robust manner, and

      managing the visibility of data for flexible and
      inexpensive support of arbitrary transaction, access
      control, versioning, and configuration models.

  The basis for metered software is the observation that objects are 
trivially able to monitor their own use [1], so long as the monitors 
can be safely and securely stored persistently. Usage monitors are 
nothing but data, and Kala's specialty is exactly the secure and 
safe storage of data. This makes it the natural locale in the 
architecture to deal with these issues. The only question left is 
how we can associate the usage monitor and the datum.

  The Kala facility supporting the pay-per-user approach is called 
SoftMeter™. The SoftMeter works like a postage meter, except that it 
parcels out abstract Meter Units instead of postage. Applications 
can debit the meter (using Kala's API function DebitMeter()) down to 
empty. The putmeter utility program refills the meter, using a key 
provided by the manufacturer or its resellers. The same facility is 
also exposed through Kala's API by the RefillMeter() and 
MeterBalance() primitives.

  DebitMeter() debits a given number of Meter Units from a meter 
counter for the current application's vendor. DebitMeter() succeeds 
silently if there are at least the required number of Units left in 
the SoftMeter. If there aren't enough Meter Units left to satisfy 
the debit then Kala raises an exception.

  In the spirit of flexibility, Kala allows you to replace its own 
(default) persistent data access method with any arbitrary code. You 
can do this on a per-data-item basis [2][3]. For example, you can 
supply a routine that loads the datum from the persistent store 
using Kala's Load() primitive, and then decompresses it (or decodes 
it) using your own decompression (or decoding) algorithm. Since the 
code you supply can be arbitrary, it may call any Kala primitives. 
In particular, it can contain a call to DebitMeter().

  Vendor ids are assigned by Kala's manufacturer, which guarantees 
their uniqueness and establishes a channel through which vendors can 
obtain revenue. Meter Units are sold by the Kala manufacturer or 
resellers. DebitMeter() uses the vendor identifier to record in the 
Kala Store the running total of debits broken down by vendor. 
Periodically this information is transmitted to the manufacturer or 
its authorized reseller, who pays to the corresponding vendors an 
appropriate share of the proceeds of Meter Unit sales. While this 
process is likely to be partly manual at first, it is fully 
mechanizable to the point of requiring no human intervention.

  The scheme is flexible enough to impose few if any constraints on 
the business model of an actual manufacturer - reseller - vendor - 
customer relationship chain. In particular, the point of revenue 
collection and redistribution can be located either with the 
manufacturer, the reseller, or any of the vendors in between.

  Using DebitMeter() in conjunction with the non-default access 
methods and other visibility control primitives, you can implement a 
very simple data access and creation metering policy, a very 
sophisticated one, or something in between. For instance, you can 
choose to meter the access only to certain data; to charge a flat 
fee for any use of the application (regardless of how much data is 
actually accessed); to meter only the initial access to a cluster of 
data but not to individual components; to vary the amount debited 
depending on the data, etc.

  Kala data can be anything that can be represented as bits and 
pointers. In particular, it can be executable code. When programs or 
dynamically linked libraries are stored in Kala, their use can be 
metered using the same general principle.

  As explained above, Kala's SoftMeter is used to monitor the access 
to data or programs stored in the Kala Store. How about Kala's own 
services? When in metered mode, Kala will charge for each of three 
fundamental operations: attaching to a Kala Server, loading a Kala 
datum and creating a new Kala datum. Kala uses internally the same 
DebitMeter() primitive, but now it doesn't charge on behalf of the 
datum's vendor, but on behalf of Kala's manufacturer. The vendor can 
have confidence in the meter system because Kala itself uses it for 
its own revenues.

  Kala's ability to insure the safety and security of the metering 
information is one of the keys to the success of this scheme. Not 
only can Kala's identifiers not be forged, but also Kala's access to 
its data is as secure as the operating environment. Moreover, Kala's 
dynamically managed Persistent Store makes it impossible for someone 
to even pinpoint where the metering information is stored. Kala 
rearranges the Store dynamically to increase performance and collect 
garbage, and in the process moves data around, making clever hacks 
difficult. Even hacking application code to branch around the 
DebitMeter() calls is detectable when the application has been well 
integrated with Kala.

------------------------------
Predictable Usage and Licenses
---------------------------------------------------------------------------

  Basing a major portion of software trade on mechanisms like Kala's 
SoftMeter will require substantial changes in the design, 
implementation, and packaging of the software being traded, as well 
as in its quality. Such changes will not happen overnight. Thus in 
addition to metering, support for conventional licensing is still 
essential. It turns out that a proper implementation of floating 
license preserves the principle of separation between distribution 
and revenue collection mentioned above.

  Licenses do not grant ownership to a piece of software. They only 
grant the right to use it. A Kala License opens a path between a 
Kala Store and the application. A License makes the Kala Store 
visible to the application.

  An application (Kala client) acquires a License by calling the 
AcquireLicense() API function . Licenses can be general (any 
application can acquire the license) or vendor specific (only a 
certain application or an application from a certain vendor can 
acquire it). The function silently returns true if successful, false 
if not. The application decides what to do if acquisition fails. 
Acquired licenses may be surrendered by a call to ReleaseLicense(), 
and any remaining acquired  licenses are automatically released when 
the application detaches from Kala.

  There is an interplay between the metering and licensing 
mechanisms. On one hand, they are independent of each other. An 
application can decide to run off the SoftMeter or to use a license. 
On the other hand, if AcquireLicense() actually fails but the 
application decides to continue, its Kala- related activity will 
automatically be charged against the SoftMeter resources the Kala 
Store may have, if any, for this application. If there are no Meter 
Units left, Kala will raise an exception. An application can use the 
same policy for its own licenses, silently segueing to metering if 
it finds no license installed.

  This dual mechanism is essential to the evolutionary approach Kala 
introduces to software distribution and revenue collection. Let's 
look at a typical example:

  Suppose that you are the manager of a medium size software 
development group, say 30 people large. You have 25 software 
engineers and 5 software writers. Your platform is a network of Unix 
workstations. You are faced with the purchase of an authoring system 
to be the writers' main tool, and to also be usable by the 
engineers. Typically, you'll be presented with a floating license 
based product. 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. What a 
waste of 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. What a waste 
of money! If you buy any number between 5 and 30, you'll be worse 
off because you'll still waste purchasing money and have to either 
force people to come to work at odd hours to get their licenses.

  With a Kala-based authoring system, you don't have to worry about 
any of the above. You can buy 5 licenses to satisfy the predictable, 
steady use by the writers. You also buy some amount of Meter Units, 
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.

  Licensing and metering are not exclusive of each other. Instead of 
replacing each other, they complement each other. The licensing 
mechanism is the best fit for predictable, relatively constant use. 
The metering mechanism is best fit for random, relatively bursty 
use. Since both regimes are common in the actual practice of using a 
shared application, a combination of metered and licensed software 
offers the best of both worlds.

-------------------
The Supplier's Side
---------------------------------------------------------------------------

  Over the past few years the food chain between the infrastructure 
software developer and the consumer has been continuously 
lengthening, and increasingly do so in the future. Platform software 
vendors often sell to the middleware vendors who often sell to the 
application vendors who often sell to the integrators who finally 
sell to the end-user. Licensing and metering trace these often 
complex paths, and must allow the proper disbursements of revenue.

  A licensing and metering mechanism must be flexible to allow 
negotiations and business deals to proceed smoothly, unencumbered by 
technical limitations. For example, the mechanism must be totally 
recursive: each consumer should be able to turn around and become a 
supplier, and in the process use the same mechanism in order to 
satisfy its needs without jeopardizing the negotiated rights of its 
own suppliers.

  Kala accomplishes this by offering access to the entire mechanism 
through its administrative API. You can install Licenses in a Kala 
Store using the API InstallLicense() and ShowKalaLicenseStat() 
functions. Licenses hold information about the vendor (for vendor 
specific licenses), the duration of license validity (as low as a 
day and as long as infinity, to provide perpetual licensing), and 
the number of seats (licenses).

  Installing a license requires a key the user obtains from its 
application vendor. Application vendors get the newlic program which 
generates such keys when they obtain their vendor id from the 
manufacturer. The newlic can only generate keys for that vendor, not 
for licenses for vendors with other ids. Thereafter the Kala 
manufacturer need not be involved in the license granting, sales or 
administration of the application vendor. An alternative is to have 
the manufacturer dispense licenses on behalf of the vendor, at lower 
cost due to volume.

  As with the SoftMeter facility, Kala Stores hold licensing 
information persistently in a totally safe and secure manner. The 
use of a "cookie" (an identifier tag produced at the Kala Store site 
by a supplied utility) in fabricating the license key guarantees the 
one-to-one mapping between licenses and Kala Stores.

  The supplier using Kala licensing and metering can use a 
conventional distribution system, through retail stores, dedicated 
sales staff, or mail order. However, the Kala system opens another 
possible distribution model which may be appropriate for many 
software developers. For example, suppose you are a small garage 
shop that has produced a multi-player interactive game program, 
which stores game history and player state on Kala. You can place 
the game itself on bulletin boards for free, and let users try it 
out on the (small) SoftMeter balance that comes with every Kala 
system without charge. When eventually play exhausts the meter, your 
players will contact the manufacturer or reseller for as many 
licenses (or meter refills) as they need. You in turn get a regular 
check from the manufacturer or reseller, without sales force, 
marketing costs, or hassles. The pricing for each vendor is subject 
to negotiation, and may be structured in any fashion deemed 
necessary to satisfy business needs.

  This model is obviously very much like shareware. It has the 
shareware virtues of low distribution costs (from the developer's 
point of view), and low trial cost and hence low risk (from the 
customer's point of view). With Kala, unlike shareware,  the 
developer's revenue is not determined by the conscientiousness and 
good will of the customer, but by the license and meter policies and 
prices chosen by the developer.

----------
Conclusion
---------------------------------------------------------------------------

  As the software industry matures, its dominant methods for 
software distribution and revenue collection are expected to migrate 
towards a combination between floating licensing and metered use. In 
order to allow the industry to settle on the methods most likely to 
provide long-term revenue streams and discourage massive fraud and 
inequity, the proper infrastructure must be put in place.

  Metering and licensing are complementary, and not exclusive of 
each other. They should be used in conjunction with each other to 
cover both predictable and random use, both constant and bursty 
usage regimes.

  Metering and licensing are specific ways of controlling the 
visibility of data and services based on paid-for rights. To insure 
the safety and security of metering and licensing information, the 
metering and licensing mechanism must be located where persistent 
data is stored and guarded - in the persistent data store. At this 
low level, a persistent data server such as Kala can insure the 
protection and inviolability of licensing and metering information, 
thus guarding the economic interests of all parties involved in the 
software trade: manufacturer, resellers, vendors, and customer.

----------
References
---------------------------------------------------------------------------

[1]  What If There Is A Silver Bullet, Brad Cox, Ph.D.,
     Journal of Object-Oriented Programming, June 1992.

[2]  Kala - Interface Reference Part I: Kala Facilities,
     Sergiu S. Simmel, Revision 2.0, December, 1991,
     Software Version 2.1. [available from Penobscot Develop
     ment Corporation]

[3]  Kala - Main Concepts,  Sergiu S. Simmel, Revision 1.0,
     August, 1990. [available from Penobscot Development
     Corporation]

[4]  The Kala Basket - A Semantic Primitive Unifying Object
     Transactions, Access Control, Versions, and
     Configurations. Sergiu S. Simmel and Ivan Godard,
     Proceedings of OOPSLA'91,  October 1991.

[5]  On software pay-per-use, Mark Miller, Xanadu Operating
     Company, private conversation, July 1992.

[6]  Objects of Substance, Sergiu S. Simmel and Ivan Godard,
     BYTE Magazine, December 1992, Volume 15, Number 1.

[7]  Superdistribution: An Overview and the Current Status,
     Ryoichi Mori, Maraji Kawahara, Technical Research
     Reports of the Institute of Electronics, Information,
     and Communication Engineers, Volume 89 Number 44.

[8]  Software Revenue Generation in Network Environments,
     Thomas M.S. Hemnes, Esq., Ropes and Gray, Massachusetts
     Computer Software Council Annual Legal Update Program,
     November 1992.

===========================================================================
===========================================================================
===========================================================================