Mozilla Public License (MPL 2.0) vs Lesser GNU General Public License (LGPL 3.0)
Je voudrais publier une bibliothèque de logiciels écrite dans un langage de programmation orienté objet (Java) sur un service d'hébergement de code source basé sur le Web , qui permet aux fourches du projet d'être fusionnées dans le projet principal (GitHub via les demandes de tirage). J'ai fait des recherches sur le Web et j'ai beaucoup réfléchi à la façon de concéder une licence sur le logiciel. Ai-je raison dans les hypothèses suivantes (du point de vue IANAL )?
LGPL et MPL favorisent le partage des modifications du logiciel sous licence LGPL/MPL utilisé dans d'autres projets logiciels. Au lieu d'exiger que les utilisateurs de la bibliothèque modifiée hébergent un fork séparé de la bibliothèque, je peux promouvoir la contribution à la bibliothèque d'origine (par exemple via des demandes de tirage).
La principale différence réside dans la manière dont le code sous licence MPL/LGPL doit être lié au projet. Les fichiers de code source MPL peuvent être directement copiés dans un projet logiciel (éventuellement) propriétaire ( liaison statique ), tandis que le code sous licence LGPL doit être lié dynamiquement (vaguement lié au projet de logiciel éventuellement propriétaire, afin que les utilisateurs finaux puissent changer la bibliothèque de logiciels sous licence pour une autre version de la bibliothèque de logiciels sous licence).
La liaison dynamique et donc la LGPL impose des obstacles supplémentaires pour empaqueter le produit logiciel propriétaire, sans promouvoir plus de contributions à la bibliothèque de logiciels open source qu'en ayant une liaison statique (et donc MPL). Il y a LGPL modifié qui permet la liaison statique.
Il n'y a aucune autre différence pertinente (d'un point de vue IANAL ).
Les anciennes versions de licence ne conviennent pas à mes besoins aussi bien que les plus récentes.
Comme vous pouvez le voir, ma principale exigence est que les modifications de la bibliothèque de logiciels qui pourraient s'avérer utiles au grand public restent open-source, sans imposer de restrictions sur l'utilisation la bibliothèque de logiciels dans un produit propriétaire.
Il n'y a pas de licence qui nécessite également des extensions de la bibliothèque de logiciels qui sont pertinentes pour le travail original à publier en open-source, car la portée du terme pertinent peut être arbitrairement petite/énorme, se terminant ainsi en GPL qui ne peut pas être utilisée dans un produit propriétaire (sans publier le source entière).
Je suis tenté d'utiliser le LPGL modifié , mais par contre découragé par l'impopularité. Sur la base des points ci-dessus, je préfère MPL.
Question: Mes déclarations ci-dessus sont-elles correctes? Quelle licence dois-je choisir en fonction de mes besoins?
Solution: Avec l'aide de la discussion dans la réponse acceptée, j'ai choisi de m'en tenir à la MPL à cause de la popularité , liberté de liaison et parce qu'il s'agit d'une licence officielle et non modifiée .
Je crois que vous avez indiqué avec précision les différences entre la Mozilla Public License et la GNU Lesser General Public License , et l'une ou l'autre peut très bien répondre à vos besoins, mais vous sautez la différence la plus importante entre les deux licences:
Qui peut créer de nouvelles versions?
Tant la MPL (section 10) que la LGPL (section 14) incluent dans leur licence le droit de remplacer la version actuelle par une dernière version, et il n'y a aucune limitation réelle quant à ce qui peut être inclus dans ces licences. Bien qu'il soit hautement improbable que la Fondation Mozilla ou la Free Software Foundation fassent quelque chose d'aussi fou que, disons, d'instituer une clause qui dit que "toutes les contributions à ce logiciel deviennent notre propriété", il n'est pas hors de portée que l'un des les organisations publieront une nouvelle version de licence que vous n'aimez pas.
Ce qui soulève un autre point sur l'utilisation d'une "LGPL modifiée".
Une licence modifiée n'est pas la même licence!
Bien que vous ayez une capacité assez étonnante à spécifier vos propres conditions de licence, et pourriez essentiellement dire "vous pouvez le distribuer selon la GPL, mais vous devez mettre mon nom dans vos crédits et me payer 1% des revenus que vous générez ", chaque fois que vous le faites, vous créez une nouvelle licence basée sur le travail de quelqu'un d'autre. Cela signifie que vous n'utilisez PAS la MPL ou la LGPL, vous utilisez une nouvelle "licence mucaho".
Cela signifie que vous n'obtiendrez probablement aucune aide de l'auteur de votre licence d'origine si vous avez besoin de défendre votre interprétation de la licence à l'intérieur d'une salle d'audience, et il est tout à fait possible qu'ils puissent intenter une action pour dire que LEUR version devrait s'appliquer et pas le vôtre.
Bien sûr, ces deux points sont mineurs. Même la "popularité de licence" n'a pas d'importance, sauf si vous vous attendez à ce que votre code soit directement incorporé dans des projets plus importants.
Personnellement, je pense que le MPL est un meilleur choix si vous aimez la compatibilité propriétaire, ou si le choix est entre le MPL réel et une licence différente que vous devez modifier manuellement en fonction de la LGPL. Sauf si vous avez une raison de ne pas utiliser le MPL, optez pour quelque chose soutenu par une fondation au lieu d'un qui pourrait vous laisser dans une salle d'audience sans aucune aide.
La réponse de DougM et AER fait valoir un argument valable. MPLv2 et LGPLv3 avec exception statique sont les mêmes en ce qui concerne les événements qui déclencheraient le copyleft. Cependant, je pense qu'il nous manque une autre différence très importante entre LGPL et MPL. Lorsque le copyleft est déclenché, le copyleft s'applique à:
- pour MPL: aux mêmes fichiers très exacts de votre bibliothèque d'origine
- pour LGPL: au "travail basé sur la bibliothèque" par opposition au "travail qui utilise la bibliothèque". La LGPL peut donc potentiellement étendre son copyleft à de nouveaux fichiers.
Edge-case: l'utilisation de MPL permet aux utilisateurs de ne pas partager leurs améliorations
MPL est une licence de copyleft au niveau fichier. Cela signifie que si quelqu'un l'intègre dans un projet plus grand (de manière statique ou dynamique) et apporte une modification à votre fichier, il n'a qu'à libérer la modification apportée à ce fichier particulier.
Si vous souhaitez conserver l'intégrité de votre base de code ouverte, il existe des cas Edge dans lesquels cet effet copyleft de MPL peut ne pas être suffisant.
Par exemple, quelqu'un pourrait prendre l'un des fichiers principaux de votre projet, ajouter "import my_private_new_file" , et modifier votre méthode principale par exemple en ajoutant "my_private_new_file.newAwesomeFeature.run ()" .
Et de cette façon, il pourrait ajouter de nouvelles fonctionnalités à votre projet tout en ne libérant que le fichier principal modifié et en conservant la logique réelle de la nouvelle fonctionnalité fermée dans "my_private_new_file" .
Le fait de renvoyer le fichier principal à la communauté vous donne simplement l'information que "vous avez ajouté une nouvelle fonctionnalité" mais cela ne vous permet pas d'incorporer cette nouvelle fonctionnalité à l'air libre ... Cela peut être ennuyeux si la nouvelle fonctionnalité est étroitement -liés au problème que votre bibliothèque essaie de résoudre.
Évidemment, c'est un cas Edge et il est peu probable que quelqu'un veuille le faire, mais c'est un risque dont vous devez être conscient lorsque vous utilisez le MPLv2.
La LGPL est écrite pour interdire de tels comportements. Voir:
Je cite la licence LGPL originale:
Portez une attention particulière à la différence entre un "travail basé sur la bibliothèque" et un "travail utilisant la bibliothèque". Le premier contient du code dérivé de la bibliothèque, tandis que le second doit être combiné avec la bibliothèque pour fonctionner.
Le copyleft s'applique uniquement au "travail basé sur la bibliothèque". Maintenant, qu'est-ce qu'un "travail basé sur la bibliothèque" dans la pratique? Elle laisse place à l'interprétation. Ce qui n'est pas seulement une bonne chose car cela signifie que se conformer à votre licence devient plus compliqué et donc effrayant. Cela pourrait conduire certaines personnes à ne pas utiliser votre bibliothèque.
En ce sens, LGPL est plus restrictive que MPL, mais aussi plus protectrice de l'intégrité du projet.
MPL permet aux utilisateurs du monde propriétaire de réparer plus facilement votre bibliothèque et de l'utiliser, tout en devant partager le correctif
Un avantage pour MPL est que si un utilisateur trouve un bogue dans votre bibliothèque, il peut le corriger directement dans le fichier, sans avoir à donner tout son code mais seulement à le corriger. En pratique, lors de la distribution de son travail à un client, il peut simplement fournir un lien vers un fork de votre projet contenant le correctif, et il est bon.
En utilisant LGPL, les choses sont plus compliquées. Si quelqu'un bifurque votre projet, corrige un bogue et l'intègre statiquement dans son logiciel propriétaire, il doit distribuer à ses utilisateurs le "travail basé sur la bibliothèque" sous la LGPL. Ce qui est une notion assez obscure, surtout lorsque la bibliothèque est intégrée statiquement ... À cet égard, je pense que c'était la raison d'origine pour laquelle il n'y a pas d'exception "statique" dans la LGPL d'origine. Cela rend l'identification du "travail basé sur la bibliothèque" triviale: c'est la bibliothèque dynamique que vous appelez dans votre logiciel propriétaire.
Par conséquent, MPL permet aux fournisseurs propriétaires d'utiliser plus facilement ET d'envoyer des correctifs à votre bibliothèque que LGPL.
Dans le même temps, la plupart du temps, les fournisseurs propriétaires n'ont pas les ressources ni le temps de plonger dans votre bibliothèque compliquée et ne le répareraient probablement pas d'eux-mêmes. Ils préfèrent ouvrir un problème sur votre dépôt GitHub, ou envoyer un e-mail dans la liste de diffusion et attendre votre correctif.
À cet égard, LGPL applique davantage ce type de comportement. Mais l'application est-elle vraiment nécessaire?
Conclusion
Choisir entre LGPL et MPL est une question délicate et, comme d'habitude avec une licence logicielle, dépend de votre objectif. Les deux licences sont très similaires mais en même temps extrêmement différentes. Ils ont été conçus pour des objectifs et une philosophie très différents.
LGPL a été créé par la Free Software Foundation pour permettre l'utilisation généralisée des bibliothèques de logiciels libres dans le monde propriétaire mais avec toujours en tête l'idée de promouvoir les logiciels libres et de lutter contre les logiciels propriétaires. Tout cela fait partie d'une stratégie envers leur idéologie. Voir: https://www.gnu.org/licenses/why-not-lgpl.html
MPL est une licence pratique conçue par Mozilla pour appliquer une sorte de partage à la bibliothèque d'origine, tout en encourageant les utilisateurs à créer des logiciels propriétaires et à ajouter ons on top (y compris Mozilla lui-même), qui est une pratique que la FSF autorise via LGPL mais considère toujours nuisible.
Par essence, MPLv2 est considéré par beaucoup comme une licence permissive, tandis que LGPLv3, y compris avec exception statique, est rarement appelé de cette façon.
ÉDITER
J'ai oublié de mentionner quelque chose d'important. LGPLv3 (avec ou sans exception statique) interdit la tivoisation . Vous pensez peut-être que c'est un "détail", mais ce n'est pas le cas, selon votre objectif. Vous vous souciez de la liberté des utilisateurs? Ce n'est donc pas un détail. Vous souciez-vous que votre bibliothèque puisse être utilisée sur l'appareil d'Apple? VLC se soucie plus d'être utilisé, donc ils ont décidé d'utiliser LGPLv2 qui ne contient pas une telle restriction. De même, c'est l'une des raisons pour lesquelles Linux continue d'utiliser la GPLv2 . MPLv2 n'a pas non plus de restriction de tiviation, car il s'agit évidemment d'une licence créée avec la philosophie Open Source plus "pratique" à l'esprit, pas l'idéologie FSF.
Il pourrait y avoir d'autres choses "mineures" comme celle-ci que j'ai ratées.