Lately, there have been great changes in the copyright market motivated by the digital and Internet revolutions. First, these revolutions have introduced new risks in the classical market, which was basically based on the distribution of physical instances of content. Second, they have opened opportunities to create new markets based on digital creations and the Internet distribution medium.
In order to manage this new situation, the main approach is to take profit from the new technological opportunities in order to develop systems to manage and protect digital works. This is referred to as Digital Rights Management, or DRM. DRM is a system of IT components and services along with corresponding law, policies and business models which strive to distribute and control content and its rights.
There is no universal DRM system (DRMS), only implementations of DRMS that satisfy the needs of specific value chain users. It is impossible to standardise functions performed in existing value-chains (we do not know how today's value-chains will evolve) and future value-chains (we do not know what they will be). It is possible to standardise lower-level functions, i.e. primitives, between value-chain players. Then current value-chain function can be implemented as a combination of the primitives. Moreover, in the future, it would be easier to develop new functions combining the existing primitives in almost all cases. This approach supports the possibility to inject continual innovation in the system.
With a digital creation, it is possible to make a copy almost instantly, it will cost nothing and the end result will be a perfect copy of the original. The digital file is protected by the very same copyright law that a hard copy is, the one that does not really prevent us from making copies. Because law is not working as a preventive measure, there is some justification that only a technology-based protection will ever work to protect digital works.
One of these technologies is encryption. It does not prevent you from copying a file. The protection that encryption provides has nothing to do with copying; instead, encryption prevents access to the content of a file. Encryption does not provide any control over copying.
Using encryption, DRM systems tie a digital file to a particular piece of hardware. This has obvious problems when there are hardware changes or users trying to enjoy their content in multiple devices. A better solution is to connect the digital file directly to the person that can enjoy it. This approach requires current under work technologies called "trusted systems".
The controls over access to the file are just the first step in DRM. There are many more controls that can be applied, such as controls over whether you can print from the file, copy passages to the clipboard, or whether the file expires after some time period. One example of DRM system that allows such kind of usage controls is Adobe Reader 6.0.
However, in many cases, these controls may become too hard and even contrary to copyright. For instance, text-to-speech facilities for accessibility purposes may be disabled or the print option unavailable even for public domain document.
The controls in current DRMS, i.e. basically e-book readers, are quite basic. But the future of digital rights management is in the development of something called a Rights Expression Language (REL). A REL will allow a publisher to designate a much more detailed and complex set of usage controls. The REL will be able to control the number of times a text can be read, can set timed controls (i.e., "for two weeks starting today"), and can manage complex relationships of distribution, sale and lending.
A REL is a language that expresses the rights you have in relation to a file. This language differs from legal language because it must be a formal language that can be interpreted unambiguously by computers. RELs are computer-oriented so the kind of controls they can model must be of the kind computers can manage, i.e. quantitative controls: time, unit-based dimensions (e.g. pages, chapters...), money, etc. More details about REL and some of the main REL developments are given in the next sections.
Rights expression languages just express rights statements; they have no means to enforce them. In order to enforce the statements, the REL expressions must be interpreted in the context of a system. The system interacts with all the involved parties and must be secure from end to end, i.e. it must be a "trusted system".
In order to trustily manage rights transaction many individual systems must be coordinated. First, there is the end-user computer. In order to make this computer trustworthy the whole system must be able to trust that the end-user computer will obey the rules of the rights management software, regardless of what the user does with it. For instance, if the user has been granted the use of a digital resource for a limited period of time, a trusted DRMS must make it impossible for the user to alter the date of his computer in order to consume the resource outside the granted time period. This is intended to prevent piracy, because a program that would break the encryption on a protected file simply would not be allowed to run.
With DRM in place, although copyright law will still recognize users' rights to fair use, they may not be able to exercise them. Currently, DRM is not conceived as an implementation of copyright law. It is intended as a system for the protection of digital works and DRM will implement licenses rights or grants like controls that can be expressed in a computer environment. Another important difference between DRM and copyright law: copyright law does not attempt to anticipate every possible use of a copyrighted work.
A digital rights management system functions in exactly the opposite way. Where copyright law is an expression of "everything that is not forbidden is permitted", DRM takes the approach of "everything that is not permitted is forbidden". This is seen as a necessary requirement to create secure software but this may limit legal use, which might create a very negative view of DRM in those traditionally enjoying this exceptional uses. Moreover, it might have great implications for future uses of protected works. If the starting point for DRM is that something not explicitly authorised is forbidden, DRM systems will automatically forbid unforeseen ways of using content.
As it has been already introduced, Rights expression languages (RELs) are part of the technology of digital rights management. As any language, their objective is to be a vehicle of expression. This generic goal is concretised in the DRM field as follows:
Moreover, there is a clear purpose of this expressions, which is what relates RELs to DRM:
The degree to which RELs are intended to be machine-actionable is a determinant in the kinds of rights that can be expressed in the REL. A machine-actionable REL must use very precise language and can nearly guarantee compliance with the terms of the machine-readable license. This REL cannot, however, support social or legal concepts like "fair use". On the other hand, broader and less precise RELs must rely on agreement and trust for enforcement, which means that there is a risk of unauthorized use. In the RELs Analysis section we will analyse three of the main RELs: Creative Commons [Lessig03], MPEG-21 REL [Wang05] and ODRL [Iannella02]. Now, they are situated in relation with these objectives in Figure.
Creative Commons functions specifically in the open access environment of the World Wide Web. ODRL is a general-purpose language that allows, but does not require, some actionable control over resource use. MPEG-21 REL is a general language that is formally described and fully actionable within a trusted systems environment.
For practical use it is expected that organizations should have to tailor the chosen REL to their particular needs. However, any one of these may provide a suitable basis for that development. In particular the two general-purpose languages, ODRL and MPEG-21 REL have a rich vocabulary that can be reduced or expanded to create a REL for a specific purpose.
Copyright law is the default agreement that exists when no other arrangement has been made between parties. A contract is a stated agreement between any two parties. Therefore, all RELs have some relationship to copyright law because it exists as a default environment. Most, however, make little reference to law.
Copyright law makes a statement about ownership of intellectual works and the rights of various parties. It gives particular rights to the copyright owner over a limited set of actions: reproduce the work, derive other works from the work, distribute copies of the work, perform the work, and display or perform the work publicly. Copyright law does not make specific reference to using materials, such as viewing or listening; these are considered to be "normal use" and assumed to be permitted.
The approach of almost all REL initiatives is that there is little that a rights expression language can or should do in relation to the copyright law. Moreover, rights expression languages that are intended to be machine-actionable are expressly not intended to implement copyright law. Some early attempts to use RELs to express legal concepts like "fair use" did not succeed. The copyright law, although carefully worded, simply cannot be expressed in the kind of languages that is used to model RELs.
This is especially true of the key concept of "fair use". Fair use is a deliberately vague exception to the monopoly rights of the copyright holder. It says essentially that although the copyright holder has the exclusive right to make copies of the work, members of the public can also make copies if their use is "fair". There is no a priori test for whether a use is fair. Electronic systems need an unambiguous and quantitative definition that they can act on, and the copyright law does not provide that.
MPEG-21 REL and ODRL are focused on the parties to the license. Both refer to the issuer of the license, but have no reference to copyright. On the other side, Creative Commons is more concerned with copyright. The machine-readable statements keep room for copyright holder's names and contact information. Moreover, the human-readable version of the statements can be augmented to a fully legal document, although it is not machine-readable.
Finally, for the implementation of controls goal, it is important to state the difference between agreement (contract) and execution (control). A contract is essentially an agreement to behave in a certain manner. Control is an actual implementation of the rights and limitations. When there is a controlling mechanism in place the parties are unable to violate the terms of an agreement even if they should wish to. The same language that expresses contracts may be used in control mechanisms if it is designed in such a way that it can be implemented in software or hardware.
Mark Stefik developed the first Rights Expression Language (REL) for Digital Rights Management at Xerox PARC in the early 1990's. The motivation was the need for protection for digital materials in order to support online commerce. Then, a trusted systems environment could be developed that would provide the level of security needed to allow digital commerce to flourish [Stefik97].
That system would need a machine-readable language to represent rights statements. The first REL by Stefik was called the Digital Property Rights Language (DPRL). In 1998, it was licensed to a company founded by Microsoft and Xerox called ContentGuard. Then, its development continued and it was renamed eXtensible Rights Markup Language (XrML) in 2001 [Wang02]. In 2003, the MPEG-21 Standard [Walle05] work started with a part of it dedicated to a rights expression language and a complementary rights data dictionary. The proposed REL is based on the last version of XrML.
Meanwhile, there were others also working in this arena. Renato Ianella of IPR Labs proposed the Open Digital Rights Language (ODRL) in 2000 as an open standard rights language. ODRL has been adopted by the Open Mobile Alliance as its rights expression language in the mobile phones domain. Moreover, the concept of rights expression languages has been appearing in almost any metadata initiative for digital resources, e.g. ONIX, OAI, METS, Dublin Core, MARC and others.
RELs are just languages to express the statement that have to be interpreted and implemented by the rights management systems; they do not act directly on content. Currently, there are some more or less mature REL initiatives but the corresponding rights management systems are still at an early stage of development. Moreover, the development is slowed by the great complexity of RELs, which makes them difficult to implement.
The main contenders for a generalized REL today appear to be MPEG-21 REL (based on XrML) and ODRL. Another of the main RELs, first developed in 2002, is Creative Commons. It seems the best alternative for open environments because it does not impose any access control. Although this lack of control mechanisms, it has great acceptance in the Web and it is being used to share contents on a free way, e.g. educational contents, free software, etc.
We have highlighted three of the main RELs but there are more. And all are trying to provide an universal language for rights expression. The consequence is that, currently, the intuition is that there is not and probably will never be a universal REL. Each one fits quite particular requirements and, as digital rights management evolves and gets more common, even more specialised requirements would open more REL development possibilities.
The RELs that have been considered are quite different in terms of how they themselves can be licensed and used. ContentGuard does not require a license but the company holds numerous patents on digital rights management technologies. Their patents may cover more than just XrML; in particular one patent titled "System for Controlling the Distribution and Use of Digital Work Having Attached Usage Rights Where the Usage Rights are Defined by a Usage Rights Grammar" (US Patent 5,715,403) may be interpreted to cover all rights expression languages. Although ContentGuard has not yet pressed its patent with others developing and using RELs, they have stated that their position is that the patent provides that capability.
ODRL is explicitly a license and patent-free technology that has been developed in the spirit of open source technology. The same applies for Creative Commons, which models its licenses on those of the open source movement, and has no license requirements for making use of the CC materials.
In order to make a survey of the current REL state of the art, we have performed an analysis over the main RELs: Creative Commons, ODRL and MPEG-21 REL. First of all we are going to detail the different aspects considered in this analysis: how do they represent contract, how do they manage control, their general architecture and finally the data elements that conform the language. Then, each of these RELs is analysed respect to these aspects. Finally, other REL initiatives are introduced shortly. This analysis has been largely inspired by Karen Coyle's Report on Rights Expressions Languages for the Library of Congress [Coyle04].
Rights or permissions beyond those included in copyright law are covered by contract or license. A copyright holder can extend copy and distribution rights through the mechanism of contracts and licenses. These agreements can give more or fewer rights to the users of the copyrighted material than would be covered by copyright law. Contracts are agreements between individuals, institutions, or groups and do not apply to the public at large. They can contain any constraints that the parties agree on.
In the RELs domain generally agreements are referred as licenses. This is indicative of the common view that in copyright contracts one party is giving specific permissions to another, rather than a general contractual agreement between parties.
A contract language typically considers some of the following:
In general, RELs expressions are statements about privileges granted by one party to another.
Neither copyright law nor contracts assert any actual control over the behaviour of users of materials. They rely on the parties to act within the stated agreement or law. Because digital materials must be mediated through software and hardware, it is possible to exercise a priori control over access to and use of the content through that technology.
The functions of control and contract tend to have data elements in common because they both represent license terms. Control is distinctive because it is designed to be machine-enforceable, therefore it will use a highly formalized expression.
In order to exercise control there are two alternatives. The simplest one is to use dedicated devices that facilitate the implementation of the controls as their functionality is already constrained by their hardware. On the contrary, the second alternative is based on general-purpose computers. They constitute an open framework that allows users to perform a great amount of actions that should be controlled. This makes the implementation of control much more difficult. The approach in this case is to develop trusted systems, i.e. safe areas within our general computing environment where such controls can be implemented. In trusted systems, certain functions available to other software will be under the control of the trusted system and not the computer user.
There are two key points where control can be exercised, the resource access and the resource use. Access controls limit who can receive or download a file. Access control is usually not covered by RELs as, for this task, they rely on external systems or the computation environment where they are implemented, e.g. the operating system or a public key infrastructure.
Usage controls determine what a user can do once the digital resource has been obtained. Since digital resources must be rendered in some way to make them human-perceivable, usage controls are generally built into the software and/or hardware that enable that perception. Access and usage controls can work together or separately.
Control-oriented languages, e.g. MPEG-21 REL or ODRL, express their controls as being license-based. The license is not a contract in the legal sense but it is a digital rendering of permissions for use. These permissions might also be expressed in a human-readable contract that has legal ramifications, but that is assumed to be outside of the REL itself. For these controls to function within an automated system, every permitted usage type must be explicitly granted in order for the rendering software to securely protect the resource. Therefore, a fully functioning rights language designed for automated control must define every possible allowable usage.
RELs are made up of data elements that express the rights situation. In general, a rights system is made up of resources, agents that interact with those resources, sets of rights or permissions, constraints on those rights, and requirements such as payments.
This element is used to identify the party or parties involved in the expressed rights statement. It is quite general so it can represent different roles in the environment of the REL.
This element is basically used to refer to the resource identifier. It is assumed that further details lay outside the REL and are linked in some way, usually by the identifier.
Rights are the core of any rights expression language. RELs use different terms to refer to them. Some talk about permissions, others about grants, etc. However, the purpose is always the same, to express a set of allowed actions over the resource. Rights refer to end-user actions, such as playing or printing, and also to other parties' actions, such as copying or communicating to the public.
The list of allowable actions varies greatly between RELs. The general purpose ones, which try to cover the widest range of situations, have the most extensive lists of actions. Moreover, some of them are designed for expansion of their rights metadata elements. Others are very specific to an application domain and they just cover the kinds of actions that are relevant to such domain.
Rights can generally be assigned to one of these types: manage, re-use, transfer and use:
These categories are detailed next and there is a summary of all the right elements defined by the considered RELs in the RELs Overview section.
Permitted actions are modified with constraints. They are based on any criteria that can logically be applied to the action, but tend to be quantitative elements in actionable RELs, i.e. time, payment or units. There are also constraints on aspects about the user and the use that are not quantitative. For instance, quantitative constraints based on units (page, chapter...), time (dates, duration...) and place (territory, region...) can be applied to a right like "play" in order to build a license like "the first chapter of this DVD can be played in the USA and Canada region 100 times each year from January 1, 2005 to December 31, 2010".
They are the specific requirements that must be fulfilled before the user can exercise the rights. The most common is payment, for instance to give a credit card number in order to complete a song acquisition process. Some of these conditions can be enforced, e.g. checking the credit card number, but others not. For instance, a usage condition like "attribution" cannot be enforced by a digital rights management system because the required action lies outside the scope of the DRMS and thus it cannot test if it is fulfilled.
Creative Commons (CC) provides a legal framework and expression language for building a "some rights reserved" medium for resources sharing on the Web. The resources can be audio, images, text, video, etc. The expression language allows defining CC licenses that are machine-readable. However, there is no machine-actionable control over use of the content that carries such a license. This means that, for automation purposes, such licenses can be used for cataloguing purposes but not for DRM.
CC relies on existing copyright law to protect digital content. In order to connect CC licenses to copyright law, the Creative Commons initiative has created a set of human-readable "classical" licenses that legally define the predefined set of CC licenses. These licenses are also available summarised for users not interested in the legal details and, as it has been said in the previous paragraph, in machine-readable form. The philosophy of the Creative Commons licenses is similar to the open licensing scheme of the Free Software Foundation, the GNU General Public License.
The Creative Commons REL is based on RDF metadata, see the RDF Model and Syntax section, and thus it is defined by a RDF Schema, see the RDF Schema section. The CC licenses in their machine-readable form have two parts: Work and License, which are classes in the RDF Schema terminology. The Work section describes the resource to which the license pertains using simple Dublin Core [Dekkers03] metadata elements. The License part is more specific, it defines the concrete actions that are required, permitted or prohibited by the license referred by the Work part. More details about the Creative Commons rights expression language are given in the following subsections.
Creative Commons licenses are centred on these three axis:
The objective of the Creative Commons project is to promote creativity by building a great base of material that can be re-used for new creations. This re-usable creations base is build using the Internet infrastructure where the materials are shared and related to a rights expression. These expression use the CC rights language that was designed to support the re-use of material. Therefore, all of their license statements address the issue of re-use.
In any case, even if either modifications or commercial use are disallowed, this does not mean that those actions are strictly forbidden. This is a less strict interpretation of "disallow" than it is common in most RELs. CC contracts define "disallow" to mean that such use must be negotiated with the copyright holder.
As it has been said, CC licenses are expressed using a machine-readable language, the CC REL but behind this simple CC license there is a fully expressed license using legal terminology. The REL acts as a simplified outline that can be used for automated cataloguing of content based on rights terms, but the rights language is considered only a summary of a human-readable license. The expanded version also explains the uses and requirements that are covered by copyright law, since these are assumed to apply to all materials on the Internet, whether or not a CC license has been assigned.
Creative Commons is not concerned with access control because its application domain is based on web-accessible documents. Moreover, it is not concerned with usage control either because its objective is to promote the re-use of these resources and not to hinder it. Therefore, Creative Commons does not have any access or usage control support and it entirely relies on the Copyright law framework. This makes CC the only one that does not have control mechanisms among all the studied RELs. On the other hand, it is the one that best supports copyright law, specially the exceptions like fair use or private copy. This is because CC is not obliged to make the assumption that everything that is not allowed by a license is automatically forbidden, on the contrary to control-oriented RELs.
The data elements defined by the Creative Commons REL are specified in the following subsections depending on their category as specified in the RELs Analysis section. There is an example of CC REL document in Table.
Creative Commons license example
|
<rdf:RDF xmlns="http://web.resource.org/cc/" |
For the element used to identify the parties involved in rights expressions, Creative Commons defines the element Agent which defines as "people or things that do stuff". The Agent element just identifies the corresponding party and it does not specify its role. More details about the party can be specified using other metadata schemas, e.g. the Dublin Core. With Dublin Core it is possible to state the agent's name using the title element and different roles using the following elements:
There are no end-users identified in CC because it operates in an open Web environment. No specific end users are identified as it is directed to any user that accesses the resource.
Differently to almost all RELs, CC does not rely on external metadata and enables a way to include more than just the resource identifier in order to describe it. CC includes the work element that allows for the use of Dublin Core data elements to describe the resource. Examples of the common Dublin Core elements used in CC are: title, description, creator's name, copyright holder's name, date, etc.
The work part of CC licenses has a license element that points to the license governing the described resource. The rights that are permitted or prohibited are specified inside the License element (note the leading capital letter). The available rights are classified and detailed in the following subsections.
Creative Commons does not consider maintenance tasks such as the installation or backup of the files that usually contain digital creations. This is because CC centres on Copyright law and creations and it does not take into account rights about the resource package, only about the intellectual content.
DerivativeWorks: this element is related to the right to create derivative works from a resource. If this element appears related to a permits element, the corresponding license specifies that derivations from the governed resource may be created and reproduced. On the other hand, if it appears related to a prohibits elements, then no derivations can be produced.
Distribution: when this element is permitted, the corresponding CC license specifies that the work (and, if authorized, derivative works) may be distributed, publicly displayed, and publicly performed.
Reproduction: this right is related to the reproduction of the work, i.e. to make copies of it. It can be permitted or prohibited by a Creative Commons license.
CommercialUse: this constraint is related to the target of the uses of the work. It can be restricted in order to disallow that rights may be exercised for commercial purposes.
There are not more constraints defined in the language because they are not required for CC purposes. For instance, there are not user based constraint because the target of CC governed works is always the general public of Internet users. Therefore, any differentiation based on user has no sense and they are not included in that language.
Creative Commons agreement take place outside the CC environment as it does not complement a DRM. For instance, the agreement can take place offline and it is also controlled offline by Copyright law. Therefore, CC has no payment elements at all in its rights expression language.
CC just defines some usage constraints. The constraints are quite particular to Creative Commons because they are taken from the licensing of open source materials domain. Both fields have the same objective, i.e. to promote sharing within the community. Therefore, to share is a requirement of use, together with other conditions that encourage moral rewards for authors and to facilitate re-use by providing the source from which the work was produced. These are the concrete usage conditions:
ODRL was developed trying to build an open standard for expressing machine-readable licenses for digital materials, i.e. a rights expression language. Although ODRL was initially a development of the IPR Systems enterprise, it is now an open and cooperative project with many participating organisation. ODRL consists of an expression language and a data dictionary. Each of the ODRL parts is defined by an XML Schema, so ODRL is based on XML metadata, see the XML section.
The expression language part, called ODRL-EX, defines the basic terms to be included in rights expressions and how they are organised, i.e. the syntax of the language. The data dictionary part, called ODRL-DD, is in charge of defining more concrete terms for the language, which are build on top of the general ones provided by ODRL-EX. The ODRL-DD is also an example of how ODRL can be extended using XML Schema mechanisms. These extension can be performed starting from the basic expression language terms, but also from the data dictionary terms.
ODRL is intended to be machine-actionable as part of a digital rights enforcement system. Consequently, as it is shown in the next subsections, ODRL is a control-oriented REL. ODRL has an open license, so it is provided for free use by anyone who wishes to incorporate all or part of it into their own DRM system. A reduced profile of ODRL has been adopted by the Open Mobile Alliance (OMA) in order to provide a standard digital rights management language for the mobile communications domain. OMA is formed by nearly 200 companies including the world's leading mobile operators, device and network suppliers, information technology companies and content and service providers, e.g. Ericsson, Nokia, IBM, Microsoft, Alcatel, NTT DoCoMo, etc.
The intention is to make ODRL a fully machine-readable language that supports digital rights enforcement and end-to-end supply chain services. However, although the ODRL REL can support a machine-actionable rights management system, it does not provide such a system nor does it make any statement about how that system should work. Therefore, it can be said that ODRL is a general REL that is independent from the concrete implementation, i.e. DRM System, that will employ it.
Contracts are modelled using three different main terms:
Finally, contracts can be also digitally signed. In this case, the necessary metadata for signature validation is attached to the contract using the Signature element, which specifies the signed info, signature value and signature key info.
ODRL relies on external means to implement access controls, so they are outside of the scope of this language. The focus is on usage controls, although usage controls are only realized when ODRL is used in a secure and trusted systems environment. Thus, ODRL is suitable to be used for usage control but its adoption does not imply that such controls are in place. It needs a DRM System that implements these controls.
In order to implement control, ODRL relies on unambiguous definition of the available rights, which must be connected to the different actions governed by the implementing DRMS. Another important point are constraints, which should be properly quantified in order to be interpreted by the DRMS. For instance, it is important to define resource units (pages, chapters, etc.) or expression of time units and intervals. There are more details about the means provided by ODRL in order to implement control in the next section, where the language elements are described.
The data elements defined by ODRL are specified in the following subsections depending on their category as specified in the RELs Analysis section. There is an example of ODRL license in Table. It is important to highlight the context element because it is widely used to attach identifiers and descriptive metadata to any of the resources taking part in a license, e.g. licenses locations, parties names, etc. It is also possible to use metadata from external schemas, e.g. parties roles from MARC (http://www.loc.gov/marc), resources resolution from MPEG-7 [Salembier02], etc.
Open Digital Rights Language license example
<?xml version="1.0" encoding="UTF-8"?> |
ODRL uses the party element in order to specify the agents participating in a license, both end-users and rights holders. There are also some general elements that can be employed to give more details about parties, independently of their kind, e.g. the party identifier or its name. However, in some cases it is important to provide metadata specific to the kind of party. For instance, Rights Holders covers roles such as creators, producers, distributors, etc., which can be specified using the context element and external metadata elements, e.g. from MARC or Dublin Core.
There is also one element in ODRL that is specific to parties of the rights holders kind. It is called rightsholder and it is used to specify royalty entitlements, which are specified using the following elements:
In order to specify the resources that take part in ODRL licenses, there is the asset element. It is complement, as for agents, with the context element in order to specify the resource identifier and descriptive metadata, e.g. name, resolution, etc. It is also possible to include cryptographic metadata for protected resources using the digest and KeyInfo.
The rights that are granted by a ODRL license are related to it using the permission element. This element specifies the concrete rights that are authorised, which are detailed in the next subsections following the classification established in the RELs Analysis section. Moreover, it is possible to use the Exclusivity attribute in order to state that the included rights are granted exclusively and the context element to provide and identifier to the concrete rights package inside the permission element. These identifiers can used to revoke a concrete rights package.
This category indicates a set of digital asset management operations. The actions for the digital management of an asset are:
It indicates a set of operations in which the asset, or portions of it, can be re-utilised. The actions for the re-utilisation of an asset creating a new asset are:
This category indicates a set of procedures in which the rights over the asset can be transferred. The actions for the downstream transfer of rights of an asset are:
It indicates a set of methods in which the asset can be consumed. The actions pertaining to the end-use of an asset are:
ODRL supports the expression of rights constraints, which restrict the permitted actions over the license asset. In ODRL, a constraint is associated with one permission. If a constraint appears at the same level as a number of permissions, then the constraint applies to all of the permissions. Constraints can also have constraints. In this case, the child constraint applies to the parent constraint. As an example of this, consider the unit constraint and it's meanings when used within the count and range constraints:
Additionally, all constraint elements may have a context element to support the use of identifiers and a type attribute to refer to additional information. Finally, it is important to note that any constraint that is expressed but cannot be performed by the implementing DRM system, must not be granted. That is, if a system does not understand how to guarantee that a specified constraint be honoured it must not grant the permission at all. For permissions with multiple constraints, all constraints must be honoured with no conflicts arising.
The constraints are grouped in the following categories.
This category indicates a set of constraints which limits usage to identified users, which are specified individually or as a group:
It indicates a set of constraints which limits usage to physical devices or systems. Device constraints apply to any electronic or digital equipment or system:
This category indicates a set of constraints which limits usage to a fixed number or extent/coverage. These are the bound constraints that define limits/extent within which any entity can function:
It indicates a set of constraints which limits usage to temporal boundaries. These are the temporal constraints for the time limits within which any entity can function:
This category indicates a set of constraints which limits usage to distinct features or expressions of the asset. These are the aspect constraints for distinct features of the asset:
It indicates a set of constraints which limits usage to where and how the asset is used. These are the target constraints to specify how and where limits over the asset:
This category indicates a set of constraints which only applies to assets with a transfer permissions and enables the specification and constraints on downstream permissions.
transferPerm: specification of constraints over assets for which there is a downstream transfer of permissions. It applies only to assets that have one of the transfer permissions applied, i.e. sell, lend, give or lease, and it limits the extent to which the authorised party can transfer the received rights to other users. Contains the downstream attribute that defines the allowable narrowing of the specified permissions. The values are equal, less or notgreater. They mean, respectively, that the permissions must be passed along without change when the asset is transferred, that a smaller subset of permissions must be passed and that the permissions may be narrowed but they must not be expanded.
ODRL defines a set of conditions that must be fulfilled in order to exercise the granted rights. They are called requirements in the ODRL nomenclature. There is a set of payment types that could be converted to machine-enforceable requirements:
Aditionally, ODRL specifies some interaction requirements, i.e. obligations in the form of user actions:
And there are also usage conditions:
MPEG-21 [Walle05] is a suite of standards relating to digital multimedia resources. There are sixteen parts to MPEG-21, including identification of digital items, content representation, delivery protocols and content management. The latter is comprised of a rights expression language and a a data dictionary, parts 5 and 6 respectively.
Part 5 of is the Rights Expression Language [Wang05]. It defines the basic terms to be included in rights expressions and how they are organised, i.e. the syntax of the language. The REL is specified by three main XML Schemas:
Part 6 is the Rights Data Dictionary (RDD) [Wang05]. The objective of this part is to define the terms used in the REL expressions, i.e. to formalise the semantics of the language terms. Differently to the ODRL data dictionary, MPEG-21 RDD is not specified using XML Schemas. RDD is an ontology, see the Ontology section, although it uses a semiformal language for its specification. The terms used in the REL, plus additional terms, are defined by semantic interrelationships. This ontology can be used to facilitate the implementation of MPEG-21 tools for content management. However, MPEG-21 REL and RDD are not directly integrated, as they are specified using different approaches, and some effort is needed in order to implement the RDD because it is not formalised.
In this analysis, in order to facilitate comparing the different analysed RELs, we are going to centre the MPEG-21 study on the REL. The MPEG-21 REL is oriented towards the licensing of digital materials. As it has been presented in the RELs History section, it was developed by MPEG-21 standards group using XrML as its basis. The standard is specifically intended to be unambiguously machine-actionable and to interact with software and hardware that will enforce the license permissions, i.e. a DRM System. The latter will provide the necessary implementation using trusted systems technology which will allow end-to-end control over digital works through the whole content value chain.
The REL standard is broad enough to make it usable for a wide variety of digital products. It provides mechanisms for its extension and adaptation to concrete application domains. For instance, the Open eBook Forum, an industry group developing standards for e-books, is considering a set of extensions to MPEG21 REL specific to e-books.
MPEG-21 REL is quite similar to ODRL. It is also a control-oriented language so it describes a machine-to-machine language for automated license control and management. The final objective is to provide a key component for a platform that supports the secure delivery of content over digital networks. Within this environment, the rights expression language is only one of sixteen architectural elements. And, also like ODRL, this REL does not describe or define the system that will make use of it. The language will be used within the context of a trusted system that can operate along the entire e-commerce business chain to manage business relationships as well as end-user permissions.
MPEG-21 REL contracts relate one or more principals, a set of rights that are associated with a digital resource, and conditions to which those rights are subject. A principal can be a person, a network node or an end-user device. A right is described in its linguistic role as a "verb". The resource is the object of the rights and a condition describes rules under which rights can be exercised. Moreover, the object of the contract, i.e. the resource, can be a rights expression. Therefore, the REL can be used to model the transfer of rights along the full chain of electronic commerce. For instance, it can be used to carry to the digital world the flow of contracts from rights holders to other parties like wholesalers and retailers interact in the analogue world.
The MPEG-21 REL rights language is designed specifically for systems that will be imbedded in devices or software and that will exercise control over the uses of the digital file. MPEG-21 REL focuses on usage controls, and access controls are outside of the scope of this language. To achieve flexibility in the control of the different kinds of usages, MPEG-21 has abstracted the kinds of actions that can be performed on creations, which are called rights, in the Rights Data Dictionary (RDD). The rights terms are taken from the controlled list of verbs in RDD. All of them derive from the generic verb "do".
For instance, the rights terminology in the area of allowable changes to a file is based on the verb "modify" and subdivided into "enlarge", "reduce" and "move". Another example of abstraction is the term "play" to represent all of the possible ways that a resource can be transiently rendered for human perception, while "print" refers to a fixed perceivable rendering.
Although this refinement is possible, to date, MPEG-21 REL uses only a small set of verbs and does not take profit from their hierarchical organisation in the dictionary. As it has been previously commented, there is not a standard mechanism for REL to RDD interoperation. Therefore, the common approach for the moment is to implement just the basic verbs that are present in the REL. The hierarchical organisation does not contribute any additional meaning as the REL terms are quite distant in the complete hierarchy provided by the RDD and not hierarchically related among them.
The data elements defined by MPEG-21 REL are specified in the following subsections depending on their category as specified in the RELs Analysis section. There is an example of MPEG-21 REL license in Table. The main element is license that encapsulates the whole license. It is composed of two sections. The first one, marked by the grant element, is the main one and it contains the actual content of the license, i.e. the granted right, the agents involved, the governed resource and the conditions. The other section is marked by the issuer element and it is in charge of stating who is the issuer of the license. It is not necessary that the isssuer party is involved in the grant part of the license.
MPEG-21 Rights Expression Language license example
<?xml version="1.0" encoding="UTF-8"?> |
MPEG-21 REL refers to the agents involved in a license using the general term principal, which can refer to any person, entity, or system component. Principals appear in the issuer part of the license, as license issuers, or in the grant part, as users or rights holders affected by the rights statement. Principals are identified by a name or an encrypted key. The latter identifies but also authenticates the principal and is specified by the keyHolder element, which details the encrypted key values, e.g. for a RSAKeyValue there are the Modulus and Exponent subelements.
Resources in MPEG-21 REL are defined as digital items, which constitute another part of the MPEG-21 standard. The link between the REL expressions and the digital items is done using the diReference element. This element specifies the concrete resources through a identifier subelement. There are not additional means in the REL for resource description. These are supposed to lay outside the scope for MPEG-21 REL. For instance, as in the case of ODRL, MPEG-7 metadata can be used to describe digital multimedia resources details.
The rights that are granted by a MPEG-21 license are directly included in the grant section of the license. The concrete right elements for the available rights are detailed in the next subsections following the classification established in the RELs Analysis section.
MPEG-21 uses the same term, condition, for both the constraints and the conditions as they are understood in this analysis. Here, constraints are interpreted as conditions that restrict the rights granted by the corresponding license. However, in MPEG-21 REL, constraints and conditions are grouped under the MPEG-21 REL "condition" category. In order to facilitate comparing the different RELs, the MPEG-21 REL conditions that are related to rights restrictions have been analysed in this section. For the rest of the MPEG-21 REL conditions, which are interpreted as "conditions" from the point of view of this analysis, are presented in the corresponding section.
The constraints are grouped in the following categories:
This category groups the constraints which limit usage to physical devices or systems. MPEG-21 REL does not directly define any device constraint. However, the e-Book Forum extension to MPEG-21 REL defines two device constraints:
This category indicates a set of constraints which limits usage to a fixed number or extent/coverage. These are the bound constraints that define limits/extent within which any entity can function:
It indicates a set of constraints which limits usage to temporal boundaries. These are the temporal constraints for the time limits within which the grant is valid:
This category indicates a set of constraints which limits usage to distinct features or expressions of the asset. These are the aspect constraints for distinct features of the asset:
MPEG-21 REL has the most detailed language for payments of all of the studied languages:
And there are also usage conditions:
Overview of the RELs data elements
|
CC |
MPEG-21 REL |
ODRL |
|
Agent Data Element |
||
|
Agent |
principal, issuer |
party |
|
Manage-type Rights |
||
|
|
delete |
delete |
|
|
install |
install |
|
|
move |
move |
|
|
uninstall |
uninstall |
|
|
|
duplicate |
|
|
|
backup |
|
|
|
verify |
|
|
|
restore |
|
|
|
save |
|
Reuse-type Rights |
||
|
DerivativeWorks |
adapt |
|
|
|
diminish |
|
|
|
embed |
|
|
|
enhance |
|
|
|
enlarge |
|
|
|
modify |
modify |
|
|
reduce |
|
|
|
|
excerpt |
|
|
|
annotate |
|
|
|
aggregate |
|
Transfer-type Rights |
||
|
Distribution |
|
|
|
|
|
sell |
|
|
|
lend |
|
|
|
give |
|
|
|
lease |
|
|
transferControl |
|
|
Use-type Rights |
||
|
Reproduction |
|
|
|
|
|
display |
|
|
execute |
execute |
|
|
play |
Play |
|
|
|
|
|
User Constraints |
||
|
|
|
individual |
|
|
|
group |
|
Device Constraints |
||
|
|
clipboard |
|
|
|
textToSpeechOff |
|
|
|
|
cpu |
|
|
|
network |
|
|
|
screen |
|
|
|
storage |
|
|
|
memory |
|
|
|
printer |
|
|
|
software |
|
|
|
hardware |
|
Limits Constraints |
||
|
|
exerciseLimit |
count |
|
|
trackQuery |
range |
|
|
territory |
spatial |
|
Temporal Constraints |
||
|
|
|
datetime |
|
|
|
accumulated |
|
|
validityInterval |
interval |
|
|
validityIntervalFloating |
|
|
Aspect Constraints |
||
|
|
diPartOf |
quality |
|
|
|
format |
|
|
|
unit |
|
|
isMarked |
watermark |
|
Target Constraints |
||
|
CommercialUse |
|
purpose |
|
|
|
industry |
|
|
|
re-context |
|
Payment Conditions |
||
|
|
feeFlat |
payment |
|
|
feePerUsePrePay |
prepay |
|
|
|
postpay |
|
|
feePerUse |
peruse |
|
|
feeMetered |
|
|
|
feePerInterval |
|
|
|
|
|
|
Usage Conditions |
||
|
|
seekApproval |
|
|
attribution |
|
attribution |
|
notice |
|
|
|
shareAlike |
|
|
|
|
|
tracked |
There other rights expression languages. They are shortly described in the next subsections.
OntologyX is, as its name shows, an ontology, like MPEG-21 RDD. It is the initiative of a private company, RightsCom, and there is not very much public information about it. OntologyX is presented as a formal ontology that has been implemented using OWL, see Ontology section. Therefore, it is not based on a language definition as almost all the existing RELs. The ontology builds a conceptual model that can be divided in the following submodels.
It defines the main entities in the content and Digital Rights Management domain:
This is the main component of the OntologyX model. It defines a set of context that are related to an event based approach. Each event modelled by OntologyX, which are DRM related events, is formalised as a context where the different entities taking part in the event are grouped. These are the main contexts:
There is a common flow of the previous events, i.e. context. The starting point is a situation of controlled rights generated by an Assignment and captured by a Rights Statement. The controlled rights define permissions and prohibitions that take place in particular events. Then, some of this events are made explicit through an offer, i.e. a Proposal. It there is an Agreement, then particular use events can take place, which are permitted. There may be some exceptions to these permissions, i.e. Prohibitions, and in order to carry out the use something might by required, i.e. a Requirement.
Adobe Content Manager is one of the few fully implemented RELs in use today. It can be used only in the Adobe Reader product for protected files. The REL has a small vocabulary but covers the basics of printing, copying, lending, and text-to-speech.
PRISM is being used primarily by newspaper and magazine publishers to exchange information about articles and other elements (photos, charts) that can be re-used by other publications. In addition to descriptive metadata, PRISM includes some rights metadata elements. They are few because they were created as they were necessary for their specific and immediate needs. The rights terms are encapsulated in what is called the PRISM Rights Languag (PRL). PRISM is based on RDF metadata, see RDF Model and Syntax section, for resource description and rights expressions.