Un lenguaje de expresión de derechos o REL es un lenguaje procesable por máquina que se utiliza para expresar derechos de propiedad intelectual (como derechos de autor) y otros términos y condiciones de uso sobre el contenido. Los REL se pueden utilizar como expresiones independientes (es decir, metadatos utilizables para búsqueda, seguimiento de compatibilidad) o dentro de un sistema DRM .
Los REL se pueden expresar en un lenguaje de máquina (como XML , RDF , RDF Schema y JSON). Aunque los REL se pueden procesar directamente, también se pueden encontrar cuando se incrustan como metadatos en otros documentos, como libros electrónicos , archivos de imagen , audio o video.
REL notables
Los REL notables incluyen:
- ccREL
- Un esquema RDF utilizado por el proyecto Creative Commons para expresar sus licencias . [1] [2]
- Este mismo vocabulario también ha sido adoptado por el Proyecto GNU para expresar su Licencia Pública General (GPL) en forma legible por máquina. [3] [4]
- ODRL del lenguaje de derechos digitales abiertos del W3C
- El Grupo de Trabajo de Expresión de Permisos y Obligaciones (POE) del W3C ha desarrollado las recomendaciones de la ODRL para expresar declaraciones de permisos y obligaciones para el contenido digital. [5]
- El modelo de información ODRL del W3C ofrece un marco para los conceptos, entidades y relaciones subyacentes que forman la base fundamental de la semántica de las expresiones ODRL. El objetivo del modelo de información ODRL es respaldar expresiones de política flexibles al permitir que el autor incluya tanto o tan poco detalle expresivo sobre los términos y condiciones para el uso de Activos, las Partes involucradas y las obligaciones. [6]
- El vocabulario y expresión ODRL del W3C describe los términos potenciales utilizados en las expresiones de la política ODRL y cómo serializarlos. Los términos forman parte de la Ontología ODRL y formalizan la semántica. El amplio conjunto de términos en el vocabulario proporciona el apoyo para que las comunidades utilicen ODRL como el idioma principal para expresar casos de uso comunes. [7]
Uso de un REL
La función de un REL es definir licencias y describir estas licencias en términos de los permisos o restricciones que implican sobre cómo se puede utilizar el contenido relacionado.
"Licencia" aquí puede significar:
- Una "licencia conocida", como GFDL , Apache License o Creative Commons CC-by-sa-3.0, etc.
- Una licencia predefinida que es como estas, pero no tan conocida. Algunos ejemplos serían las licencias propietarias "shrinkwrap".
- Una licencia específica que se crea con términos y condiciones individuales, para contenido con licencia de una parte a otra.
Licencias conocidas
El uso de una licencia conocida se elige a menudo por su inequívoca simplicidad: GFDL significa lo mismo sin importar quién la esté usando. El uso de licencias existentes también evita los problemas de proliferación de licencias . También es práctico utilizar una licencia de este tipo, y comprobar que un proyecto la está cumpliendo, sin entender demasiado los detalles que conlleva. El simple hecho de saber que "GFDL es aceptable para este proyecto" y "Todos los recursos de este proyecto utilizan GFDL" es suficiente. En ese sentido, las licencias conocidas son una forma de evitar la necesidad de usar un REL para modelar los detalles de una licencia, su nombre solo es suficiente. [13]
A pesar de esto, un REL aún puede ser útil con estas licencias. Proporciona una forma procesable por la máquina para identificar la licencia en uso, evitando problemas de nombres y posibles ambigüedades entre "Licencia Apache" o "Licencia Apache 2.0". Los autores de estas licencias también necesitan un medio para describir sus detalles internos.
Licencia predefinida
Son similares a las licencias conocidas, ya que se definen antes de su uso y se pueden aplicar a muchas instancias de licencias. Su diferencia es que, como no son muy conocidos, también es necesario explicar en qué consiste cada uno de ellos, ya que siempre es probable que el usuario se encuentre con cada uno de ellos por primera vez. Un REL proporciona los medios para hacer esto.
El uso de contenido con licencia dentro de un proyecto ahora requiere la evaluación de la declaración: "¿Hay algún recurso dentro de este proyecto cuya licencia prohíba una condición que el proyecto requiere, o requiere una condición que el proyecto no puede permitir?". Estos pueden incluir la capacidad necesaria para distribuir copias del proyecto posteriormente, o una condición para la acreditación en una pantalla de presentación que podría ser inaceptable para algunos proyectos.
En el desarrollo de software de código abierto, también es común que los proyectos creen su propia licencia bajo su propio nombre de proyecto, pero que los detalles de esta licencia sean una copia repetitiva de una licencia conocida, o incluso una referencia a esta licencia. [14] Un REL debe apoyar esto, proporcionando un medio para que las licencias se definan subclasificando las licencias existentes y posiblemente cambiando su comportamiento. Muchas de estas licencias son poco más que licencias de vanidad , aunque otros proyectos dependientes aún deben poder trabajar con ellas. [15]
Licencias específicas
Estas son licencias que se crean según sea necesario, para piezas específicas de contenido o usuarios finales específicos. Por lo general, esto es para que puedan tener condiciones específicas de uso adjuntas, como fechas de vencimiento. Aunque estas licencias pueden basarse en un modelo estándar, cada una es única. Hacer referencia a ellos por su nombre no podría funcionar ya que no hay un nombre único y estable. Por tanto, es necesario utilizar un REL para expresar cada uno en términos de sus propiedades individuales.
Los ejemplos pueden incluir un contrato por tiempo limitado para ver deportes por televisión durante un mes, pagado por un contrato en curso, y verlo en el hogar, pero no mostrarlo en un bar público.
Estructura de un REL
Un REL puede utilizar convenientemente un modelo Entidad-Atributo-Valor , como para RDF , para estructurar su descripción de un modelo de derechos. Tal modelo [16] se expresa como listas de:
- Entidades
- "Cosas" o "clases" concretas, por ejemplo:
- Trabajo / Activo
- El artículo que se licencia.
- Licencia
- La licencia, especialmente cuando se trata de una licencia "conocida" (donde muchas Obras utilizarán una licencia abstracta comparable, como GFDL )
- o bien una instancia de una licencia específica, como los derechos de reproducción de contenido adquiridos por un usuario.
- Usuario final / Partes
- Un medio para identificar al usuario final, cuando la licencia es un contrato específico con una persona u organismo, así como la parte que otorga la licencia.
- Rara vez se indica explícitamente, pero es un calificativo importante cuando existen variaciones legales locales en la ley de propiedad intelectual .
- Atributos
- "Propiedades", o aspectos de cada una de estas Entidades, por ejemplo, para una Licencia:
- limitaciones
- Acciones permitidas o prohibidas
- Algunos REL [16] separan estas restricciones en grupos, ya que los valores probables para cada uno son generalmente conjuntos disjuntos (las acciones que a veces pueden estar prohibidas rara vez son obligatorias)
- permisos
- prohibiciones
- requisitos / obligaciones (o deberes)
- Valores
- Valores para estas propiedades, de un vocabulario predefinido, por ejemplo, las Cuatro Libertades :
- Usando el trabajo
- Estudiar y modificar la Obra
- Redistribuir copias
- Redistribuir copias modificadas
- Imprime el activo
El REL define conjuntos de miembros para cada uno de estos tres grupos y las relaciones permitidas entre ellos. En el ejemplo anterior puede haber conceptos de Licencias , permisos y redistribución de copias . También pueden existir las relaciones, una Licencia puede expresar prohibiciones y por separado se puede otorgar Permiso para redistribuir copias .
Luego, se pueden hacer declaraciones usando el REL (estos estarían fuera del REL mismo) como:
rdf: about = "http://example.org/licenses/distribution/" > rdf: resource = "https://creativecommons.org/license/" /> Licencia de distribución permitida de FooCo rdf: resource = "https://creativecommons.org/ns#Distribution" />
Esto define una nueva licencia abstracta, que permite la redistribución de copias. Works puede entonces utilizar esta Licencia refiriéndose a ella,
< P > Esta página web está bajo licencia de < un rel = "licencia" href = "http://example.org/licenses/distribution/" > Distribución permitido la licencia de FooCo a > .
Tenga en cuenta que aunque esta hipotética "Distribución permitida" licencia se ha expresado mediante el Creative Commons REL, es no una licencia de Creative Commons. Simplemente utiliza los conceptos "Licencia", "permiso" y "Distribución". Aunque no es una de las licencias Creative Commons definidas por ese proyecto, comparte exactamente estos términos en común: "Distribución" tiene exactamente el mismo significado y definición legal entre ellos.
El siguiente ejemplo de W3C ODRL muestra un Acuerdo (Licencia) de la parte Cedente para un Activo que puede ser Mostrado por un cesionario (usuario) y otro para Imprimir el Activo.
{ "@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 " , " permiso " : [{ "assignee" : "http://example.com/guest:0001" , "action" : "odrl: display" }], "permiso" : [{ "assignee" : "http: // ejemplo. com / guest: 0002 " , " action " : " odrl: print " }] }
Interfuncionamiento entre licencias
El creciente interés en mashups y proyectos colaborativos crea una demanda de combinación de contenido y tecnologías de licenciamiento que puedan respaldar esto.
El enfoque más simple es combinar contenido solo bajo la misma licencia conocida. Sin embargo, esto es demasiado restrictivo y muchas licencias compatibles pueden permitir la combinación de su contenido . Sin embargo, es difícil juzgar esto, si está permitido y cómo se debe licenciar el contenido resultante. [17] Aún puede haber sutilezas cuando hay requisitos superpuestos o problemas de Copyleft . En particular, los términos "atribución-compartir-igual" de Creative Commons y "atribución-no comercial-compartir-igual" son incompatibles. [nota 1] [17] [18] [19]
Combinar licencias es más sencillo si todas las licencias involucradas pueden expresarse a través del mismo REL. En ese caso, es más fácil ver cuándo se aplica un permiso o una prohibición si al menos se aplican a una definición idéntica de "Distribución". Un ejemplo obvio de esto son las licencias Creative Commons , donde una familia de licencias se define en términos del mismo REL .
Incluso si diferentes licencias se definieron originalmente a través de diferentes REL, es posible volver a codificar una licencia simultáneamente en otro REL compartido, haciéndolas comparables. La GPL se ha expresado recientemente en ccREL , lo que otorga esta ventaja. [3] [4] [nota 2]
Dificultades en el interfuncionamiento entre licencias
Aparte de los problemas de los requisitos en conflicto (arriba), también existen problemas técnicos al comparar licencias. Muchos de estos se alivian si se puede usar el mismo REL, incluso si las licencias son diferentes.
Semántica
Un problema habitual con la traducción semántica entre esquemas (como los REL) es asegurarse de que los significados de los términos sean idénticos. Aunque la web semántica está comenzando a utilizar herramientas de ontología como OWL para describir el significado, el estado actual de la técnica de REL es menos avanzado. Un procesamiento más simple, y la posibilidad de litigios costosos de lo contrario, significa que la semántica de los REL debe ser claramente idéntica, no solo inferida a través de un razonador .
Los problemas habituales consisten en demostrar la equivalencia de clases , propiedades e instancias . Para los REL, el problema principal son las instancias , es decir, las definiciones precisas de "Distribución", "Compartir por igual", etc. Las clases y propiedades suelen ser conceptos simples y muy similares. Sin embargo, no todos los REL admiten todas las clases: algunos ignoran la jurisdicción o incluso el usuario final, según las necesidades del mercado para el que fueron desarrollados.
Condiciones previas implícitas
Un problema menos obvio al comparar los REL es cuando tienen una línea de base diferente. [20] [21] La línea de base define las condiciones implícitas en la licencia cuando no se incluyen declaraciones explícitas. Algunos REL adoptan el enfoque "Todo lo que no está permitido está prohibido", otros (como el ccREL) utilizan el Convenio de Berna como base.
Referencias
- ^ Ver Creative Commons # Crítica
- ^ Tenga en cuenta que a pesar de la sugerencia de Introducir RDF para licencias GNU , el beneficio se acumula porque GPL se expresa en ccREL (y RDF), no simplemente en RDF. Para que las licencias sean comparables, sedeben compartir los vocabularios REL , no solo el modelo de datos.
- ^ "ccREL: El lenguaje de expresión de derechos de Creative Commons" (PDF) . Creative Commons . 3 de marzo de 2008.
- ^ "10: ccREL: El lenguaje de expresión de derechos de Creative Commons" (PDF) . El dominio público digital: bases para una cultura abierta . 2012.
- ^ a b "Presentación de RDF para licencias GNU" . Fundación de Software Libre .
- ^ a b "GPL en RDF" (RDF) . Fundación de Software Libre .
- ^ "Grupo de Trabajo de Expresión de Obligaciones y Permisos (POE) del W3C" .
- ^ "Modelo de información W3C ODRL" .
- ^ "Vocabulario y expresión de W3C ODRL" .
- ^ XrML.org
- ^ "El lenguaje de expresión de derechos MPEG-21" (PDF) . Rightscom. Archivado desde el original (PDF) el 8 de noviembre de 2006.
- ^ MPEG . "Parte 5: Lenguaje de expresión de derechos" . Archivado desde el original el 5 de julio de 2009.
- ^ Nancy J. Hoebelheinrich (Bibliotecas de la Universidad de Stanford). "Esquema METSRights" .
- ^ "Ejemplos de METSRights" . Biblioteca del Congreso.
- ^ Ed Burnette (2 de noviembre de 2006). "Google dice no a la proliferación de licencias" . Archivado desde el original el 24 de febrero de 2007.
- ^ Haga que su software de código abierto sea compatible con la GPL. Si no. , D. Wheeler (2014)
- ^ David A. Wheeler (20 de agosto de 2008). "Proliferación de licencias FLOSS: sigue siendo un problema" .
- ^ a b "Describiendo los derechos de autor en RDF" . Creative Commons .
- ^ a b "¿Puedo combinar dos trabajos con licencia Creative Commons diferentes? ¿Puedo combinar un trabajo con licencia Creative Commons con otro trabajo sin licencia CC?" . FAQ . Creative Commons . Consultado el 16 de septiembre de 2009 .
- ^ "Creative Commons - Reconocimiento-CompartirIgual 3.0 Unported - CC BY-SA 3.0" .
- ^ "Creative Commons - Reconocimiento-NoComercial-CompartirIgual 3.0 Unported - CC BY-NC-SA 3.0" .
- ^ "ccREL: El lenguaje de expresión de derechos de Creative Commons" . Envío de miembros del W3C . 1 de mayo de 2008.
- ^ Nathan Yergler. "¿Cómo negar cc: permisos, cc: prohíbe, cc: requiere?" . lista de correo cc-metadata .