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.

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)?
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?)
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).

licensing github

— Kay
source

Ayez donc un fichier README et un ou plusieurs fichiers de LICENCE. Ce n'est pas sorcier.

— Robert Harvey

En ce qui concerne la page liée: cela n'a rien à voir avec la distribution des fichiers de licence, cela a à voir avec l'API Licences de GitHub qui détermine / rend compte de la licence d'un dépôt. Comme je demandais sur les licences / l'utilisation des fichiers de licence sur GitHub spécifiquement, pas open source ou git en général, comme un projet open source est « représentée » à une licence là - bas est trop pertinent. «Ce n'est pas sorcier» n'est pas particulièrement utile, btw., Esp. pas dans le contexte de ma question axée sur GitHub.

— Kay

Je pourrais suggérer que votre fichier README comporte une section sur les licences, indiquant simplement qu'il existe plusieurs licences et informant pour chaque licence, le nom du fichier de LICENCE dans lequel il se trouve?

— Erik Eidt

@immibis J'en suis conscient et ce n'est pas du tout l'objet de ma question. Je demandais spécifiquement une réponse concernant `` la manière la plus logique pour les humains '' (sur: GitHub).

— Kay

@immibis: "Aucun compilateur ne le lira" - le problème est qu'à proprement parler, ce n'est pas vrai pour Github. Github utilise un outil automatique pour déterminer "la" licence appliquée au contenu du référentiel. Le nom de la licence ainsi déterminée sera ensuite affiché dans la barre de titre du référentiel, ainsi que des informations plus générales qui fournissent aux visiteurs une impression de base du projet (par exemple, le nombre de contributeurs et de versions).

— OR Mapper du

Réponses:

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.

— Bart van Ingen Schenau
source

Comment géreriez-vous votre propre fichier de LICENCE dans le cas d'une double licence de contenu propre dans ce scénario? C'est-à-dire si vous avez utilisé différentes licences pour différentes parties du projet (code vs fichiers multimédias) ou si vous vouliez distribuer votre code sous deux (ou plus) licences logicielles différentes? Mettre des informations supplémentaires dans le README a beaucoup de sens et c'est ce que je ferais aussi, mais je suis particulièrement intéressé par la façon de gérer les fichiers de LICENCE sur GitHub (qui, à mes yeux, sont encouragés à donner aux visiteurs / téléspectateurs de le projet un aperçu rapide).

— Kay

Si (certaines parties) de mon propre code ont une double licence, j'ajouterais deux (ou plus) fichiers de licence au projet, un pour chaque licence, et je préciserais dans le fichier Lisez-moi quelle licence s'applique dans quel cas.

— Bart van Ingen Schenau

Bart, merci d'avoir partagé comment vous le feriez - c'est beaucoup plus utile que certains des commentaires que j'ai reçus. :) En attendant, j'ai en fait contacté GitHub à ce sujet et je laisserai cette question ouverte pour le cas où quelque chose en sortirait.

— Kay

Lorsque vous obtenez une réponse de Github, veuillez publier ces informations comme réponse automatique à cette question.

— Bart van Ingen Schenau

Je le ferai certainement si ça leur convient, car il pourrait être intéressant de le savoir pour les autres aussi!

— Kay

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

— koppor
source

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.

— Kay
source