World Library  
Flag as Inappropriate
Email this Article

Rights Expression Language

Article Id: WHEBN0023551673
Reproduction Date:

Title: Rights Expression Language  
Author: World Heritage Encyclopedia
Language: English
Subject: Creative Commons Rights Expression Language, MPEG-D, Delivery Multimedia Integration Framework, Digital rights management, MPEG-4 Part 20
Publisher: World Heritage Encyclopedia

Rights Expression Language

A Rights Expression Language or REL is a machine-processable language used to express copyright or similar status of data (metadata usable for search, compatibility tracking or DRM).

Most REL are expressible in XML, but this is not a requirement and any format could be used.[note 1] Some use RDF and RDF Schema.[1] Although RELs may be processed directly, they will most commonly be encountered when embedded as metadata within other documents, such as eBooks, image, audio or video files.

Notable RELs

Notable RELs include:

An RDF Schema used by the Creative Commons project to express their licences.[1][2]
This same vocabulary has also been adopted by the GNU Project to express their General Public License (GPL) in machine-readable form.[3][4]
An open standard for an XML-based REL.[5]
XrML began with work at Xerox in the 1990s.[6] After passing through several versions and separate projects, it later formed the basis of the REL for MPEG-21.[7]
Part 5 of this MPEG standard includes a REL.[8]
METSRights is an extension schema to the METS packaging metadata standard.[9][10]

Use of a REL

The function of a REL is to define licences, and to describe these licences in terms of the permissions or restrictions they imply for how the related content may then be used.

"Licence" here may mean either:

  • A "well-known licence", such as GFDL, Apache License or a Creative Commons CC-by-sa-3.0 etc.
  • A pre-defined licence that is like these, but not so well known. Examples would be proprietary "shrinkwrap" licences.
  • A specific licence that is created afresh, for one piece of content licensed to one user.

Well-known licences

Use of a well-known licence is often chosen for its unambiguous simplicity: GFDL means the same no matter who is using it. Using an existing licences also avoids the problems of licence proliferation. It is also practical to use such a licence, and to check that a project is complying with it, without understanding too much about what detail it entails. Merely knowing that "GFDL is acceptable to this project" and "All resources within this project use GFDL" is sufficient. In that sense, well-known licences are a way to avoid needing to use a REL to model the details of a licence, its name alone is enough.[11]

Despite this, a REL may still be useful with these licences. It provides a machine-processable way to identify the licence in use, avoiding naming issues and potential ambiguities between "Apache License" or "Apache 2.0 Licence". The authors of these licences also require a means to describe their internal details.

Pre-defined licence

These are similar to the well-known licences, in that they're defined before their use and can be applied to many instances of licensing. Their difference is that as they're not well known, it's also necessary to explain what each of them entails, as the user is always likely to be encountering each of them for the first time. A REL provides the means to do this.

Using licensed content within a project now requires evaluation of the statement, "Are there any resources within this project whose licence forbids a condition that the project requires, or requires a condition that the project cannot permit?". These might include a necessary ability to distribute copies of the project afterwards, or a condition for accreditation on a splash screen that might be unacceptable to some projects.

In open source software development, it's also common for projects to create their own licence under their own project name, but for the details of this licence to be a boilerplate copy from a well-known licence, or even a reference to this licence.[12] A REL should support this, providing a means for licences to be defined by sub-classing existing licences and possibly changing their behaviour. Many of these licences are little more than vanity licences, although other dependent projects must still be able to work with them.[13]

Specific licences

These are licences that are created as needed, for specific pieces of content, or specific end users. This is usually so that they may have use-specific conditions attached to them, such as expiry dates. Although these licences might be based on a standard boilerplate, each one is thus unique. Referring to them by name could not work as there's no single, stable name. It's thus necessary to use a REL to express each one in terms of its individual properties.

Structure of a REL

A REL may conveniently use an Entity-Attribute-Value model, as for RDF, to structure its description of a rights model. Such a model[14] expresses itself as lists of:

Concrete "things" or "classes", e.g.:
  • Work
The item being licensed.
  • Licence
The licence, particularly when this is either a "well-known" licence (where many Works will use a comparable abstract licence, such as GFDL)
or else an instance of a specific licence, such as content playback rights purchased by one user.
  • End-user
A means to identify the end-user, when the licensing is a specific contract with one person or body.
Rarely stated explicitly, but an important qualifier when there are local legal variations in IP law.
"Properties", or aspects of each of these Entities, e.g. for a Licence:
  • constraints
Actions that are either permitted, or forbidden
Some RELs[14] separate these constraints into groups, as the likely values for each are generally disjoint sets (actions that may be sometimes prohibited are rarely compulsory)
  • permissions
  • requirements
  • prohibitions
Values for these properties, from a pre-defined vocabulary, e.g. the Four Freedoms:
  • Using the Work
  • Studying and modifying the Work
  • Redistributing copies
  • Redistributing modified copies

The REL defines sets of members for each of these three groups, and the permitted relations between them. In the example above there may be concepts of Licences, permissions and redistributing copies. Also there may be the relations, A Licence may express prohibitions, and separately Permission may be given to redistribute copies.

Statements may then be made using the REL (these would be outside of the REL itself) such as:

  FooCo's Distribution Permitted Licence


This defines a new abstract licence, one that permits re-distribution of copies. Works may then use this Licence by referring to it,

This web page is licensed under FooCo's Distribution Permitted Licence.

Note that although this hypothetical "Distribution permitted" licence has been expressed using the Creative Commons REL, it is not a Creative Commons licence. It merely uses the concepts "License", "permission" and "Distribution". Although it's not one of the Creative Commons licences defined by that project, it does share exact commonality for these terms: "Distribution" has exactly the same meaning and legal definition between them.

Interworking between licences

Increasing interest in mashups and collaborative projects creates a demand for combining content, and in licensing technologies that can support this.

The simplest approach is to only combine content under the same well-known licence. This is over-restrictive though, and many compatible licences may permit their content to be combined. It is however difficult to judge this, whether it is permitted and how the resultant content should be licensed.[15] There may still be subtleties when there are overlapping requirements or Copyleft issues. Notably the Creative Commons 'attribution-sharealike' and 'attribution-noncommercial-sharealike' are incompatible.[note 2][15][16][17]

Combining licences is simpler if all of the licences involved may be expressed through the same REL. In that case it's easier to see when a permission or a prohibition applies if they do at least apply to an identical definition of "Distribution". An obvious example of this are the Creative Commons licenses, where a family of licences are all defined in terms of the same REL.

Even if different licences were originally defined through different REL, it may be possible to re-encode a licence simultaneously in another shared REL, making them comparable. GPL has recently been expressed in ccREL, giving this advantage.[3][4][note 3]

Difficulties in interworking between licences

Apart from the issues of conflicting requirements (above), there are also technical issues in comparing licences. Many of these are alleviated if the same REL can be used, even if the licences are different.


A regular problem with semantic translation between schemas (such as RELs) is in making sure that the meanings of terms are identical. Although the semantic web is beginning to use ontology tools such as OWL to describe meaning, the current state of the art for REL is less advanced than this. Simpler processing, and the potential for expensive litigation otherwise, means that the semantics of RELs must be clearly identical, not just inferred to be so through a reasoner.

The regular problems are in demonstrating the equivalence of classes, properties and instances. For RELs the major problem is for the instances, i.e. the precise definitions of "Distribution", "Share-alike" etc. The classes and properties are usually simple concepts and very similar. Not all RELs support all classes though: some ignore Jurisdiction or even End-user, according to the needs of the market they were developed for.

Implicit pre-conditions

A less-obvious problem in comparing RELs is when they have a differing baseline.[18][19] The baseline defines the conditions implied by the licence when there are no explicit statements included. Some RELs take the "Everything not permitted is forbidden" approach, others (such as ccREL) use the Berne Convention as their baseline.


  1. ^ XrML began in Lisp.
  2. ^ See Creative Commons#Criticism
  3. ^ Note that despite the suggestion of Introducing RDF for GNU Licenses, the benefit accrues because GPL is expressed in ccREL (and RDF), not merely in RDF. For licences to become comparable, the REL vocabularies must be shared, not merely the data model.
  1. ^ a b "ccREL: The Creative Commons Rights Expression Language" (PDF).  
  2. ^ "The Digital Public Domain: Foundations for an Open Culture" (PDF). 2012. 
  3. ^ a b "Introducing RDF for GNU Licenses".  
  4. ^ a b "GPL in RDF" (RDF).  
  5. ^ "ODRL Initiative, the international effort to develop and promote ODRL". 
  6. ^
  7. ^ "The MPEG-21 Rights Expression Language" (pdf). Rightscom. 
  8. ^  
  9. ^ Nancy J. Hoebelheinrich (Stanford University Libraries). "METSRights Schema". 
  10. ^ "METSRights examples". Library of Congress. 
  11. ^ Ed Burnette (2006-11-02). "Google says no to license proliferation". Archived from the original on 2007-02-24. 
  12. ^ Make Your Open Source Software GPL-Compatible. Or Else., D. Wheeler (2014)
  13. ^  
  14. ^ a b "Can I combine two different Creative Commons licensed works? Can I combine a Creative Commons licensed work with another non-CC licensed work?". FAQ. Creative Commons. Retrieved 16 Sep 2009. 
  15. ^
  16. ^
  17. ^ "ccREL: The Creative Commons Rights Expression Language". W3C Member Submission. 1 May 2008. 
  18. ^ Nathan Yergler. "How to negate cc:permits, cc:prohibits, cc:requires?". cc-metadata mailing list. 
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.