Il n'est pas question d'hérédité avec la gpl puisqu'elle impose sa licence au code lié
La GPL impose aussi sa licence au code dérivé, donc là, on peut en effet parler d'hérédité. Contrairement à d'autres licences, qui n'imposent pas la licence du code dérivé.
Mais ça n'est juste pas ce dont on parlait ici. La GPL impose une licence au code réellement dérivé (et ça, c'est le principe du copyleft), et elle tente aussi d'imposer (tout du moins c'est l'interprétation de la FSF, parce que le texte de la GPL n'est pas du tout convainquant là-dessus) sa licence au code lié, en prétendant que la liaison fait du logiciel une œuvre dérivée des bibliothèques.
L'histoire des ambiguités de la FSF est probablement intéressante, mais je n'ai pas vraiment le temps ni l'envie d'aller mettre les mains dans le cambouis. Plusieurs projets sous GPL ont ressenti très tôt le besoin de clarifier la situation, en mettant leur code sous licence GPL-non-virale (typiquement, le kernel Linux, la libc proposée par gcc, la STL C++ de g++, etc). La publication de la LGPL a permi de clarifier les choses pour les bibliothèques sous LGPL, mais paradoxalement, ça n'a pas réellement clarifié les choses pour les bibliothèques sous GPL, puisque ça pourrait donner l'impression que la viralité prétendue de la GPL est établie, ce qui n'est pas le cas.
Après, personne ne prétend que l'interprétation de la FSF est totallement illégitime, puisque si je ne m'abuse, le modèle commercial de plusieurs entreprises a été ou est toujours basé dessus (la lib est disponible sous GPL et sous licence proprio payante, si tu fais du GPL tu peux utiliser la version GPL gratuitement, si tu fais du proprio il faut raquer). Mais disons que dans ce cas, c'est plutôt la menace de procès qui est dissuasive (payer la licence proprio est probablement moins cher que de s'engager dans un bras de fer judiciaire sur un des points les plus compliqués de la licence GPL); ça ne prouve pas réellement que la FSF est dans son droit là-dessus
[^] # Re: Sémantique toxique
Posté par arnaudus . En réponse au journal SSPL: All your service are belong to us. Évalué à 3. Dernière modification le 24 octobre 2018 à 11:09.
La GPL impose aussi sa licence au code dérivé, donc là, on peut en effet parler d'hérédité. Contrairement à d'autres licences, qui n'imposent pas la licence du code dérivé.
Mais ça n'est juste pas ce dont on parlait ici. La GPL impose une licence au code réellement dérivé (et ça, c'est le principe du copyleft), et elle tente aussi d'imposer (tout du moins c'est l'interprétation de la FSF, parce que le texte de la GPL n'est pas du tout convainquant là-dessus) sa licence au code lié, en prétendant que la liaison fait du logiciel une œuvre dérivée des bibliothèques.
L'histoire des ambiguités de la FSF est probablement intéressante, mais je n'ai pas vraiment le temps ni l'envie d'aller mettre les mains dans le cambouis. Plusieurs projets sous GPL ont ressenti très tôt le besoin de clarifier la situation, en mettant leur code sous licence GPL-non-virale (typiquement, le kernel Linux, la libc proposée par gcc, la STL C++ de g++, etc). La publication de la LGPL a permi de clarifier les choses pour les bibliothèques sous LGPL, mais paradoxalement, ça n'a pas réellement clarifié les choses pour les bibliothèques sous GPL, puisque ça pourrait donner l'impression que la viralité prétendue de la GPL est établie, ce qui n'est pas le cas.
Après, personne ne prétend que l'interprétation de la FSF est totallement illégitime, puisque si je ne m'abuse, le modèle commercial de plusieurs entreprises a été ou est toujours basé dessus (la lib est disponible sous GPL et sous licence proprio payante, si tu fais du GPL tu peux utiliser la version GPL gratuitement, si tu fais du proprio il faut raquer). Mais disons que dans ce cas, c'est plutôt la menace de procès qui est dissuasive (payer la licence proprio est probablement moins cher que de s'engager dans un bras de fer judiciaire sur un des points les plus compliqués de la licence GPL); ça ne prouve pas réellement que la FSF est dans son droit là-dessus