Je réponds par la même occasion à trois_1 qui pose une question similaire en dessous.
Je pense que c'est principalement du à une mauvaise compréhension de la LGPL.
Les éditeurs de logiciels proprio sont très frileux (du moins leurs avocats) quant aux impacts que peut avoir la licence d'une bibliothèque utilisée sur l'ouverture ou non de leur code. Et sur l'impact que cela peut éventuellement avoir sur le code de leurs clients.
On va dire qu'ils préfèrent prévenir que de se taper des complications.
La LGPL en fait les frais à cause de l'ambiguité qu'il y a eu à une certaine époque sur la notion de "lien" qui est plutôt claire en C ou C++ par exemple mais pas en Java.
Même si il y a eu des précisions depuis ça reste dans l'air.
Les applications ne doivent suivre que les conditions de la section 6 de la LGPL : autoriser de nouvelles versions de la bibliothèque à être liées avec l'application et de permettre la rétro-ingénierie pour déboguer cela.
Je ne m'étonne pas que les éditeurs de proprios ne soient pas très chauds pour autoriser la rétro-ingénierie de leurs produits.
La licence Apache (au hasard) n'a pas ce genre de contraintes ou d'ambiguités.
J'espère que ça vous éclaire un peu sur mon contexte :-)
[^] # Re: Sauf que ...
Posté par Jérôme . En réponse à la dépêche Qt 4.5 sera sous licence LGPL 2.1. Évalué à 3.
Je pense que c'est principalement du à une mauvaise compréhension de la LGPL.
Les éditeurs de logiciels proprio sont très frileux (du moins leurs avocats) quant aux impacts que peut avoir la licence d'une bibliothèque utilisée sur l'ouverture ou non de leur code. Et sur l'impact que cela peut éventuellement avoir sur le code de leurs clients.
On va dire qu'ils préfèrent prévenir que de se taper des complications.
La LGPL en fait les frais à cause de l'ambiguité qu'il y a eu à une certaine époque sur la notion de "lien" qui est plutôt claire en C ou C++ par exemple mais pas en Java.
Même si il y a eu des précisions depuis ça reste dans l'air.
De plus je viens de jeter un oeil à http://www.gnu.org/licenses/lgpl-java.fr.html pour avoir plus d'infos.
Et quand je lis :
Les applications ne doivent suivre que les conditions de la section 6 de la LGPL : autoriser de nouvelles versions de la bibliothèque à être liées avec l'application et de permettre la rétro-ingénierie pour déboguer cela.
Je ne m'étonne pas que les éditeurs de proprios ne soient pas très chauds pour autoriser la rétro-ingénierie de leurs produits.
La licence Apache (au hasard) n'a pas ce genre de contraintes ou d'ambiguités.
J'espère que ça vous éclaire un peu sur mon contexte :-)