|
Search | Back Issues | Author Index | Title Index | Contents |
 |
D-Lib Magazine
|
|
Karen Coyle |
|
IntroductionConcern in digital libraries has turned from, How will we digitize materials, store them and make them available? to, How do we manage the rights along with the materials? Before we can answer that, we need a clear idea of what we mean by rights. This turns out to be a much harder question to answer than, What is the ideal compression algorithm for digital images? Rights takes us into areas of law and business that many of us in libraries have studiously avoided in the past. These are also areas that were not necessary for us to understand, at least not in as much detail, when dealing with analog materials. In this article I reprise the short taxonomy of rights, and technologies that attempt to express those rights, that I introduced in the white paper on digital rights languages produced under contract for the Network Development and MARC Standards Office of the Library of Congress [1]. Obtaining clarity on what we mean by rights and the various approaches to those rights will help us in the process of finding solutions that are appropriate to the library context. The 3 C's of RightsCopyrightThe first C is for copyright, or more accurately, copyright law. Copyright law is the perfect example of what Lawrence Lessig calls "East coast code"—the code of legislation, of government, and of lawyers [2]. Our copyright law today goes far beyond the constitutional promise to "secure for creators, etc." Title 17 of the US Code fills 290 or so pages of text with an intricate set of special interest grants and exceptions, approaching the mind-numbing complexity of our tax code [3][4]. Although it has been common for techno-utopians to declare the Internet, and by analogy all digital media, a "copyright free" zone, copyright law does apply to all forms of intellectual property, whether we accede to the law or not. And it requires no action on the part of creators of digital materials to apply the law to them, not even a copyright notice [5]. So when I author this paper and write "by Karen Coyle" in a prominent place, although it is born digital on my computer and will be distributed digitally, there's little that "West coast code" (Lessig's term for computing and programs) can do regarding copyright law. ContractThe second C is contract. Contracts are another form of law; they are legally binding agreements between parties. Librarians are becoming more familiar with the art of contracts (and licenses, which are a form of contract) as more intellectual resources are available through services rather than through sales of a tangible medium. Contracts represent business arrangements, and business transactions can be carried between parties with some computerized representation of the transaction. Electronic Data Interchange (EDI) standards have served for decades to facilitate these transactions. Some work on the goal of a digital contract standard is coming out of the EDI tradition. The work of <indecs>® [6] and EDItEUR [7] (the EDI in EDItEUR refers to electronic data interchange) is based on a transaction view of the exchange of goods in digital form. In 1999, Godfrey Rust, of <indecs>, introduced his "stuff" diagram at a meeting sponsored by the National Information Standards Organization (NISO). The diagram went something like:
This reads as:
"People make stuff" The goal of <indecs>, and later groups like EDItEUR, PRISM [8], and even CreativeCommons [9], was to codify the business of doing deals about stuff in an EDI-like transaction. The publishing trade has developed a transaction and product record, ONIX [10], and is working on new standards for serials subscriptions [11]. But a single transaction or deal is not the digital equivalent to the contracts that libraries make with the purveyors of digital information products and does not substitute for those contracts. Contract is a good example of the difference between the code of law and the code of computers. Contracts are documents created by or under the influence of lawyers, and contracts are designed to be readable by humans. Statements in contracts are often open to interpretation, and that is by design. For example, this is a statement from a Council on Library and Information Resources/Digital Library Federation (CLIR/DLF) model license for digital materials: Electronic Reserve. Licensee and Authorized Users may use a reasonable portion of the Licensed Materials for use in connection with specific courses of instruction offered by Licensee and/or its parent institution. The "use a reasonable portion" is a deliberately vague statement, avoiding the specification of a particular action or a quantification. This is in keeping with the spirit of the doctrine of Fair Use, where circumstances determine what is "fair" or "reasonable." To anyone who has written programs, imagine what code you would write to capture the concept of "a reasonable portion" without specifying any particular number. Legal languages and computer algorithms occupy distinctly different semantic spaces. There are various efforts underway to create a machine-readable expression of contracts, although these tend to be limited in scope. The CreativeCommons project has developed a series of standard contract statements that are each represented by a URL identifier within an RDF statement, such as:
The GIF of the license that appears on a web resource contains a link that resolves to a human-readable statement of the meaning of the license. Note that the actual license is not intended for machine interpretation. The agreement part of the license is contained in text, much as the agreement that appears online before downloads is presented as text to be read and interpreted by a person. The lawyer-creators of CreativeCommons deliberately limited the set of statements that CreativeCommons licenses would make, aware that the license could otherwise become very complex. The CreativeCommons development community is struggling with requests to expand the role of the licenses. The question is, How much can be added before the licenses fail to serve their original purpose of a simple statement of easily understood rights? PRISM, a metadata standard for syndicated items (i.e., newspaper or journal articles), serves an industry with ongoing agreements regarding the re-use of materials. The PRISM metadata that accompanies digital items available for this re-use carries only information relevant to that particular instance: copyright notice, date of availability, etc. The contract governing the relationship between the parties that are sharing this data exists elsewhere, most likely as a document prepared by lawyers for the companies involved in the agreement. PRISM assumes a previous agreement between parties, and CreativeCommons sets up a limited set of options that are suitable for open-access networked materials. Both of these metadata formats function within a circumscribed environment. Although CreativeCommons license statements leave room for a user to ask for specific use permissions for a resource, the only contact information in a CreativeCommons license is an email address. More conducive to the complexity of libraries and archives, the draft of the METS Rights schema [12] has full contact information for the institution that holds the rights or at least administers the contract for the materials. METS contains the full "real world" connection between the digital material and the contract. But when it comes to expressing contractual terms, METS primarily relies on textual fields that will be displayed to the users. Each of these metadata codifies a limited set of the rules of the relevant transaction, and this limited set allows only a small number of actions that can be exploited by software applications. There is no metadata schema for encoding the full content of a typical contract, and therefore no schema that allows us to create automated systems that interact fully with those contracts. But this is due in large part to the nature of contracts. If your intent is to create a fully actionable machine-readable contract, the entire nature of the contract and the actions it allows will have to change. This change could be effected by some developing rights management systems that provide a fully machine-readable control schema. ControlThe third C of the 3 C's of Rights is control.There are aspects of our current business practices that are judged by some to be sub-optimal for digital commerce. One is that the person-to-person contracts governing our actions are separate from the online transaction. It's hard to do efficient digital commerce if you have to first negotiate an agreement offline, so the desire is to create a fully automated, machine-to-machine interaction that covers the entire transaction. Some of this exists already in the purchase and download of software over the Internet, where a credit card transaction authenticates the release of software to your desktop machine. This type of control, access control, is the goal of the OASIS eXtensible Access Control Markup Language (XACML) [13]. Access control, as it is envisioned by XACML, is a formalized version of a function very familiar to libraries: allowing users access to materials based on policies. Policies can be any kind of criteria, like "allow access to faculty members," or "allow access on successful completion of credit card transaction." When the incoming request matches the policy, then the access request is accepted. XACML arises out of the OASIS Secure Services Technical Committee whose members are mainly from technology companies, not the library or academic community. But there is interaction between the OASIS committee and the Internet2® middleware project "Shibboleth" [14], which is a user authentication method with great promise for libraries and educational institutions. The combination of Shibboleth® authentication of users and the XACML access language could end up looking not unlike the Federated Digital Rights Management System outlined by Martin, et al. [15] for library-licensed materials. The other key aspect for developers of rights management systems, and especially for providers of popular commercial products, is the fact that contracts do nothing to prevent piracy. Yes, a company with a contract can use the court system (or threats of the court system) to punish violators, as the RIAA has recently done, but a contract has no ability to prevent actions like piracy. Such control can, however, be built into the hardware and software necessary to render digital works perceivable to human customers, and it is that control that is the focus of efforts like MPEG-21 [16], Open Mobile Alliance (OMA) [17], and the document formats such as Adobe® Portable Document Format (PDF) [18] and the Microsoft® Reader [19] format. In the case of these systems, "rights" are the actions that are allowed or granted by the machine-enforceable license. This is NOT, however, a machine-readable form of the license or contract that we discussed above, although it identifies people, stuff and deals. This license does not talk of "reasonable number of copies" or "preserve in perpetuity." The rights in this license are ones that can be granted by a computer system or rendering device. This means two things: the rights are stated in terms of device actions ("print", "modify", "backup"), and the qualities of those rights must be measurable units that can be manipulated by the device. So you can print five pages or 5% of the whole resource; or you can modify the document by making it larger or smaller, in terms of the number of bytes; or you can play the resource for two weeks or for one hour every second day; etc. The codification of these rights is based on a diagram similar to the "stuff" of Godfrey Rust, but with some additional detail:
What appear in these technologies as "rights" or "grants" or "permissions" are actually digital verbs relating to ways in which one can use a digital resource. Although the terms of these rights may be common words like "play" or "give," the actual digital action can differ from the real life act. For example, this is the description of the steps in the right to give a work to a friend: "...the first grant allows a consumer, represented as a keyHolder, to play a DVD movie for free, upon prior approval from an online service. The second grantGroup grants this consumer the right to transfer the movie to anyone as long as he pays a one-time fee of $10.00. The issue construct indicates that this consumer can issue a new license for the same movie. The trackReport construct specifies the service to be reported to when a new license is issued" [21]. What we don't see in this description are the actions implied by "... upon prior approval of an online service," or "issue a new license," or "service to be reported." The act of giving could be implemented in software and hardware in a way that users are barely aware of the presence of controls, much as most users are mainly unaware of the controls in their iPod® [22] or their MobiPocket [23] e-book reader. Something else implied in the above description of "give" is the interaction with a service over the life of the resource. This contrasts with the one-time transaction that characterizes a sale. Future products are seen as ongoing interactions with customers, which means that ideally customers would be always in communication with the service. If nothing else, online use of resources would provide service opportunities, such as transferring a resource (and its license) from you to a friend, or purchasing additional services related to the resource. There is no need to engage the cooperation of the consumer in order to have effective controls; the controls are built into the product. A device that does not interface with a printer cannot be used to print; one that has a "receive files" function but no "send" function cannot be used to send resources to others.Rights and Digital LibrariesJust as the term "rights" is used for everything from copyright law to a menu of service options on a cellular phone ("Buy," "Listen," "Delete") the term "digital libraries" covers a wide range of information services. Important differences in rights issues exist between the library's digitizing of its 19th century archives and playing selections from licensed reference works on e-reserve. A "one size fits all" rights solution is unlikely. Some of our information resources will arrive at the library with their own embedded rights technology, as e-books do today. Some information resources on the market will have controls that libraries find so unacceptable that they will choose not to obtain those materials. Some controls, such as further development of access control technologies, will benefit digital libraries, allowing them to provide more resources more easily to remote users. The right answer to the rights question for digital libraries is not between rights technology A and rights technology B. We will need to understand a broad rights landscape, one as heterogeneous as the resources we manage and the users we serve. The due diligence we will need to assert will not only be to respect the intellectual property rights in the resources we manage but also to defend the rights of our users to exercise their constitutional and legal rights to make use of these resources. Notes and References[1] Coyle, Karen. Rights Expression Languages, a Report for the Library of Congress, February, 2004. Available at <http://www.loc.gov/standards/relreport.pdf>. [2] Lessig, Lawrence. Code and Other Laws of Cyberspace. New York, Basic Books, 1999. p. 53. [3] For more on how special interests have been involved in the evolution of our copyright law, see: Litman, Jessica. Digital Copyright. Amherst, NY, Prometheus Books, 2001. Chapter 3: Copyright and Compromise. [4] I heard the apt analogy of copyright law and the tax code from Andrew Bridges, a lawyer who has been involved in recent copyright lawsuits, speaking at the Berkeley Center for Law and Technology in April 2004. [5] Copyright notices on works have not been required for the application of copyright since the 1976 revision of the US copyright law. [6] <indecs>™, <http://www.indecs.org>. [7] EDItEUR, <http://www.editeur.org>. [8] PRISM: Publishing Requirements for Industry Standard Metadata, <http://www.prismstandard.org>. [9] CreativeCommons, <http://www.creativecommons.org>. [10] ONIX, <http://www.editeur.org/onix.html>. [11] EDItEUR for Serials, <http://www.editeur.org/onixserials.htm>. [12] "Draft Rights Declaration Schema is Ready for Review." METS News and Announcements (Library of Congress), August 8, 2003, <http://www.loc.gov/standards/mets/news080503.html>. [13] OASIS eXtensible Access Control Markup Language TC, <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml>. [14] Shibboleth Project - Internet2 Middleware, <http://shibboleth.internet2.edu/index.html>. [15] Martin, Mairead, et al. "Federated Digital Rights Management: A Proposed DRM Solution for Research and Education." D-Lib Magazine, July/August 2002. <http://www.dlib.org/dlib/july02/martin/07martin.html>. [16] MPEG-21 Overview v.5, <http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm>. The MPEG-21 rights expression language is Part 5 of the ISO 12000 standard. The language is based on the eXtensible rights Markup Language, XrML. More information can be found at <http://www.xrml.org>. [17] Open Mobile Alliance (OMA), <http://www.openmobilealliance.org/>. The OMA standard uses rights metadata from the Open Digital Rights Language (ODRL), <http://www.odrl.net>, and may soon also accommodate the MPEG-21 rights language standard. [18] Adobe® Reader®, <http://www.adobe.com/products/acrobat/readermain.html>. [19] Microsoft® Reader, <http://www.microsoft.com/reader/default.asp>. [20] Iannella, Renato, ed. Open Digital Rights Language (ODRL). Version 1.1. August 8, 2002. <http://odrl.net/1.1/ODRL-11.pdf>, p. 4. Also available in HTML: <http://www.w3.org/TR/odrl/>. [21] ContentGuard. eXtensible rights Markup Language Example Use Cases. 20 November, 2001. Companion Document to XrML 2.01. [22] The Apple digital rights management system is part of the iTunes product, and is named "Fairplay." Available at <http://www.apple.com/support/itunes/authorization.html>. [23] Mobipocket, <http://www.mobipocket.com/ebookbase/en/Homepage/pub_info.asp>. Copyright © 2004 Karen Coyle |
|
|
|
Top | Contents |
| |
|
D-Lib Magazine Access Terms and Conditions doi:10.1045/september2004-coyle
|
