Un lenguaje de expresión de derechos ( REL , por sus siglas en inglés) es un lenguaje procesable por máquina que se utiliza para expresar derechos de propiedad intelectual (como los derechos de autor) y otros términos y condiciones de uso del contenido. Los REL pueden utilizarse como expresiones independientes (por ejemplo, metadatos utilizables para búsquedas y 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). Si bien los REL se pueden procesar directamente, también se pueden encontrar incrustados como metadatos en otros documentos, como libros electrónicos , imágenes , archivos de audio o video.
RELs notables
Entre los REL más destacados se incluyen:
- ccREL
- 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 ]
- Lenguaje Abierto de Derechos Digitales (ODRL) del W3C
- El Grupo de Trabajo de Expresión de Permisos y Obligaciones (POE) del W3C ha desarrollado las recomendaciones ODRL para expresar declaraciones de permisos y obligaciones para contenido digital. [ 5 ]
- El modelo de información ODRL del W3C ofrece un marco para los conceptos, entidades y relaciones subyacentes que constituyen la base fundamental de la semántica de las expresiones ODRL. El objetivo del modelo de información ODRL es admitir expresiones de políticas flexibles, permitiendo al autor incluir tantos detalles expresivos como desee sobre los términos y condiciones de uso de los activos, las partes involucradas y las obligaciones. [ 6 ]
- El vocabulario y las expresiones ODRL del W3C describen los términos potenciales utilizados en las expresiones de la política ODRL y cómo serializarlos. Estos términos forman parte de la ontología ODRL y formalizan la semántica. El amplio conjunto de términos del vocabulario permite a las comunidades utilizar ODRL como lenguaje principal para expresar casos de uso comunes. [ 7 ]
- XrML
- XrML comenzó con el trabajo en Xerox en la década de 1990. [ 8 ] Después de pasar por varias versiones y proyectos separados, más tarde formó la base de REL para MPEG-21 . [ 9 ]
- Derechos METS
- METSRights es un esquema de extensión del estándar de metadatos de empaquetado METS . [ 11 ] [ 12 ]
- RightsML
- Lenguaje de Expresión de Derechos de la IPTC para medios de comunicación basado en ODRL.
Uso de un REL
La función de una REL es definir licencias y describirlas en términos de los permisos o restricciones que implican sobre cómo se puede utilizar el contenido relacionado.
Aquí, "licencia" puede significar cualquiera de las siguientes opciones:
- Una "licencia conocida", como GFDL , la licencia Apache o una licencia Creative Commons como CC BY-SA 4.0 , etc.
- Una licencia predefinida similar a estas, pero no tan conocida. Un ejemplo serían las licencias propietarias tipo " envoltorio sellado ".
- Una licencia específica, creada con términos y condiciones individuales, para el contenido licenciado de una parte a otra.
Licencias conocidas
El uso de una licencia conocida suele elegirse por su simplicidad inequívoca: GFDL significa lo mismo independientemente de quién la utilice. El uso de licencias existentes también evita los problemas de la proliferación de licencias . Además, resulta práctico utilizar una licencia de este tipo y comprobar que un proyecto la cumple, sin necesidad de comprender demasiados detalles. Basta con saber que «GFDL es aceptable para este proyecto» y que «Todos los recursos de este proyecto utilizan GFDL». En ese sentido, las licencias conocidas son una forma de evitar la necesidad de utilizar un REL para modelar los detalles de una licencia; basta con su nombre. [ 13 ]
A pesar de esto, un REL aún puede ser útil con estas licencias. Proporciona una forma procesable por máquina para identificar la licencia en uso, evitando problemas de nomenclatura 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.
Algunos productos de lista de materiales de software (SBOM), como Software Package Data Exchange (SPDX), no utilizan una REL, sino que limitan las licencias potenciales a un conjunto de licencias conocidas, expresadas a través de su vocabulario controlado local de SPDX ID . [ 14 ] Cada licencia se identifica mediante un nombre completo, como " Mozilla Public License 2.0", y un identificador corto, en este caso "MPL-2.0". Las licencias se pueden combinar mediante operadores booleanos simples ANDy ORagrupación ( ... ). Sin embargo, esto aún requiere intervención humana para verificar la aceptabilidad de estas licencias y sus efectos al combinarlas: el producto SBOM sin REL no puede hacerlo por sí mismo.
Licencia predefinida
Estas licencias son similares a las licencias convencionales, ya que se definen antes de su uso y pueden aplicarse a múltiples casos de licenciamiento. La diferencia radica en que, al no ser tan conocidas, es necesario explicar qué implica cada una, dado que es probable que el usuario las vea por primera vez. Una REL proporciona los medios para hacerlo.
El uso de contenido con licencia en un proyecto ahora requiere evaluar la siguiente pregunta: "¿Existen recursos en este proyecto cuya licencia prohíba una condición que el proyecto requiere, o que requiera una condición que el proyecto no puede permitir?". Esto podría incluir la necesidad de distribuir copias del proyecto posteriormente, o una condición para la acreditación en la pantalla de inicio que podría resultar 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, pero que los detalles de esta licencia sean una copia estándar de una licencia conocida, o incluso una referencia a esta licencia. [ 15 ] Una REL debería admitir esto, proporcionando un medio para que las licencias se definan mediante la creación de subclases de licencias existentes y posiblemente cambiando su comportamiento. Muchas de estas licencias son poco más que licencias de vanidad , aunque otros proyectos dependientes deben poder trabajar con ellas. [ 16 ]
Licencias específicas
Se trata de licencias que se crean según sea necesario, para contenidos específicos o usuarios finales concretos. Esto suele hacerse para que puedan incluir condiciones de uso específicas, como fechas de caducidad. Aunque estas licencias se basen en una plantilla estándar, cada una es única. No sería práctico referirse a ellas por su nombre, ya que no existe un nombre único y estable. Por lo tanto, es necesario utilizar un REL para expresar cada una en función de sus propiedades individuales.
Algunos ejemplos podrían ser un contrato por tiempo limitado para ver deportes por televisión durante un mes, pagado mediante un contrato vigente, y verlo dentro del hogar pero no en un bar público.
Estructura de un REL
Un REL puede utilizar convenientemente un modelo Entidad-atributo-valor , como en RDF , para estructurar la descripción de un modelo de derechos. Dicho modelo [ 17 ] se expresa como listas de:
- Entidades
- "Cosas" o "clases" concretas, por ejemplo:
- Obra/Activo
- El artículo que se está licenciando.
- Licencia
- La licencia, en particular cuando se trata de una licencia "conocida" (donde muchas obras utilizarán una licencia abstracta comparable, como la 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 o entidad, así como a la parte licenciataria.
- Aunque rara vez se menciona explícitamente, es una aclaración importante cuando existen variaciones legales locales en la legislación sobre propiedad intelectual .
- Atributos
- "Propiedades" o aspectos de cada una de estas Entidades, por ejemplo, para una Licencia:
- restricciones
- Acciones que están permitidas o prohibidas
- Algunos REL [ 17 ] 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, a partir de un vocabulario predefinido, por ejemplo, las Cuatro Libertades :
- Utilizando el trabajo
- Estudiar y modificar el trabajo
- Redistribuir copias
- Redistribuir copias modificadas
- Imprime el recurso
La REL define conjuntos de miembros para cada uno de estos tres grupos y las relaciones permitidas entre ellos. En el ejemplo anterior, pueden existir conceptos de Licencias , permisos y redistribución de copias . Asimismo, 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 REL (estas estarían fuera de REL mismo), tales como:
<cc:License rdf:about= "http://example.org/licenses/distribution/" > <cc:licenseClass rdf:resource= "https://creativecommons.org/license/" /> <dc:title> Licencia de distribución permitida de FooCo </dc:title><cc:permits rdf:resource= "https://creativecommons.org/ns#Distribution" /> </cc:License>Esto define una nueva licencia abstracta, que permite la redistribución de copias. Las obras pueden entonces utilizar esta Licencia haciendo referencia a ella,
<p> Esta página web está licenciada bajo la <a rel="license" href="http://example.org/licenses/distribution/"> Licencia de Distribución Permitida de FooCo </a> .Cabe señalar que, si bien esta hipotética licencia de "Distribución permitida" se ha expresado utilizando la referencia Creative Commons REL, no se trata de una licencia Creative Commons. Simplemente utiliza los conceptos de "Licencia", "permiso" y "Distribución". Aunque no es una de las licencias Creative Commons definidas por dicho proyecto, sí comparte la misma naturaleza en cuanto a estos términos: "Distribución" tiene exactamente el mismo significado y definición legal en ambos casos.
El siguiente ejemplo de W3C ODRL muestra un Acuerdo (Licencia) de la parte cedente para un activo que puede ser visualizado 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" , "permission" : [{ "assignee" : "http://example.com/guest:0001" , "action" : "odrl:display" }], "permission" : [{ "assignee" : "http://example.com/guest:0002" , "action" : "odrl:print" }] }Interoperabilidad entre licencias
El creciente interés por las combinaciones de contenidos y los proyectos colaborativos genera una demanda de combinación de contenidos y de tecnologías de licenciamiento que puedan respaldar esta práctica.
El enfoque más simple consiste en combinar únicamente contenido bajo la misma licencia conocida. Sin embargo, esto es demasiado restrictivo, y muchas licencias compatibles pueden permitir la combinación de su contenido . No obstante, es difícil determinar si esto está permitido y cómo debe licenciarse el contenido resultante. [ 18 ] Aún pueden existir matices cuando hay requisitos superpuestos o problemas de Copyleft . En particular, las licencias Creative Commons «atribución-compartirigual» y «atribución-no comercial-compartirigual» son incompatibles. [ i ] [ 18 ] [ 19 ] [ 20 ]
Combinar licencias es más sencillo si todas las licencias involucradas se pueden expresar mediante el mismo REL. En ese caso, es más fácil determinar 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 claro de esto son las licencias Creative Commons , donde una familia de licencias se define en términos del mismo REL .
Aunque las distintas licencias se definieron originalmente mediante 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 ofrece esta ventaja. [ 3 ] [ 4 ] [ ii ]
Dificultades en la interoperabilidad entre licencias
Además de los problemas derivados de los requisitos contradictorios (mencionados anteriormente), también existen problemas técnicos al comparar licencias. Muchos de estos problemas se solucionan si se puede utilizar el mismo REL, aunque las licencias sean diferentes.
Semántica
Un problema común en la traducción semántica entre esquemas (como los REL) radica en asegurar que los significados de los términos sean idénticos. Si bien 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 para REL es menos avanzado. Un procesamiento más sencillo, y el potencial de litigios costosos en caso contrario, implica que la semántica de los REL debe ser claramente idéntica, y no solo inferida como tal por un razonador .
Los problemas habituales radican en demostrar la equivalencia de clases , propiedades e instancias . En el caso de las REL, el principal problema reside en las instancias , es decir, en las definiciones precisas de "Distribución", "Compartir por igual", etc. Las clases y propiedades suelen ser conceptos sencillos y muy similares. Sin embargo, no todas las REL admiten todas las clases: algunas ignoran la jurisdicción o incluso el usuario final, según las necesidades del mercado para el que fueron desarrolladas.
Precondiciones implícitas
Un problema menos evidente al comparar las REL es cuando tienen una base de referencia diferente. [ 21 ] [ 22 ] La base de referencia define las condiciones implícitas en la licencia cuando no se incluyen declaraciones explícitas. Algunas REL adoptan el enfoque de "Todo lo que no está permitido está prohibido", mientras que otras (como ccREL) utilizan el Convenio de Berna como su base de referencia.
Notas
- ↑ Ver Creative Commons#Crítica
- ↑ Cabe señalar que, a pesar de la sugerencia de introducir RDF para las licencias GNU , el beneficio radica en que la GPL se expresa en ccREL (y RDF), no solo en RDF. Para que las licencias sean comparables,deben compartirse los vocabularios REL , no solo el modelo de datos.
Referencias
- ↑ "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: Fundamentos para una cultura abierta . 2012. Archivado (PDF) del original el 1 de septiembre de 2013. Recuperado el 24 de febrero de 2014 .
- 1 2 "Introducción a RDF para licencias GNU" . Free Software Foundation . Archivado del original el 1 de julio de 2009. Consultado el 9 de julio de 2009 .
- 1 2 "GPL en RDF" (RDF) . Free Software Foundation . Archivado del original el 26-07-2016 . Recuperado el 22-07-2016 .
- ↑ "Grupo de trabajo sobre expresiones de permisos y obligaciones" . www.w3.org . Archivado del original el 25 de mayo de 2026. Consultado el 29 de mayo de 2026 .
- ↑ "ODRL Information Model 2.2" . www.w3.org . Archivado del original el 22 de junio de 2025. Consultado el 29 de mayo de 2026 .
- ↑ "Vocabulario y expresiones ODRL 2.2" . www.w3.org .
- ↑ "XrML... Lenguaje de marcado de derechos extensibles" . www.xrml.org . Archivado del original el 12 de junio de 2006. Consultado el 9 de julio de 2009 .
- ↑ "Lenguaje de expresión de derechos MPEG-21" (PDF) . Rightscom. Archivado del original (PDF) el 8 de noviembre de 2006.
- ↑ MPEG . "Parte 5: Lenguaje de expresión de derechos" . Archivado del original el 5 de julio de 2009.
- ↑ Nancy J. Hoebelheinrich (Bibliotecas de la Universidad de Stanford). "METSRights Schema" . Biblioteca del Congreso . Archivado del original el 19 de octubre de 2025. Consultado el 29 de mayo de 2026 .
- ↑ "Ejemplos de METSRights" . Biblioteca del Congreso. Archivado del original el 6 de junio de 2015. Consultado el 29 de mayo de 2026 .
- ↑ Ed Burnette (2 de noviembre de 2006). "Google dice no a la proliferación de licencias" . ZDNet . Archivado del original el 24 de febrero de 2007.
- ↑ "Gestión de información de licencia" . SPDX . The Linux Foundation . 2023. Archivado del original el 26 de mayo de 2026. Consultado el 29 de mayo de 2026 .
- ↑ Haz que tu software de código abierto sea compatible con la GPL. O atente a las consecuencias. Archivado el 23/04/2002 en Wayback Machine , D. Wheeler (2014)
- ↑ David A. Wheeler (20 de agosto de 2008). "Proliferación de licencias FLOSS: sigue siendo un problema" . Archivado del original el 22 de mayo de 2012. Recuperado el 29 de mayo de 2013 .
- 1 2 "Descripción de los derechos de autor en RDF" . Creative Commons .
- 1 2 "¿Puedo combinar dos obras con licencia Creative Commons diferentes? ¿Puedo combinar una obra con licencia Creative Commons con otra obra sin licencia CC?" . Preguntas frecuentes . Creative Commons. Archivado del original el 27 de noviembre de 2010 . Consultado el 16 de septiembre de 2009 .
- ↑ "Creative Commons — Atribución-CompartirIgual 3.0 Sin adaptar — CC BY-SA 3.0" . Archivado del original el 22 de febrero de 2011. Consultado el 25 de octubre de 2018 .
- ↑ "Creative Commons — Atribución-NoComercial-CompartirIgual 3.0 Sin adaptar — CC BY-NC-SA 3.0" . Archivado del original el 15 de febrero de 2018. Consultado el 29 de mayo de 2026 .
- ↑ "ccREL: El lenguaje de expresión de derechos de Creative Commons" . Contribución de un miembro del W3C . 1 de mayo de 2008. Archivado del original el 16 de marzo de 2009. Consultado el 10 de noviembre de 2009 .
- ↑ Nathan Yergler. "¿Cómo negar cc:permits, cc:prohibits, cc:requires?" . Lista de correo cc-metadata . Archivado del original el 13-07-2012 . Recuperado el 10-11-2009 .
- Gestión de derechos digitales
- Metadatos