Déclaration de plusieurs licences dans un projet GitHub

Pendant des années, j'ai été un grand fan de mettre des licences sur des choses partagées en ligne pour permettre aux autres de déterminer plus facilement si et comment ils peuvent réutiliser ces choses. Avant que GitHub ne commence à `` pousser '' doucement ses utilisateurs à inclure des fichiers de LICENCE avec leurs dépôts, je ne savais pas vraiment comment le faire avec du code - en particulier le code partagé publiquement sur GitHub! - mais j'ai essayé de faire bon usage des fichiers de LICENCE depuis.

Je suis maintenant dans la situation où j'ai travaillé sur un petit projet avec d'autres personnes, ce qui nécessite la mention de plusieurs licences (en raison de code et de bibliothèques tiers ainsi que de fichiers non-code). Alors que mes partenaires abordent la question plutôt «négligemment» - il a été suggéré de «simplement mettre le code en ligne tel quel, personne ne s'en souciera» -, je préfère le faire correctement. Le problème est: je ne sais pas comment on est censé mentionner plusieurs licences (différentes) sur GitHub.

J'ai vu plusieurs solutions différentes sur GitHub, c'est pourquoi il est difficile pour moi de juger si cette réponse à une question légèrement différente fait autorité. Ce que j'aimerais savoir, c'est laquelle des options suivantes - le cas échéant - est la plus courante, ou s'il existe d'autres moyens supplémentaires de procéder.

1. Créez un seul fichier de LICENCE et insérez-y les descriptions de toutes les différentes licences. ( Questions : Doit-on les placer dans un ordre particulier? Est-ce que je commencerais le dossier en mentionnant les noms de toutes les licences contenues dans, pour une meilleure vue d'ensemble)?
2. Créer un fichier de licence par licence utilisée et de les nommer LICENSE.md, LICENSE.LibNameA.md, LICENSE.AssetsB.mdetc. , comme le suggère la réponse liée. ( Question : La dénomination serait basée sur les noms de projet? Pas sur les noms de licence? Si j'utilisais plus d'une licence pour du matériel auto-fourni, est-ce que je les mentionnerais tous dans le 'principal' LICENSE.md? Sinon, que ferais-je à la place?)
3. Créez deux fichiers de LICENCE : l'un répertoriant la (les) licence (s) pour le contenu «principal», c'est-à-dire l'ensemble du code / des actifs que vous avez créé; un pour tout le matériel tiers. ( Questions comme ci - dessus : existe-t-il un schéma de nommage particulier que l'on utiliserait et l'ordre dans lequel on répertorierait les matériaux tiers?)

Enfin, si j'ai bien compris les différentes explications et projets de GitHub concernant leur API Licences, seul le fichier de LICENCE `` principal '' sera pris en compte lors de la détermination de la licence d'un référentiel (bien que je n'aie pas pu déterminer quelle licence serait choisie si plusieurs ont été mentionnés).

Vous pouvez utiliser n'importe quel mécanisme pour inclure les licences que vous aimez, tant qu'il devient clair pour un visiteur de votre projet quelle licence est applicable à quelle partie du projet.

Ma préférence serait:

• Placez chaque bibliothèque tierce que vous utilisez dans son propre répertoire. Ce répertoire doit contenir tous les fichiers qui font partie de la distribution de la bibliothèque, y compris les fichiers de licence et les fichiers Lisez-moi.
• Dans votre propre fichier de licence, ne vous référez qu'à la licence de votre propre code
• Dans le fichier Lisez-moi de votre projet, mentionnez les bibliothèques tierces que vous utilisez et la licence sous laquelle chaque bibliothèque est distribuée. Pour plus de détails sur la licence, reportez-vous au fichier de licence dans le répertoire de la bibliothèque.

Dans une présentation des créateurs SPDX ( diapo 12 ), il est très clair:

Contenu de LICENSE:

Apache-2.0 OR GPL-2.0-or-later

Vous pouvez ensuite ajouter deux fichiers de LICENCE supplémentaires: LICENSE.Apache-2.0et LICENSE.GPL-2.0-or-later.

Dans tous les cas, le README.mddoit contenir un identifiant de licence SPDX :

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

Vous pouvez le faire comme ça:

## 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`

Notez cela Apache-2.0 OR GPL-2.0-or-lateret Apache-2.0 AND GPL-2.0-or-laterfait une grande différence. Le premier signifie que l'utilisateur peut choisir entre les deux (ce qui est le cas normal!) Et le second indique que l'utilisateur doit se conformer aux deux licences. Voir aussi multi licences sur Wikipedia.

Notez que j'utilise la nouvelle liste de licences SPDX 3.0 (en date du 28/12/2017 ) ici. Les versions de 2017 avaient un GPL-2.0identifiant pour GPL 2.0, mais il n'était pas clair si cela signifiait "GPL 2.0 uniquement" ou "GPL 2.0 ou toute version ultérieure".

J'ai finalement contacté le support GitHub directement en ce qui concerne ma question et ils ont dit qu'il était OK de les citer si je précisais que leurs réponses n'étaient que des suggestions, pas des recommandations.

Notre équipe n'a pas de recommandations particulières à proposer pour le moment, mais nous nous assurerons de vous demander et de vous informer si nous avons autre chose à partager!

Leur réponse originale avait à offrir:

Une suggestion est d'avoir un fichier de LICENCE pour la majorité de votre code et d'ajouter le texte des licences pour le reste du matériel tiers dans votre fichier README.

Une autre façon consiste à ce que chaque chemin ait son propre fichier de LICENCE quand cela a du sens. Ainsi, si, par exemple, votre référentiel a le chemin suivant: libs / awesome-lib-v2 / vous pourriez avoir libs / awesome-lib-v2 / LICENSE.

Dans ce dernier cas, vous voudrez peut-être le mentionner dans le fichier README et / ou le fichier LICENSE dans votre racine.

Vous pouvez également envisager d'utiliser un seul fichier LICENCE à la racine de votre référentiel et ajouter des sous-sections pour tout matériel, code, etc., tiers.