# Linguagem de expressão de direitos

Uma Rights Expression Language ou REL é uma linguagem processável por máquina usada para expressar direitos de propriedade intelectual (como direitos autorais) e outros termos e condições de uso sobre conteúdo. Os RELs podem ser usados como expressões autônomas (ou seja, metadados utilizáveis para pesquisa e rastreamento de compatibilidade) ou dentro de um sistema DRM.
Os RELs podem ser expressos em uma linguagem de máquina (como XML, RDF, RDF Schema e JSON). Embora os RELs possam ser processados diretamente, eles também podem ser encontrados quando incorporados como metadados em outros documentos, como e-books, arquivos de imagem, áudio ou vídeo.

## RELs notáveis

Os RELs notáveis incluem:

### ccREL

    Um esquema RDF usado pelo projeto Creative Commons para expressar suas licenças.
    Este mesmo vocabulário também foi adotado pelo Projeto GNU para expressar sua Licença Pública Geral (GPL) em formato legível por máquina.

### Linguagem de direitos digitais abertos do W3C ODRL

    O Grupo de Trabalho de Expressão de Permissões e Obrigações (POE) do W3C desenvolveu as recomendações do ODRL para expressar declarações de permissões e obrigações para conteúdo digital.
    O Modelo de Informação ODRL do W3C oferece uma estrutura para os conceitos, entidades e relacionamentos subjacentes que formam a base fundamental para a semântica das expressões ODRL. O objetivo do Modelo de Informação ODRL é dar suporte a expressões de Política flexíveis, permitindo que o autor inclua tantos, ou tão poucos, detalhes expressivos sobre os termos e condições de uso de Ativos, as Partes envolvidas e as obrigações.
    O Vocabulário e Expressão ODRL do W3C descreve os termos potenciais usados nas expressões de Política ODRL e como serializá-los. Os termos fazem parte da Ontologia ODRL e formalizam a semântica. O amplo conjunto de termos no vocabulário fornece suporte para que as comunidades usem o ODRL como a linguagem principal para expressar casos de uso comuns.

### XrML

    O XrML começou com o trabalho na Xerox na década de 1990. Depois de passar por várias versões e projetos separados, mais tarde formou a base do REL para MPEG-21.

### MPEG-21

    A parte 5 deste padrão MPEG inclui um REL.

### METSRights

    METSRights é um esquema de extensão para o padrão de metadados de empacotamento METS.

## Uso de um REL

A função de um REL é definir licenças e descrevê-las em termos das permissões ou restrições que elas implicam sobre como o conteúdo relacionado pode ser usado.
"Licença" aqui pode significar:
* Uma "licença bem conhecida", como GFDL, Apache License ou Creative Commons CC-by-sa-3.0 etc.
* Uma licença predefinida semelhante a essas, mas não tão conhecida. Exemplos seriam licenças proprietárias "shrinkwrap".
* Uma licença específica que é criada com termos e condições individuais para conteúdo licenciado de uma parte para outra.

### Licenças bem conhecidas

O uso de uma licença bem conhecida é frequentemente escolhido por sua simplicidade inequívoca: GFDL significa a mesma coisa, não importa quem a esteja usando. O uso de licenças existentes também evita os problemas de proliferação de licenças. Também é prático usar essa licença e verificar se um projeto está em conformidade com ela, sem entender muito sobre os detalhes que ela envolve. Basta saber que "GFDL é aceitável para este projeto" e "Todos os recursos dentro deste projeto usam GFDL". Nesse sentido, as licenças bem conhecidas são uma forma de evitar a necessidade de usar um REL para modelar os detalhes de uma licença, bastando apenas o seu nome.
Apesar disso, um REL ainda pode ser útil com essas licenças. Ele fornece uma maneira processável por máquina de identificar a licença em uso, evitando problemas de nomenclatura e potenciais ambiguidades entre "Licença Apache" ou "Licença Apache 2.0". Os autores dessas licenças também precisam de um meio para descrever seus detalhes internos.
Alguns produtos de lista de materiais de software (SBOM), como o Software Package Data Exchange (SPDX), não usam um REL, mas limitam as licenças potenciais a um conjunto de licenças bem conhecidas, expressas por meio de seu vocabulário controlado local de ID SPDX. Cada licença é identificada por um nome completo, como "Mozilla Public License 2.0" e um identificador curto, aqui "MPL-2.0". As licenças podem ser combinadas por operadores booleanos simples AND, OR e agrupamento ( ... ). No entanto, isso ainda requer intervenção humana para verificar a aceitabilidade dessas licenças e seus efeitos quando combinadas: o produto SBOM não REL não pode fazer isso sozinho.

### Licença pré-definida

Elas são semelhantes às licenças mais conhecidas, pois são definidas antes de seu uso e podem ser aplicadas a muitas instâncias de licenciamento. A diferença é que, como não são muito conhecidas, também é necessário explicar o que cada uma delas envolve, já que o usuário provavelmente sempre se deparará com cada uma delas pela primeira vez. Um REL fornece os meios para fazer isso.
O uso de conteúdo licenciado dentro de um projeto agora requer a avaliação da declaração: "Há algum recurso dentro deste projeto cuja licença proíbe uma condição que o projeto exige ou exige uma condição que o projeto não pode permitir?". Isso pode incluir a capacidade necessária de distribuir cópias do projeto posteriormente ou uma condição para credenciamento em uma tela inicial que pode ser inaceitável para alguns projetos.
No desenvolvimento de software de código aberto, também é comum que os projetos criem sua própria licença com seu próprio nome de projeto, mas os detalhes dessa licença sejam uma cópia padrão de uma licença bem conhecida, ou mesmo uma referência a essa licença. Um REL deve dar suporte a isso, fornecendo um meio para que as licenças sejam definidas por meio da subclassificação das licenças existentes e possivelmente alterando seu comportamento. Muitas destas licenças são pouco mais do que licenças de vaidade, embora outros projectos dependentes ainda devam ser capazes de trabalhar com elas.

### Licenças específicas

Essas são licenças criadas conforme a necessidade, para partes específicas de conteúdo ou usuários finais específicos. Geralmente isso ocorre para que eles tenham condições específicas de uso associadas a eles, como datas de validade. Embora essas licenças possam ser baseadas em um modelo padrão, cada uma delas é única. Referir-se a eles pelo nome não funcionaria, pois não há um nome único e estável. Portanto, é necessário usar um REL para expressar cada um em termos de suas propriedades individuais.
Exemplos podem incluir um contrato por tempo limitado para assistir a esportes na TV por um mês, pago por um contrato contínuo, e assistir em casa, mas não exibi-lo em um bar público.

## Estrutura de um REL

Um REL pode convenientemente usar um modelo Entidade-atributo-valor, como para RDF, para estruturar sua descrição de um modelo de direitos. Um modelo desse tipo se expressa como listas de:

### Entidades

    "Coisas" ou "classes" concretas, por exemplo:
* Work/Asset
    O item que está sendo licenciado.
* Licence
    A licença, especialmente quando se trata de uma licença "bem conhecida" (onde muitas Obras usarão uma licença abstrata comparável, como a GFDL)
    ou então uma instância de uma licença específica, como direitos de reprodução de conteúdo adquiridos por um usuário.
* End-user/Parties
    Um meio de identificar o usuário final, quando o licenciamento é um contrato específico com uma pessoa ou órgão, bem como a parte licenciadora.
* Jurisdição
    Raramente declarado explicitamente, mas é um qualificador importante quando há variações legais locais na lei de PI.

### Atributos

    "Properties", ou aspectos de cada uma dessas Entidades, por exemplo, para uma Licença:
* constraints
    Ações que são permitidas ou proibidas
    Alguns RELs separam essas restrições em grupos, pois os valores prováveis para cada um são geralmente conjuntos disjuntos (ações que podem ser às vezes proibidas raramente são obrigatórias)
* permissions
* proibições
* requisitos/obrigações (ou deveres)

### Values

    Valores para essas propriedades, de um vocabulário pré-definido, por exemplo, as Quatro Liberdades:
* Usando o trabalho
* Estudando e modificando a Obra
* Redistribuindo cópias
* Redistribuindo cópias modificadas
* Imprimir o ativo
O REL define conjuntos de membros para cada um desses três grupos e as relações permitidas entre eles. No exemplo acima pode haver conceitos de Licenças, permissões e redistribuição de cópias. Também pode haver relações: uma licença pode expressar proibições e, separadamente, pode ser dada permissão para redistribuir cópias.
Declarações podem então ser feitas usando o REL (elas estariam fora do próprio REL), como:
Isso define uma nova licença abstrata, que permite a redistribuição de cópias. As obras podem então usar esta Licença referindo-se a ela,
Observe que, embora esta hipotética licença "Distribuição permitida" tenha sido expressa usando o Creative Commons REL, ela não é uma licença Creative Commons. Ele apenas usa os conceitos "Licença", "permissão" e "Distribuição". Embora não seja uma das licenças Creative Commons definidas por esse projeto, ela compartilha exatamente estes termos: "Distribuição" tem exatamente o mesmo significado e definição legal entre eles.
O exemplo de ODRL do W3C abaixo mostra um Contrato (Licença) da parte Cedente para um Ativo que pode ser Exibido por um cessionário (usuário) e outro para Imprimir o Ativo.

## Interoperabilidade entre licenças

O interesse crescente em mashups e projetos colaborativos cria uma demanda pela combinação de conteúdo e pelo licenciamento de tecnologias que possam dar suporte a isso.
A abordagem mais simples é combinar apenas conteúdo sob a mesma licença conhecida. No entanto, isso é muito restritivo e muitas licenças compatíveis podem permitir que seu conteúdo seja combinado. No entanto, é difícil avaliar se é permitido e como o conteúdo resultante deve ser licenciado. Ainda pode haver sutilezas quando há requisitos sobrepostos ou problemas de Copyleft. Notavelmente, as licenças Creative Commons 'atribuição-compartilhamento igual' e 'atribuição-não comercial-compartilhamento igual' são incompatíveis.
A combinação de licenças é mais simples se todas as licenças envolvidas puderem ser expressas através do mesmo REL. Nesse caso, é mais fácil ver quando uma permissão ou proibição se aplica se elas pelo menos se aplicam a uma definição idêntica de "Distribuição". Um exemplo óbvio disso são as licenças Creative Commons, onde uma família de licenças é definida em termos do mesmo REL.
Mesmo que licenças diferentes tenham sido definidas originalmente por meio de REL diferentes, pode ser possível recodificar uma licença simultaneamente em outro REL compartilhado, tornando-as comparáveis. GPL foi recentemente expresso em ccREL, dando esta vantagem.

### Dificuldades na interoperabilidade entre licenças

Além das questões de requisitos conflitantes (acima), também há questões técnicas na comparação de licenças. Muitos desses problemas são aliviados se o mesmo REL puder ser usado, mesmo que as licenças sejam diferentes.

### Semântica

Um problema comum com a tradução semântica entre esquemas (como RELs) é garantir que os significados dos termos sejam idênticos. Embora a web semântica esteja começando a usar ferramentas de ontologia como OWL para descrever significado, o estado atual da arte para REL é menos avançado do que isso. Um processamento mais simples e o potencial para litígios dispendiosos de outra forma significam que a semântica dos RELs deve ser claramente idêntica, e não apenas inferida por meio de um raciocínio.
Os problemas regulares estão na demonstração da equivalência de classes, propriedades e instâncias . Para RELs, o maior problema são as instâncias, ou seja, as definições precisas de "Distribuição", "Compartilhamento pela mesma", etc. As classes e propriedades geralmente são conceitos simples e muito semelhantes. No entanto, nem todos os RELs oferecem suporte a todas as classes: alguns ignoram a jurisdição ou até mesmo o usuário final, de acordo com as necessidades do mercado para o qual foram desenvolvidos.

### Pré-condições implícitas

Um problema menos óbvio na comparação de RELs é quando eles têm uma linha de base diferente. A linha de base define as condições implícitas pela licença quando não há declarações explícitas incluídas. Alguns RELs adotam a abordagem "tudo o que não é permitido é proibido", outros (como o ccREL) usam a Convenção de Berna como base.