La LGPL me permet-elle de le faire?

16

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?

Daenyth
la source
6
Le problème avec votre question ici est que vous n'essayez pas d'utiliser la licence dans l'esprit dans lequel elle a été écrite. Nous pouvons probablement répondre aux questions sur la signification prévue des licences, mais nous ne pouvons pas entrer dans les détails juridiques de manière fiable . Pour cela, nous ne pouvons que recommander un avocat. De plus, ce que vous faites dépend d'une question juridique (qu'est-ce qu'un travail dérivé du logiciel LGPLed?) Qui n'a pas été réglée aux États-Unis par la jurisprudence, et j'ai vu des opinions divergentes parmi les vrais avocats. (Je ne suis pas avocat, mais j'ai suivi ces problèmes avec désinvolture.)
David Thornley
Dur à dire. Lisez ceci: javalobby.org/java/forums/t15903.html - ils parlent de Java, mais cela semble applicable à n'importe quel langage OO.
Mike Baranczak

Réponses:

26

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 à <[email protected]>.

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

Mark Booth
la source
4
J'aime la suggestion "demandez à la FSF"
ZJR
Ma lecture était qu'ils voulaient exposer plus de fonctions dans la lib LGPL. Tant que la bibliothèque résultante est toujours LGPL et qu'un utilisateur du logiciel de l'OP est libre de remplacer la bibliothèque par sa version en cours de construction - je serais heureux
Martin Beckett
3
@MartinBeckett - Pas tout à fait, le questionneur tente de contourner la LGPL en modifiant la bibliothèque pour lui permettre de modifier plus subrepticement la bibliothèque dans son code source fermé. S'il ajoutait directement sa nouvelle fonctionnalité de bibliothèque à la LGPL et l'utilisait ensuite dans son propre code, il n'y aurait aucun problème. C'est le fait qu'il essaie de garder sa propre nouvelle fonctionnalité fermée en source tout en faisant toujours partie de la bibliothèque, c'est le problème.
Mark Booth
6
LGPL 3.0 déclare: "La définition d'une sous-classe d'une classe définie par la bibliothèque est considérée comme un mode d'utilisation d'une interface fournie par la bibliothèque." Cela devrait donc être autorisé, au moins sous LGPL 3.0.
David
3
@David - Je crois qu'en modifiant la bibliothèque LGPL pour vous permettre de remplacer une fonction qui ne pourrait normalement pas être remplacée, vous reconnaissez tacitement que votre code est suffisamment couplé qu'il a comme un «basé sur» plutôt qu'un relation «utilisée par» avec la bibliothèque, donc le copyleft faible s'active.
Mark Booth
13

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 .

unholysampler
la source
+1. Pour résumer: nous pensons qu'il ne viole pas LGPL (mais IANAL)
MarkJ
@MarkJ - Comme je l'explique dans ma réponse , je ne suis pas sûr que la question posée soit simplement une question d'héritage de classe.
Mark Booth
9
Je pense que les gens aiment juste taper IANAL car il contient "ANAL".
g33kz0r
5

"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 .

Communauté
la source
1
Le problème est que la LGPL autorise certaines formes d'œuvres dérivées, tout en interdisant d'autres. J'ai mis à jour ma réponse pour faire une distinction entre les œuvres dérivées qui entrent dans la catégorie des travaux basés sur la bibliothèque (qui devait être LGPL) et les travaux qui utilisent la bibliothèque (ce qui n'est pas le cas).
Mark Booth
@MarkBooth Je suis d'accord avec vous et les autres, que dans ce cas c'est work based onparce qu'ils apportent des modifications à LGPL afin d'exposer du code précédemment privé.
1

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)

ZJR
la source
1

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.

Nik.B
la source
1
Votre réponse contredit plusieurs autres réponses mais n'apporte pas grand-chose à l'appui de vos affirmations. D'autres réponses sont plus détaillées et expliquent mieux leurs affirmations. Veuillez modifier votre réponse pour fournir des devis pertinents de la licence ou de la FSF afin de soutenir votre réclamation.
Comment en fait ma réponse ne fournit-elle pas grand-chose pour appuyer mes réclamations? J'avais mis un lien vers la page officielle GNU qui efface la confusion sur LGPL et l'héritage de classe. Il est même mis à jour pour couvrir LGPL v3.
Nik.B