La LGPL et Java
par David Turner
Cet article a été écrit en novembre 2004, quand la LGPLv2.1 était la version la plus à jour de la licence. Depuis, la LGPLv3 a été publiée. Les points principaux de cet article demeurent vrais avec la LGPLv3, mais certains détails, comme les numéros de section, ont changé.
La position de la FSF a toujours été que la liaison dynamique d'applications à des bibliothèques crée une œuvre unique dérivée à la fois du code de la bibliothèque et de celui de l'application. La GPL nécessite que toutes les œuvres dérivées soient sous licence GPL, un effet qui peut être décrit comme « héréditaire ». Donc, si une application est liée à une bibliothèque sous licence GPL, l'application doit être aussi sous licence GPL. En revanche, des bibliothèques sous licence GNU Lesser General Public License (LGPL) peuvent être liées à des applications propriétaires.
En juillet 2003, Slashdot a publié une histoire déclarant que j'avais affirmé que la LGPL ne fonctionnait pas comme prévu dans le cas de Java. Cette histoire était basée sur une mauvaise compréhension d'une réponse à une question envoyée à licensing@gnu.org, et plusieurs tentatives pour clarifier le problème dans l'histoire de Slashdot n'ont pas abouti. J'ai reçu de nombreuses questions sur cette histoire depuis, à la fois sur licensing@gnu.org et sur mon adresse personnelle.
La position de la FSF est demeurée la même depuis : la LGPL fonctionne comme prévu avec tous les langages de programmation connus, y compris Java. Les applications qui sont liées à des bibliothèques LGPL n'ont pas besoin d'être publiées sous licence LGPL. 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.
L'arrangement typique pour Java est que chaque bibliothèque qu'une application utilise est distribuée sous forme de fichier JAR séparé (archive Java). Les applications utilisent la fonctionnalité « import » de Java pour accéder aux classes de ces bibliothèques. quand l'application est compilée, les signatures de fonction sont vérifiées par rapport à la bibliothèque, créant un lien. L'applicationest alors généralement une œuvre dérivée de la bibliothèque. Donc, le détenteur du copyright de la bibliothèque doit autoriser la distribution de l'œuvre. La LGPL permet cette distribution.
Si vous distribuez une application Java qui importe des bibliothèques sous LGPL, il est facile de se conformer à la LGPL. La licence de votre application doit autoriser les utilisateurs à modifier la bibliothèque et à faire de la rétro-ingénierie de votre code pour déboguer ces modifications. Cela ne signifie pas que vous devez fournir le code source ou des détails sur le fonctionnement interne de votre appplication. Bien sûr, certains changements que peuvent faire les utilisateurs peuvent casser l'interface, rendant la bibliothèque inutilisable pour fonctionner avec votre application. Vous n'avez pas à vous inquiéter de cela (les personnes qui modifient la bibliothèque sont responsables de son fonctionnement).
Quand vous distribuez la bibliothèque avec votre application (ou séparément), vous devez inclure le code source de la bibliothèque. Mais si votre application nécessite que les utilisateurs doivent obtenir la bibliothèque par leurs propres moyens, vous n'avez pas besoin de fournir le code source de la bibliothèque.
La seule différence entre Java et C du point de vue de la LGPL est que Java est un langage orienté objet et gérant l'héritage. La LGPL ne contient pas de clauses spéciales pour l'héritage, car aucune n'est nécessaire. L'héritage crée une œuvre dérivée de la même manière que la liaison traditionnelle, et la LGPL permet ce type d'œuvre dérivée de la même manière qu'elle permet les appels de fonction ordinaires.