Rights Expression Language

Notable RELs include:

ccREL

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]

W3C Open Digital Rights Language ODRL

The W3C Permissions and Obligations Expression (POE) Working Group has developed the ODRL recommendations for expressing permissions and obligations statements for digital content.[5]

The W3C ODRL Information Model offers a framework for the underlying concepts, entities, and relationships that form the foundational basis for the semantics of ODRL expressions. The aim of the ODRL Information Model is to support flexible Policy expressions by allowing the author to include as much, or as little, expressive detail about the terms and conditions for Asset usage, the Parties involved, and obligations.[6]

The W3C ODRL Vocabulary & Expression describes the potential terms used in ODRL Policy expressions and how to serialise them. The terms form part of the ODRL Ontology and formalise the semantics. The wide set of terms in the vocabulary provides the support for communities to use ODRL as the primary language to express common use cases.[7]

XrML

XrML began with work at Xerox in the 1990s.[8] After passing through several versions and separate projects, it later formed the basis of the REL for MPEG-21.[9]

MPEG-21

Part 5 of this MPEG standard includes a REL.[10]

METSRights

METSRights is an extension schema to the METS packaging metadata standard.[11][12]

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 with individual terms and conditions, for content licensed from one party to another.

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

Entities

Concrete "things" or "classes", e.g.:

• Work/Asset

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/Parties

A means to identify the end-user, when the licensing is a specific contract with one person or body, as well as the licensing party.

• Jurisdiction

Rarely stated explicitly, but an important qualifier when there are local legal variations in IP law.

Attributes

"Properties", or aspects of each of these Entities, e.g. for a Licence:

• constraints

Actions that are either permitted, or forbidden

Some RELs[16] 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
• prohibitions
• requirements/obligations (or duties)

Values

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
• Print the asset

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:

<cc:License rdf:about="http://example.org/licenses/distribution/">
  <cc:licenseClass rdf:resource="https://creativecommons.org/license/"/>
  <dc:title>FooCo's Distribution Permitted Licence</dc:title>

  <cc:permits rdf:resource="https://creativecommons.org/ns#Distribution"/>
    
</cc:License>

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

<p>This web page is licensed under <a rel="license" href="http://example.org/licenses/distribution/" 
    >FooCo's Distribution Permitted Licence</a>.

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.

The below W3C ODRL example shows an Agreement (License) from the Assigner party for an Asset that can be Displayed by one assignee (user), and another to Print the Asset.

{
    "@context": {
    "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:4444",
    "target": "http://example.com/asset:5555",
     "assigner": "http://example.com/MyPix:55",
    "permission": [{
        "assignee": "http://example.com/guest:0001",
        "action": "odrl:display"
    }],
    "permission": [{
        "assignee": "http://example.com/guest:0002",
        "action": "odrl:print"
    }]
}

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.[17] 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 1][17][18][19]

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 2]