La LGPL me permet-elle de le faire?

Je prévois de développer un logiciel commercial à l'aide d'un logiciel LGPL.

Dans le logiciel LGPL que j'utilise, certaines fonctions d'une classe ne sont pas entièrement implémentées. Je souhaite modifier le code LGPL afin que la classe et les fonctions non implémentées soient rendues visibles en dehors de la DLL en ajoutant dllexport en face de la classe et en ajoutant un mot clé virtuel en face de la fonction.

Ensuite, je prévois d'implémenter ces fonctions dans mon logiciel propriétaire. Je suis prêt à distribuer le code LGPL modifié mais pas un logiciel propriétaire qui implémente les fonctions comme je le souhaite.

Cela viole-t-il les conditions générales de LGPL?

C'est une question complexe, mais je pense que ce que vous proposez n'est pas autorisé.

Vous suggérez d' ajouter des crochets dans la bibliothèque pour le rendre plus facile pour vous de sous-classe de la bibliothèque et donc, à tout le moins. contourner l' esprit de la LGPL.

Le problème est que si vous sous-classe une classe soumise à la licence LGPL dans votre propre code, alors votre travail devient un travail basé sur la bibliothèque , plutôt qu'un travail qui utilise la bibliothèque, ce qui signifie que votre code est un dérivé travaux couverts par la section 2 ( LGPL v2.1 ) plutôt que ceux couverts par la section 6 ( LGPL v2.1 ). C'est-à-dire qu'il devient soumis à la LGPL !

Je pense que Stephen Colebourne fournit un bon résumé sur javalobby.

Je ne suis pas un grand fan de réflexions à propos de vos suggestions d' avocat , mais dans ce cas, je pense que cela en vaudrait la peine si vous envisagez de procéder, sinon vous pourriez recevoir une méchante lettre du logiciel libre Fondation Équipe juridique de la .

Vous pouvez également demander directement à la FSF . Depuis leur page de contact :

Pour des questions sur les licences de logiciels libres et les droits d'auteur

Veuillez consulter notre FAQ sur les licences , la liste des licences , les informations générales sur le copyleft et les pages connexes . Si des questions persistent, envoyez un e-mail à <licensing@gnu.org>.

Soit dit en passant , dans la question connexe Réflexion et LGPL , gbjbaanb répond avec la perspective LGPL 3.0 .

Standard Je ne suis pas un déni d'avocat.

LGPL exige que des modifications du code source de la bibliothèque soient distribuées à toute personne qui a utilisé votre code. Il ne nécessite pas que votre code, qui utilise la bibliothèque, soit open source et publié sous la même licence.

Wikipédia pour une description plus détaillée mais non juridique de la LGPL, y compris une section sur l' héritage de classe .

"Je veux modifier le code LGPL ..." cela en dit assez que vous devez libérer tout ce code modifié. Puis étendre si l'extension ou non de ce code modifié est un travail dérivé est sujet à controverse et, dans l'affirmative, il devient soumis à la LGPL.

Il semble que vous essayez de contourner la LGPL, ce qui, dans ce cas, avec ces techniques, vous ne pouvez pas.

S'il s'agit d'un travail dérivé, les termes du programme doivent permettre une "modification pour le propre usage du client et une ingénierie inverse pour le débogage de ces modifications". Qu'une œuvre utilisant un programme LGPL soit une œuvre dérivée ou non est un problème juridique.

Mais si ce que vous essayez de faire est de contourner la LGPL, je contacterais la FSF comme recommandé par Mark Booth .

Ma conjecture: (mais IANAL) vous devez libérer en open source la bibliothèque modifiée en tant que code LGPL, puis déposer dans un programme commercial. Ça marcherait. En fait, vous finirez par avoir un fork open source de la bibliothèque et vous vendrez un frontal pour cela.

Mais comme beaucoup d'autres l'ont dit à juste titre, demandez à la FSF : c'est un scénario patologique intrigant que vous avez là; ils pourraient se demander autant que vous si c'est applicable ou non. (ou au moins vous en souciez suffisamment pour publier une entrée FAQ sur le sujet)

https://www.gnu.org/licenses/lgpl-java.html

Si vous distribuez une application Java qui importe des bibliothèques LGPL, il est facile de se conformer à la LGPL. La licence de votre application doit permettre aux utilisateurs de modifier la bibliothèque et effectuer une rétro-ingénierie de votre code pour déboguer ces modifications. Cela ne signifie pas que vous devez fournir du code source ou des détails sur les composants internes de votre application. Bien sûr, certaines modifications que les utilisateurs peuvent apporter à la bibliothèque peuvent briser l'interface, rendant la bibliothèque incapable de fonctionner avec votre application. Vous n'avez pas à vous en préoccuper: les personnes qui modifient la bibliothèque sont responsables de son bon fonctionnement.

En bref, il n'y a pas de problème d'héritage tant que vous ne modifiez pas le code de la bibliothèque lui-même, mais même si vous le changez, vous devez publier uniquement le code modifié de la bibliothèque, pas votre code d'application.