Declarando múltiples licencias en un proyecto GitHub

28

Durante años, he sido un gran admirador de poner licencias sobre cosas compartidas en línea para que sea más fácil para otros determinar si pueden reutilizar dichas cosas y cómo pueden hacerlo. Antes de que GitHub comenzara a 'presionar' suavemente a sus usuarios para que incluyeran archivos de LICENCIA con sus repositorios, realmente no sabía cómo hacer esto mejor con el código, ¡especialmente el código compartido públicamente en GitHub! - pero he tratado de hacer un buen uso de los archivos de LICENCIA desde entonces.

Ahora estoy en la situación en la que trabajé en un pequeño proyecto con otras personas, lo que requiere mencionar varias licencias (debido al código y las bibliotecas de terceros, así como a los archivos sin código). Si bien mis socios abordan el problema de forma bastante `` descuidada '', se sugirió que `` simplemente coloque el código en línea tal como está, a nadie le importará '', prefiero hacerlo correctamente. El problema es: no sé cómo se supone que uno debe mencionar varias licencias (diferentes) en GitHub.

He visto varias soluciones diferentes en GitHub, por eso es difícil para mí juzgar si esta respuesta a una pregunta ligeramente diferente es autoritativa. Lo que me gustaría saber es cuál de los siguientes, si los hay, es el más común, o si hay otras formas adicionales de hacerlo.

  1. Cree un solo archivo de LICENCIA y coloque las descripciones de todas las diferentes licencias allí. ( Preguntas : ¿Deberían colocarse en un orden particular? ¿Comenzaría el archivo con la mención de los nombres de todas las licencias que contiene, para una mejor visión general)?
  2. Crear un archivo de licencia por licencia utilizada y los nombró LICENSE.md, LICENSE.LibNameA.md, LICENSE.AssetsB.mdetc., como se sugiere en la respuesta vinculado. ( Pregunta : ¿El nombre se basaría en los nombres de los proyectos? ¿No en los nombres de las licencias? Si usara más de una licencia para material auto-contribuido, ¿las mencionaría todas en el 'principal'LICENSE.md ? Si no, ¿qué haría en su lugar?)
  3. Cree dos archivos de LICENCIA : uno que enumere las licencias para el contenido 'principal', es decir, todo el código / activo que uno mismo ha creado; uno para todos los materiales de terceros. ( Preguntas como las anteriores : ¿existe un esquema de nomenclatura particular que se usaría y el orden en el que se enumerarían los materiales de terceros?)

Por último, si entendí las diversas explicaciones y proyectos de GitHub con respecto a su API de Licencias correctamente, solo se tomará en cuenta el archivo de LICENCIA 'principal' al determinar la licencia de un repositorio (aunque no he podido averiguar qué licencia se elegiría si se mencionaron varios)

Kay
fuente
2
Entonces tenga un archivo README y uno o más archivos de LICENCIA. Esto no es ciencia espacial.
Robert Harvey
44
Con respecto a la página vinculada: no tiene nada que ver con la distribución de los archivos de licencia, tiene que ver con la API de licencias de GitHub que determina / informa sobre la licencia de un repositorio. Como estaba preguntando sobre la licencia / el uso de archivos de LICENCIA en GitHub específicamente, no de código abierto o git en general, la forma en que un proyecto de código abierto se 'retrata' para obtener una licencia allí también es relevante. 'Esto no es ciencia espacial' no es particularmente útil, por cierto, especialmente. no en el contexto de mi pregunta centrada en GitHub.
Kay
2
Podría sugerir que su archivo README tenga una sección sobre licencias, simplemente indicando que hay varias licencias e informando para cada licencia, el nombre del archivo de LICENCIA en el que se encuentra.
Erik Eidt
3
@immibis Soy consciente de eso y no se trata en absoluto de mi pregunta. Estaba pidiendo específicamente una respuesta con respecto a "la forma que tenga más sentido para los humanos" (en: GitHub).
Kay
3
@immibis: "Ningún compilador lo leerá" - el problema es que, estrictamente hablando, esto no es cierto para Github. Github utiliza una herramienta automática para determinar "la" licencia aplicada a los contenidos del repositorio. El nombre de la licencia así determinada se mostrará en la barra de título del repositorio, junto con información más general que proporciona a los visitantes una impresión básica del proyecto (por ejemplo, número de contribuyentes y lanzamientos).
O Mapper el

Respuestas:

15

Puede utilizar cualquier mecanismo para incluir las licencias que desee, siempre que un visitante de su proyecto tenga claro qué licencia es aplicable a qué parte del proyecto.

Mi preferencia sería:

  • Coloque cada biblioteca de terceros que utilice en un directorio propio. Este directorio debe contener todos los archivos que forman parte de la distribución de la biblioteca, incluidos los archivos de licencia y léame.
  • En su propio archivo de licencia, consulte solo la licencia de su propio código
  • En el archivo Léame de su proyecto, mencione qué bibliotecas de terceros utiliza y bajo qué licencia se distribuye cada biblioteca. Para obtener detalles completos de la licencia, consulte el archivo de licencia en el directorio de la biblioteca.
Bart van Ingen Schenau
fuente
1
¿Cómo manejaría su propio archivo de LICENCIA en el caso de doble licencia de contenido propio en este escenario? Es decir, si utilizó diferentes licencias para diferentes partes del proyecto (código frente a archivos multimedia) o si desea distribuir su código en dos (o más) licencias de software diferentes. Poner información adicional en el archivo README tiene mucho sentido y es lo que yo haría también, pero estoy particularmente interesado en cómo tratar con los archivos de LICENCIA en GitHub (que, en mi opinión, se recomienda a los visitantes / espectadores de el proyecto una visión general rápida).
Kay
1
Si (partes) de mi propio código tienen doble licencia, agregaría dos (o más) archivos de licencia al proyecto, uno para cada licencia, y aclararía en el archivo Léame qué licencia se aplica en ese caso.
Bart van Ingen Schenau
1
Bart, gracias por compartir cómo lo harías, eso es mucho más útil que algunos de los comentarios que recibí. :) Mientras tanto, he contactado a GitHub al respecto y dejaré esta pregunta abierta por ahora en caso de que algo salga de eso.
Kay
2
Cuando reciba una respuesta de Github, publique esa información como respuesta propia a esta pregunta.
Bart van Ingen Schenau
1
¡Definitivamente lo haré si está bien con ellos, ya que también podría ser interesante saber para los demás!
Kay
12

En una presentación de los creadores de SPDX ( diapositiva 12 ), queda muy claro:

Contenido de LICENSE:

Apache-2.0 OR GPL-2.0-or-later

Luego puede agregar dos archivos de LICENCIA adicionales: LICENSE.Apache-2.0y LICENSE.GPL-2.0-or-later.

En todos los casos, README.mddebe contener un identificador de licencia SPDX :

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

Puedes hacerlo así:

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

Tenga en cuenta que Apache-2.0 OR GPL-2.0-or-latery Apache-2.0 AND GPL-2.0-or-laterhace una gran diferencia. El primero significa que el usuario puede elegir entre ambos (¡lo cual es el caso normal!) Y el segundo indica que el usuario debe cumplir con ambas licencias. Ver también licencias múltiples en Wikipedia.

Tenga en cuenta que estoy usando la nueva (a partir de 2017-12-28 ) SPDX License List 3.0 aquí. Las versiones de 2017 tenían un GPL-2.0identificador para GPL 2.0, pero no estaba claro si eso significaba "solo GPL 2.0" o "GPL 2.0 o cualquier versión posterior".

koppor
fuente
4

Eventualmente me puse en contacto directamente con el soporte de GitHub con respecto a mi pregunta y me dijeron que estaba bien citarlos si dejaba claro que sus respuestas solo eran sugerencias, no recomendaciones.

Nuestro equipo no tiene ninguna recomendación en particular para ofrecer en este momento, ¡pero nos aseguraremos de preguntarle y actualizarlo si tenemos algo más que compartir!

Su respuesta original tenía lo siguiente para ofrecer:

Una sugerencia es tener un archivo de LICENCIA para la mayoría de su código y agregar el texto de las licencias para el resto de los materiales de terceros en su archivo README.

Otra forma es que cada ruta tenga su propio archivo de LICENCIA cuando tenga sentido. Entonces, si, por ejemplo, su repositorio tiene la siguiente ruta: libs / awesome-lib-v2 / podría tener libs / awesome-lib-v2 / LICENSE.

En el último caso, es posible que desee mencionar eso en el archivo README y / o el archivo LICENCIA en su raíz.

También puede considerar usar un solo archivo de LICENCIA en la raíz de su repositorio y agregar subsecciones para cualquier material, código, etc. de terceros.

Kay
fuente