Declarando múltiples licencias en un proyecto GitHub

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)

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.

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".

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.