Digital Licensing - Computer Science and Computer Engineering

Architectural Perspectives

Digital Licensing Craig W. Thompson and Rishikesh Jena • University of Arkansas

Q

uestions of ownership can block widespread software reuse. Forced to choose between negotiating rights to an existing component and reimplementing it, developers often take the latter option. At least in part, this is because they have less control when negotiating with an unknown party, and such negotiations can be expensive — in time, legal fees, knowledge, and the bookkeeping required to monitor usage. How can we dramatically reduce these costs? A digital license protects an author or owner’s intellectual property rights to regulate how content is sold or used, monitors compliance to terms and conditions, and regulates compensation. The goal of digital license automation is to provide an infrastructure that makes it easy for programs to negotiate with each other when they need services, taking the human at least partly out of the loop. A pervasive, low-overhead digital licensing infrastructure could enlarge the component software marketplace and lead to greater availability of reusable software components.

Digital Licensing Use Cases A use case is “a description of a set of sequences of actions, including variants, that a system performs that yield an observable result of value to an actor.”1 For digital licensing, we can describe simple use cases in two broad domains: Internet Web services and the coming Internet of Things. Web Services Use Case One way the Web is getting smarter is by providing standardized ways for programs to connect to programs. Web services are essentially procedure calls that can access remote programs or databases across the Internet (see www.w3.org/2002/ws/). This type of service-oriented architecture (SOA) provides a standardized way for a requestor to use

IEEE INTERNET COMPUTING

1089-7801/05/$20.00 © 2005 IEEE

a registry to discover and then connect to a provider’s remote services. Web services depend on three specifications: • SOAP provides a remote procedure call mechanism and defines an XML message format in terms of an envelope (the message’s start and end), a header (optional characteristics such as quality of service), and a body (the text itself ). • Web Services Description Language (WSDL) provides an interface description language for remote functions and defines the signature for operations and argument types. • Universal Description Discovery and Integration (UDDI) acts as a registry of service advertisements and defines how Web services are published and discovered. In this digital licensing use case, the Web service developer wants to grant limited rights to any potential consumers, restrict usage in terms of time, number of calls, or resources, and receive compensation. If a digital licensing framework existed, anyone could publish a service and define negotiation, usage, and compensation constraints, and anyone else could negotiate for and use the service under the license’s terms. Internet of Things Use Case The second use case for digital licensing is an expansion of today’s Internet to an Internet of Things in which common objects, including inanimate and abstract ones, become smart devices that “can have individual identities, memory, processing capabilities, and the ability to communicate and sense, monitor, and control their own behaviors.”2 Today, we’re used to paying for things we buy at the store or the services we use (such as hotel rooms). Imagine if every item had ownership and

Published by the IEEE Computer Society

JULY • AUGUST 2005

85


Digital license service

Negotiation service

Digital rights service

Electronic licenses

Service-level agreement (SLA) service

Compensation service

Electronic receipts service

Figure 1. Reference model for a digital licensing service. A negotiation service generates a contract (an XML document) that defines digital rights that control access to a service, further agreements on quality of service payment for services rendered, compensations, and the issuing of electronic receipts. usage restrictions. In such a world, everyday devices — lights, thermostats, and so on — would have network identities, wireless connectivity, and APIs. When you bought a TV, for example, you could bring it home, install it, and then grant digital rights to family members and guests, thus controlling usage. This same approach could also help you monitor telephone or refrigerator use, or ease situations in which users want to pay for only the services they receive or resources they consume. The facilitiesmanagement area is already moving toward smart buildings with highly tunable, controllable environments.3 At the University of Arkansas, we’re currently developing the Everything is Alive (EiA) agent system to explore a scalable, universal wrapper infrastructure for smart devices.4 We want the ability to wrap smart devices, add or remove services dynamically at runtime, and use the wealth of available Web services. EiA uses a modular plug-in composition platform called E2, which we patterned after eclipse.org’s platform, but it also supports plug-in unloading (which lets components be removed), message transport, and WSDL. 5 Because third parties own Web services that use resources on remote machines, we’re also developing a digital licensing framework to automate licensing so that agents can control, manage, and share such resources.

86


Digital Licensing Reference Model

licenses, and regulates their usage to ensure that the service’s terms and condition are met, prevents unauthorized access to the software, and compensates the licensor. Negotiation Service Negotiation involves offers and counteroffers between vendors and consumers until they reach an agreement. The agent community has invested considerable research in exploring various market-based negotiation services; the negotiation process itself can be manual, semiautomated, or automated.

If digital licensing is to become widely useful, it first needs a standard reference model to define its functionality. A reference model is a high-level specification that defines a family of related systems in terms of functional capabilities, thus enabling a comparison of similarities and differences among specific implementations. Accordingly, we should be able to deconstruct the model into a collection of lower-level capabilities that can be separately standardized. As Figure 1 illustrates, a digital licensing service consists of several simpler services (that can also be further deconstructed). Conditions are right for creating an industry-wide reference model for digital licensing: copyright and patent law outlines rights, and repositories of boilerplate licenses are readily available. SOAs, including Web services, exist. Relatively little work has been done toward developing a generalpurpose infrastructure framework for widespread use of digital licensing,6 but some subservices are already being separately standardized. In the rest of this article, we’ll sketch key components of such a model.

Digital Rights Management Service A digital rights management service dynamically enforces the license’s terms and conditions at runtime. The license specifies which operations are permitted or denied. Open Digital Rights Language (ODRL; http://odrl.net) is an example of a rights expression language (REL); we use it in EiA,7 primarily because it is an open standard, has wide acceptance, and is defined in XML. ODRL has four main components:

Digital Licensing Service A licensing server is the administrative hub of the digital licensing service. It brokers negotiations between vendors and consumers, grants

• subject — the service’s creator, end user, distributor, and so on; • object — a resource under license (the title of a song by a certain artist, for example);

www.computer.org/internet/

License: An XML Document The end result of negotiation is a license — an XML document that encodes terms and conditions of use for the object under license. Sections of an XML license can include machinereadable constraints such as digital rights, service-level agreements (SLAs), and micropayments, which we’ll examine in more detail later. The license can also be translated — via Extensible Stylesheet Language Transformations (XSLT), for example — to a textual document for vendor or consumer review. The digital licensing service can manage a repository of licenses.


Digital Licensing

• rights — rules that govern consumption, use, copying, and transfer; and • constraints — date and time intervals, the number of times a resource can be used, or the logical or physical environment in which the license is enforced. A digital rights expression can indicate that a service can be used N times during a certain time period for set purposes, and that the licensee can grant limited rights to third parties. Service-Level Agreement Service A SLA defines an optional section of a license. Although most licenses involve the transfer of rights to a consumer and compensation for service use to the vendor, some licenses also contain penalties — a vendor might agree to pay for underperformance below some quantified level of service, for example. An SLA encodes these conditions and penalties (in XML), and an SLA service monitors them. Compensation Service A license usually defines a compensation scheme and a method of payment. License servers would use compensation models such as: • Pay-me-now perpetual or termlimited licenses. The consumer purchases a license for use of a given object over a specified time period. • Pay-per-user licenses. The license server generates license keys based on the number of standalone applications the service requestor purchases. • Pay-per-use or subscription licenses. The consumer purchases units of usage of some resource, so a license key is generated every time the service is invoked. A trend has emerged toward subscription-based rather than perpetual licenses; in such arrangements, vendors benefit from constant revenue


streams rather than one-time fees, and consumers benefit by paying only for services consumed. Subscription licenses may involve many tiny transactions and payments in fractions of a cent (micropayments). Ongoing research into efficient micropayment systems includes the Micropayment Transfer Protocol (MPTP; www.w3.org/ECommerce/ Micropayments) and Peppercorn. MPTP assumes that the compensation broker is a financial intermediary that can economically handle numerous transactions and keep and aggregate records for both vendors and consumers. Peppercorn’s scheme uses probability sampling rather than transaction aggregation, making charges with fractions-of-a-cent accuracy.

tems, confidentiality, and data integrity. Various standards and specifications already address security concerns, including Secure Sockets Layer (SSL), XML Signature (XMLSIG), XML Encryption, XML Key Management Specification (XKMS), Security Assertion Markup Language (SAML), and Extensible Access Control Markup Language (XACML). Security services are needed in the digital licensing suite of services because the other digital license services must be trustworthy; we must be able to authenticate the parties; and we need ways to encrypt and transmit data securely. Security services provide all these capabilities. Workflow services use graphs of operations that define specified busi-

A trend has emerged toward subscription-based licensing rather than perpetual licenses.

Additional Services Needed Digital licensing will also need several other services. Security services are important because license generators exploit the interoperability in open system architectures. Key issues include secure end-to-end SOAP messaging, access control, identification and authentication of participant sys-

ness processes. Entire workflows and specific services can be licensed together or separately. We could use a workflow rule to map a service description into other service descriptions. For instance, to solve problem W, solve problems X, Y, and Z. This is a natural step toward compositional licensing, in which a license depends on one or more other licenses. Terms of the parent license can’t provide more rights than those contained in the sublicenses. Logging and auditing services provide persistent, trusted record keeping, and an accounting of licensed interactions. They lend assurance that records of transactions can be consulted if needed. These additional services will be needed to make digital licensing services industrial strength, but they are likely to be needed separately for many other purposes. It makes sense



Electronic Receipt Service The electronic receipt service generates a persistent log entry (e-receipt) for each purchase or use of a resource. This e-receipt records which services were used and the form of payment. The service can generate e-receipts for Web services usage, agent interactions, calls to a database, or goods purchased over the Internet or at a store. An ereceipt service can manage accounts for service suppliers and consumers and can provide item or unit-of-uselevel accounting.

87


to separate these concerns and implement these as independent services.

Welihindha, who are prototyping the digital licensing services described here.

Aspects A calling program typically binds directly to a remote Web service by using the service’s WSDL interface. Aspect-oriented software engineering — an architectural style that makes it easier to evolve large software programs — provides a clean way to wrap calls to a service and inject additional behaviors, which could include digital licensing services.8 These licensing services could be interleaved seamlessly in the communication path between the caller and the service. Not all digital licensing subservices are always needed, and many may be subject to various policies. For instance, the electronic receipt service could be useful even without other digital licensing services. Similarly, policy choices might determine what compensation plan to use.

References

Who Benefits? Several communities would benefit from the automation of digital licensing, including the Web services and agents communities. With its focus on sharing computation and data, the Grid community would also benefit from being able to license, monitor, and charge for processing and data as metered commodities.9 The businessto-business (B2B) and business-toconsumer (B2C) communities could also benefit from being able to monitor and control supply chains. Before communities can benefit, however, the middleware community will have to test, improve, and standardize a suite of digital licensing services. The Web service, agent, grid, B2B, and B2C communities can all benefit from a common suite of such services. Acknowledgments This column summarizes ongoing work by the Everything is Alive middleware project at the University of Arkansas, particularly the work of students Aaron Arthurs, Ciprian Caloianu, Kevin Smith, Ryan Von Rembow, and Dilan Angelo


1. G. Booch, I. Jacobson, and J. Rumbaugh, Unified Modeling Language Users Guide, Addison-Wesley Longman, 1999. 2. C. Thompson, “Everything Is Alive,” IEEE Internet Computing, vol. 8, no. 1, 2004, pp. 83–86. 3. R. Mitchell, “The Rise of Smart Buildings,” ComputerWorld, 14 Mar. 2005, www. computerworld.com/networkingtopics/ networking/story/0,10801,100318,00.html. 4. C. Thompson, “Smart Devices and Soft Controllers,” IEEE Internet Computing, vol. 8, no. 1, 2005, pp. 82–85. 5. M. Vu, “E2 Agent Plugin Architecture,” Proc. IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS), IEEE Press, 2005, pp. 26–31. 6. N. Clarke, “Distributed Software Licensing Framework based on Web Services and SOAP,” BA thesis, Dept. of Computer Science, Trinity College, May 2002. 7. C. Caloianu and C. Thompson, “Digital Rights for Agents,” Proc. IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS), IEEE Press, 2005, pp. 492–496. 8. R.E. Filman et al., eds., Aspect-Oriented Software Development, Addison-Wesley, 2005. 9. C. Thompson, “Agents, Grids, and Middleware,” IEEE Internet Computing, vol. 8, no. 5, 2004, pp. 97–99. Craig W. Thompson is a professor and Acxiom Database Chair in Engineering at the University of Arkansas and president of Object Services and Consulting, a middleware research company. His research interests include data engineering, software architectures, middleware, and agent technology. Thompson received a PhD in computer science from the University of Texas at Austin. He is a senior member of the IEEE. Contact him at [email protected]. Rishikesh Jena is a graduate student at the University of Arkansas’ computer science and computer engineering department. His research issues include database management, grids, and agents. Contact him at [email protected].
