ARights Expression Language orREL is a machine-processable language used to express intellectual property rights (such as copyright) and other terms and conditions for use over content. RELs can be used as standalone expressions (i.e. metadata usable for search, compatibility tracking) or within aDRM system.
RELs are expressible in a machine-language (such asXML,RDF,RDF Schema, and JSON). Although RELs may be processed directly, they can also be encountered when embedded asmetadata within other documents, such aseBooks,image,audio or video files.
Notable RELs include:
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:
Use of a well-known licence is often chosen for its unambiguous simplicity:GFDL means the same no matter who is using it. Using existing licences also avoids the problems oflicence 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 toavoid needing to use a REL to model the details of a licence, its name alone is enough.[13]
Despite this, a REL may still be useful with these licences. It provides a machine-processable way to identify the licence in use, avoidingnaming 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.
Somesoftware bill of materials (SBOM) products, such asSoftware Package Data Exchange (SPDX) do not use a REL but instead limit potential licences to a set of well-known licences, expressed through their localcontrolled vocabulary ofSPDX ID.[14] Each license is identified by a full name, such as "Mozilla Public License 2.0" and a short identifier, here "MPL-2.0". Licenses can be combined by simple Boolean operatorsAND,OR, and grouping( ... ). However this still requires human intervention to check these licences for acceptability and for their effects when combined: the non-REL SBOM product cannot do this itself.
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 asplash 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.[15] 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 thanvanity licences, although other dependent projects must still be able to work with them.[16]
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.
Examples might include a time-limited contract to watch TV sport for a month, as paid for by an ongoing contract, and to watch this within the home but not to show it within a public bar.
A REL may conveniently use anEntity–attribute–value model, as forRDF, to structure its description of a rights model. Such a model[17] expresses itself as lists of:
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 ofLicences,permissions andredistributing copies. Also there may be the relations,A Licence may express prohibitions, and separatelyPermission 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:Licenserdf:about="http://example.org/licenses/distribution/"><cc:licenseClassrdf:resource="https://creativecommons.org/license/"/><dc:title>FooCo'sDistributionPermittedLicence</dc:title><cc:permitsrdf: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<arel="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 isnot 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 inmashups 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 maypermit their content to be combined. It is however difficult to judge this, whether it is permitted and how the resultant content should be licensed.[18] There may still be subtleties when there are overlapping requirements orCopyleft issues. Notably the Creative Commons 'attribution-sharealike' and 'attribution-noncommercial-sharealike' are incompatible.[i][18][19][20]
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 theCreative Commons licenses, where a family of licences are all defined in terms ofthe 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 inccREL, giving this advantage.[3][4][ii]
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 withsemantic translation between schemas (such as RELs) is in making sure that the meanings of terms are identical. Although thesemantic web is beginning to useontology tools such asOWL 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 areasoner.
The regular problems are in demonstrating the equivalence ofclasses,properties andinstances. For RELs the major problem is for theinstances, 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.
A less-obvious problem in comparing RELs is when they have a differing baseline.[21][22] 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 theBerne Convention as their baseline.