LGPL 2.1 vs LGPL 3.0 Avantages et inconvénients
D'après ce que j'ai lu, LGPL 3.0 vous permet d'utiliser la licence avec d'autres licences, plus permissives à ce sujet (je n'en suis même pas sûr).
D'après https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility il indique qu'il n'est pas compatible avec GPLv2, tandis que LGPL 2.1 est compatible avec lui. C'est un peu contraire à ce que j'ai lu ...
Alors, savez-vous quels sont les avantages et les inconvénients réels de LGPL 3.0 par rapport à LGPL 2.1?
Un inconvénient serait qu'il n'est pas compatible avec la GPLv2.
Je pense que vous devez commencer par l'intention de la LGPL 2.1 et de la LGPL 3. La LGPL 2.1 a été conçue pour être une licence écrite en grande partie en anglais simple qui donnerait aux programmeurs des conseils sur ce qu'ils pourraient faire avec le logiciel. Elle est généralement plus claire que la GPL 2 en raison de la liaison refuge. Une incertitude majeure concernant la GPL est de savoir si un détenteur de droits d'auteur a même un intérêt à contrôler quels programmes peuvent être liés à une bibliothèque protégée par des droits d'auteur. La LGPL supprime cette incertitude en offrant un havre sûr concernant les liaisons.
Cependant, le principal inconvénient de cette approche est qu'elle dépend généralement des concepts juridiques américains et autres, et des définitions juridictionnelles. Ce qui peut être un travail dérivé dans une juridiction peut ne pas l'être dans une autre et cela fait une différence significative lorsque le logiciel est groupé et distribué, et l'autorisation est accordée pour l'agrégation mais pas la dérivation. La LGPL a moins de problèmes ici que la GPL, mais c'est une incertitude importante, en particulier dans la GPL qui est une licence complémentaire.
Pour résoudre certains de ces problèmes et fournir un meilleur contrôle des droits exacts, la série de licences GPL v3 a été rédigée (la LGPL 3 en fait partie). Ceux-ci cherchent à supprimer les définitions juridictionnelles de dérivation et d'agrégation et à réécrire le langage afin qu'il fournisse des conseils aux avocats plutôt qu'aux programmeurs. Les licences sont beaucoup plus complexes, utilisant de loin des structures plus accessibles aux avocats que les programmeurs, et pas nécessairement moins vagues [1]. Cependant, ils parviennent dans une certaine mesure à contourner les définitions des compétences.
Donc, le premier compromis est de savoir si vous voulez écrire votre licence comme celle que le public est un programmeur contre le public est un avocat et le second est à quel point vous vous préoccupez des définitions internationales dans différentes juridictions.
La dernière, cependant, est que la série de licences GPL v3 a forcé la compatibilité avec l'AGPL v3, ce qui signifie que le code peut être extrait des programmes GPL et que les restrictions supplémentaires de l'AGPL sont ajoutées de telle manière que cela ne peut pas être réintroduit sous la même licence. Il s'agit d'un problème avec la copie LGPL -> GPL également sur l'une ou l'autre licence, il s'agit donc probablement d'une préoccupation relativement mineure.
Moi-même, je préfère les licences GPL v2 et LGPL 2.1 parce qu'elles sont plus simples et je pense donc qu'il y a moins de possibilité qu'un malentendu majeur se produise (des malentendus mineurs peuvent être plus courants cependant), mais c'est ma préférence personnelle, et le vôtre peut varier.
[1] Par exemple, si vous lisez à la fois la licence BSD à 2 clauses et la GPL v3 (et par extension la LGPL b3), ces licences sont incompatibles car les licences BSD ne mentionnent pas explicitement la sous-licence contrairement au MIT licences et donc au moins certains avocats comme Larry Rosen ne croient pas qu'une telle licence soit accordée. Par conséquent, vous ne pouvez pas simplement prendre le code BSD et le redistribuer en tant que GPL v3 sans ajouter des modifications dignes de copyright. convient que les licences BSD et GPL v3 sont compatibles, ce qui pose cependant des problèmes importants d'interprétation des licences et du dessin au trait.