Je voudrais publier une bibliothèque de logiciels écrite dans un langage de programmation orienté objet (Java) basé sur une classe 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 pull demandes). 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 apportées au 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 une fourchette distincte 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 de logiciel propriétaire (éventuellement) ( lien 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 le logiciel 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 existe une LGPL modifiée qui permet la liaison statique.

• Il n'y a pas d'autres différences pertinentes (du 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 de la bibliothèque de logiciels dans un produit propriétaire.
Il n'y a pas de licence qui nécessite également que des extensions de la bibliothèque de logiciels pertinentes pour le travail original soient publiées 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é dans un produit propriétaire (sans libérer la source entière).

Je suis tenté d'utiliser le LPGL modifié , mais d'un autre côté 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: À l'aide de la discussion dans la réponse acceptée, j'ai choisi de m'en tenir à la MPL en raison de la popularité , de la liberté de liaison et parce que c'est une licence officielle et non modifiée .

Je pense que vous avez indiqué avec précision les différences entre la licence publique Mozilla et la licence publique générale générale GNU , et que l'une ou l'autre peut très bien répondre à vos besoins, mais vous ignorez la différence la plus importante entre les deux licences:

Qui peut faire 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 que vous puissiez essentiellement dire "vous pouvez le distribuer conformément à 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 extrêmes 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 "importer 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é au problème que votre bibliothèque essaie de résoudre.

Évidemment, c'est un cas de bord et il est peu probable que quelqu'un veuille le faire, mais c'est un risque que vous devez savoir lorsque vous utilisez le MPLv2.

La LGPL est écrite pour interdire de tels comportements. Voir:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• La LGPL me permet-elle de le faire?

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". Qu'est-ce qu'un "travail basé sur la bibliothèque" en 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 et d'utiliser plus facilement votre bibliothèque, 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 ni 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 gens à créer des logiciels et des modules complémentaires propriétaires (y compris Mozilla lui-même), ce qui est une pratique autorisée par la FSF via LGPL mais considère toujours dangereux.

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.

MODIFIER

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é, ils ont donc 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.