Pourquoi dois-je conserver ma licence de logiciel open source à la racine?

Presque toutes les licences de logiciels open source exigent (ou du moins les avocats suggèrent généralement qu'elles exigent) que les utilisateurs incluent la licence complète à la racine du projet qu'ils protègent.

Un avocat à qui j'ai parlé suggère qu'il s'agit d'un héritage de l'ère du CD, où il était nécessaire qu'une licence complète soit incluse dans un écrin.

Mais aujourd'hui, nous vivons à l'ère du cloud. Pourquoi ne puis-je pas, par exemple, simplement héberger la licence complète sur mon site Web et inclure le titre + l'URL de cette licence dans l'en-tête de mes fichiers source?

Bonus: s'il est généralement admis que les licences établies doivent être conservées intactes à la racine, pourquoi l'OSI de la FSF n'a-t-il pas approuvé une licence à laquelle vous pouvez vous référer par URL, et qu'est-ce qui empêche quelqu'un de créer cette licence?

— samthebrand
source

Un problème qui me vient à l'esprit est que les URL peuvent changer ou être interrompues.

— Aaron Kurtzhals

'Internet n'est pas omniprésent' serait la raison la plus évidente (même si quelqu'un a Internet quand il télécharge votre logiciel, il peut ne pas être disponible pour lui quand il veut l'étendre / le modifier).

— TZHX

Vous demandez-vous pourquoi LA LICENCE ENTIÈRE DOIT ÊTRE INCLUSE à la racine, ou pourquoi la licence entière doit être incluse dans la racine?

— DougM

Je souligne simplement que nous semblons parler d'une fausse dichotomie ici; Vous demandez pourquoi la licence doit être à la racine et pourquoi ne peut-elle pas être en ligne à une URL à la place? Il y a une troisième option: personne n'est mentionné; la licence est fournie avec le logiciel mais dans un répertoire "docs" ou quelque chose et le commentaire dans l'en-tête des fichiers de code reflète cela. Je suis d'accord avec les bonnes raisons pour lesquelles la licence devrait être fournie avec le logiciel, mais cela ne s'arrête pas d'aller dans un répertoire de documentation.

— James

La raison pour laquelle il est presque toujours à la racine est qu'il est facile à trouver. Lorsque je télécharge votre projet, je parcours la racine et l'une des premières choses que je vois est la licence.

— Aussi

Réponses:

De la FAQ GPL (mais les conseils s'appliquent à toutes les licences):

Pourquoi la GPL nécessite-t-elle d'inclure une copie de la GPL avec chaque copie du programme?

Il est essentiel d'inclure une copie de la licence avec l'œuvre pour que tous ceux qui obtiennent une copie du programme puissent connaître leurs droits.

Il peut être tentant d'inclure une URL faisant référence à la licence, au lieu de la licence elle-même. Mais vous ne pouvez pas être sûr que l'URL sera toujours valide dans cinq ou dix ans. Dans vingt ans, les URL telles que nous les connaissons aujourd'hui peuvent ne plus exister.

La seule façon de s'assurer que les personnes qui ont des copies du programme continueront à voir la licence, malgré tous les changements qui se produiront sur le réseau, est d'inclure une copie de la licence dans le programme.

(c'est moi qui souligne)

Au moment où le site qui vous héberge tombe en panne ou modifie ses chemins URL, les personnes qui ont des copies de votre logiciel ne peuvent plus vérifier quels droits ils peuvent exercer en toute sécurité. Supposons même que vous puissiez en quelque sorte garantir que cette URL exacte sera toujours en ligne: la possibilité pour les utilisateurs de vérifier que leur utilisation de votre logiciel est légale dépend toujours de la capacité de se connecter à cette URL particulière. Bien que cette exigence puisse ne pas être onéreuse dans votre ville / pays / planète particulière, elle peut l'être aussi ailleurs. Vous ne devez pas imposer cette exigence, en particulier lorsque la solution de contournement (y compris le texte complet de la licence) est triviale.

Vous pouvez répondre à cette plainte en disant: "Et alors? Si l'URL descend ou n'est pas accessible, un descripteur sans ambiguïté comme 'GNU GPL v3' devrait suffire. Les copies en texte intégral de la GPL sont nombreuses; les utilisateurs peuvent rechercher la licence eux-mêmes. " Quelques problèmes viennent immédiatement à l'esprit:

Cela ne se généralise pas aux identifiants de licence qui sont moins clairs (l'expression "licence BSD" me vient à l'esprit).
Cela ne se généralise pas bien aux licences qui sont moins courantes ou qui ont été personnalisées ("GPL avec exceptions de liaison" vient à l'esprit: quelles exceptions de liaison?). Dans quelle mesure une licence doit-elle être courante avant qu'il soit raisonnable de s'attendre à ce qu'un utilisateur la trouve de manière fiable par son nom?
Cela nécessite toujours que les utilisateurs disposent d'une connexion Internet, ce qui peut ne pas être le cas, même s'ils avaient une connexion au moment où ils ont obtenu le logiciel. (Et ils n'avaient peut-être pas accès à Internet lorsqu'ils ont obtenu le logiciel: "l'ère du CD" n'est pas encore terminée dans de nombreuses régions du monde. Comme cas supplémentaire, considérons les populations nationales qui ont un accès Internet étendu mais en censurent une grande partie .) Une conséquence d'un logiciel librement redistribuable est qu'un destinataire peut ne pas recevoir une copie de votre logiciel directement de vous ou par le biais d'un canal de distribution que vous aviez prévu à l'origine.

Un dernier argument contre les liens de licence est noté par le commentaire de MichaelT ci-dessous: il pourrait vous permettre de modifier dynamiquement et rétroactivement la licence. Cela pourrait être fait intentionnellement, mais cela pourrait également être fait par accident, si vous modifiez la licence entre les versions du logiciel, mais que vous utilisez le même lien de licence pour les deux versions, détruisant ainsi votre ancienne licence. Un tel changement ajouterait de la difficulté aux personnes qui doivent prouver qu'elles ont obtenu leur ancienne copie sous une licence différente de la version actuelle.

Alors pourquoi dois-je conserver la licence à la racine du projet?

Je ne suis pas avocat, mais je ne l' ai jamais vu aucun argument convaincant que vous avez besoin de garder des licences dans la racine du projet. Même la GPL, qui précise que la licence doit accompagner chaque copie de l'œuvre, ne dit pas comment elle doit accompagner l'œuvre. (Cela peut être dû au fait que la GPL pourrait être appliquée dans des contextes non logiciels, où la notion de "répertoire racine" n'a pas de sens.)

Garder la licence dans le répertoire racine est probablement une bonne idée car elle maximise la probabilité que l'utilisateur la voie, et minimise ainsi à la fois la frustration de l'utilisateur et la probabilité de plaintes contre vous pour avoir tenté de cacher la licence dans un répertoire obscur. Si vous avez plusieurs licences, il peut être plus judicieux de les placer toutes dans leur propre dossier et d'inclure un fichier README de projet évident qui contient des chemins de fichier pour trouver la licence pour chaque composant.

Placer votre licence dans la racine du répertoire est également une pratique utile car cela peut lever l'ambiguïté des licences des modules dont la licence est différente de celle du travail dans son ensemble. Supposons que mon projet FooProj utilise le module autonome BarMod. FooProj peut être sous licence GPL, tandis que le module autonome peut être sous licence MIT. Lorsque j'ouvre FooProj pour la première fois, je vois une copie de la GPL à la racine et je comprends que le travail dans son ensemble est sous licence GPL. Lorsque je descends dans le dossier de BarMod, j'y vois un nouveau fichier de licence et je comprends que le contenu de ce dossier est sous licence MIT. Bien sûr, ce n'est qu'une aide utile; vous devez toujours indiquer la licence de vos modules de manière explicite dans un fichier README, NOTICE ou similaire.

En résumé, l'utilisation de la racine du fichier est une question de commodité et de clarté. Je n'ai vu aucun texte de licence open source juridiquement contraignant qui l'exige, et je ne connais aucune raison pour laquelle il serait légalement requis. Votre licence doit être raisonnablement facile à découvrir pour le destinataire; l'inclusion de la licence dans la racine du projet est suffisante, mais pas nécessaire, pour satisfaire ce critère.

— absides
source

Considérez également la possibilité que vous établissiez un lien vers un site distant pour site.com/foo/license.txt que vous avez obtenu sous une licence BSD, mais depuis lors, il a été sous licence GPL v3 et c'est ce que site.com/foo/license. txt contient maintenant. Mais la version que vous avez téléchargée a des droits différents.

J'ai marqué cette réponse comme correcte, car elle semble exposer la sagesse conventionnelle et juridique concernant les licences OSS. Cela dit , cette pensée me semble un peu paranoïaque pour ce monde sauvegardé et contrôlé par version dans lequel nous vivons. Je ne suis pas sûr que le risque de falsification de contenu canonique d'URL soit plus grand que le risque de suppression accidentelle d'une partie de une licence contenue dans la racine. Et même si le risque est plus grand, je suis sceptique quant au fait qu'il soit si formidable d'obliger les développeurs à inclure des licences complètes dans leur logiciel, au lieu, par exemple, de citer des licences hébergées en externe dans les commentaires de code.

— samthebrand

Pour info, peut-être un signe de choses à venir pour les licences OSS: Creative Commons 4.0 permet aux titulaires de licence de créer un lien vers une page distincte qui inclut des informations d'attribution.

— samthebrand

Mais aujourd'hui, nous vivons à l'ère du cloud. Pourquoi ne puis-je pas, par exemple, simplement héberger la licence complète sur mon site Web et inclure le titre + l'URL de cette licence dans l'en-tête de mes fichiers source?

Il existe des licences qui le permettent. Apache 2.0, par exemple. Apache 2.0 nécessite uniquement que chaque fichier source contienne un petit en-tête qui pointe vers l'URL canonique de la licence Apache 2.0. Il n'est pas nécessaire de reproduire la licence complète dans l'arborescence source.

Depuis la licence Apache 2.0 elle-même:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

— Chadversary
source

Je pense que l'annexe est incomplète ou au moins fonctionne avec l'hypothèse que vous incluez déjà une copie de la licence. Du texte 2.0 lui - même , lors de la distribution de l'oeuvre sous licence Apache:4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;

— apsillers

Il n'est pas nécessaire qu'il soit à la racine du projet. C'est simplement l'endroit le plus commun, et donc le premier endroit où les gens vont chercher pour trouver la licence. D'ailleurs, même si ce n'était pas courant, c'est probablement le premier endroit où les gens regarderont. Puisque la licence existe pour informer, cacher les informations n'a pas beaucoup de sens.

Si vous le cachez derrière une URL, il n'y a aucune garantie absolue que cette URL sera toujours disponible. S'il s'agit d'un fichier à la racine du projet, par définition, il sera toujours disponible.

En bref, c'est l'endroit le plus efficace et le plus convivial pour le mettre.

— Bryan Oakley
source

La racine du projet est le premier endroit où l'on pourrait regarder: c'est le haut de l'arborescence, la racine de la hiérarchie des dossiers. Toute la documentation de haut niveau doit y aller: fichier lisez-moi, licence, etc. Ces fichiers peuvent diriger le lecteur pour creuser plus profondément ailleurs dans le projet, mais la racine est le premier endroit où je cherche quoi que ce soit.