Suite à une petite reflexion personelle sur la licence GPL et LGP, je me suis posé la question suivante :
Si vous etes un decideur pressé, reportez vous directement a la fin du journal pour une version simplifiée de mon problème ;)
Soit un premier logiciel A sous GPL et un seconde logiciel B sous licence LGP, encapsulant les fonctionnalités de A. Le role de B est de jouer une interface entre le logiciel A et d'autres logiciels, ce qui dans la pratique peut se trouver dans les cas suivants :
- B peut par exemple etre un "binding" permettant d'utiliser les foncionnalités de A sans utiliser le meme langage ;
- B peut etre une interface (au sens POO), et A l'implementation de cette interface.
La question est donc la suivante :
Quelle doit etre la licence de C, C n'utilisant que B ?
En effet, dans la pratique, C n'est lié qu'a B, A n'etant pas necessaire (puisque la liaison entre A et B a deja ete faite). B etant sous licence LGPL, je peux tres bien mettre C sous une licence non libre.
En fait ce que je viens de dire est peut etre faux. Mais suivant ces deux cas, je me suis retrouvé fasse a deux problemes :
C peut etre sous licence non libre :
Dans ce cas, la licence GPL n'a plus aucun interet car toute bibliotheque sous licence GPL pourra etre encapsulée par une biblio en LGPL. Ainsi, une lib telle que QT sous licence GPL pourrait etre utilisée dans un contexte commercial en toute legalité.
C doit etre sous une licence compatible GPL
Dans ce cas, je dois m'assurer que TOUT le code utilisé directement et indirectement DOIT etre sous une licence compatible GPL. Ce qui dans la pratique est pratiquement impossible, a moins de compiler toutes les bibliotheques et leurs dependances depuis le debut ...
Pour resumer, et pour faire simple, que designe le terme lié utilisé dans la licence GPL et LGPL ?
Journal Reflexion sur les licences libres
4
mai
2004
# Re: Reflexion sur les licences libres
Posté par Vincent Richard (site web personnel) . Évalué à 1.
[^] # Re: Reflexion sur les licences libres
Posté par Anonyme . Évalué à 1.
[^] # Re: Reflexion sur les licences libres
Posté par Loic Jaquemet . Évalué à 1.
Elle est en GPL/LGPL quelque part... bref, les deux y sont.
Et pour cause. La majorité des programmes ( même non libres ) l'utilise. Légalement.
Nan le 'linkage' pose pas de problème...
Tu as le droit d'utiliser un programme GPL dans un environnement non libre.
C'est juste que tu n'as pas le droit d'utiliser le code source dans un programme non libre. Les .h sont du code source.
Donc si tu veux utiliser une bibliothèque GPL, tu ne peux pas faire du non libre, parceque tu inclueras forcement du .h GPL.
Mais si c'est du LGPL, C'est bon.
Compris ?
J'ai pas tout faux ?
Transpose ça en java/python/peutimporte .... et c'est pareil.
[^] # Re: Reflexion sur les licences libres
Posté par Vincent Richard (site web personnel) . Évalué à 1.
La FAQ de la licence GPL :
http://www.gnu.org/licenses/gpl-faq.html(...)
[^] # Re: Reflexion sur les licences libres
Posté par Anonyme . Évalué à 1.
[^] # Re: Reflexion sur les licences libres
Posté par Anonyme . Évalué à 1.
J'avais lu dans un commentaire ici meme que le terme linkage etait plus vaste que la simple liaison dynamique/statique et pouvait etre transposé en terme de communication par socket (c'est le cas par exemple pour X, Gnome avec Corba, ...) Je pense que c'est faux car cela poserait evidement probleme entre un serveur HTTP sous GPL et IE par exemple.
Mais la, je m'ecarte un peu du probleme initial. Supposons donc que ce que tu dis est vrai, alors la GPL n'a plus aucun pouvoir car toute lib sous GPL pourra etre encapsulée dans une lib en LGPL et ainsi etre liée a des programmes sous licence non libre (mon premier cas). Est-ce que c'est effectivement le cas ?
[^] # Re: Reflexion sur les licences libres
Posté par Vincent Richard (site web personnel) . Évalué à 1.
Non, justement. A partir du moment où tu lies un programme B avec un programme A sous GPL, alors B doit forcément être sous GPL.
L'inverse est possible par contre : A sous LGPL et B en GPL.
Une solution : A sous GPL. B utilise A, B est sous GPL et B expose un service Web. C, sous n'importe quelle licence, utilise les services proposés par B via une connexion HTTP (par exemple). Je crois que c'est ce qu'ils appellent un cas "border-line" dans la FAQ, mais c'est faisable.
Autre exemple : A sous GPL. B peut-être sous n'importe quelle licence à condition de ne pas lier avec A : lancement par un fork par exemple. Ce n'est évidemment pas applicable si A est une bibliothèque.
[^] # Re: Reflexion sur les licences libres
Posté par Anonyme . Évalué à 1.
[^] # Re: Reflexion sur les licences libres
Posté par Anonyme . Évalué à 1.
http://developer.kde.org/policies/licensepolicy.html(...)
et le site de Trolltech pour la licence de Qt
[^] # Re: Reflexion sur les licences libres
Posté par Anonyme . Évalué à 1.
# Erreur de frappes
Posté par Anonyme . Évalué à 1.
# .
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
impossible !
B doit être sous GPL.
"La première sécurité est la liberté"
[^] # Re: .
Posté par Anonyme . Évalué à 1.
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses(...)
Ce terme compatibilité signifie bien qu'il est possible de lié un programme GPL a un programme LGPL ?
[^] # Re: .
Posté par Vincent Richard (site web personnel) . Évalué à 1.
Il faut voir ça comme des ensemble au sens mathématique du terme.
La GPL est un ensemble dont les éléments sont des permissions (clauses). La LGPL est un autre ensemble qui contient certains éléments de la GPL, plus d'autres.
Donc GPL inclu dans LGPL (sous-ensemble), mais pas l'inverse.
La compatibilité n'est donc que dans un sens.
Dans la licence LGPL :
Je pense que ce qu'ils appellent "compatibilité" c'est le fait de pouvoir revenir à une licence plus restrictive (ce qui est le cas du passage BSD, LGPL --> GPL mais surtout pas l'inverse).
Merci de me corriger (enfin mon texte, pas moi ! :-)) si je raconte des c*nneries.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.