La LGPL et Java

Cet article a été écrit en novembre 2004, quand la LGPLv2.1 était la version la plus récente 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 exige que toutes les œuvres dérivées soient couvertes par la GPL dans leur intégralité, un effet qui peut être décrit comme « héréditaire ». Donc, si une application est liée à une bibliothèque sous GPL, l'application doit être aussi sous GPL. En revanche, des bibliothèques sous licence publique générale GNU amoindrie (LGPL) peuvent être liées à des applications privatrices.¹

En juillet 2003, Slashdot a publié un article déclarant que, selon mes affirmations, la LGPL ne fonctionnait pas comme prévu dans le cas de Java. Cet article était basé sur une mauvaise interprétation de la réponse à une question envoyée à licensing@gnu.org, et plusieurs tentatives que j'ai faites pour clarifier le problème n'ont pas abouti. J'ai reçu depuis de nombreuses questions sur cet article, aussi bien sur licensing@gnu.org qu'à mon adresse personnelle.

La position de la FSF n'a jamais varié : 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 la même licence. Les seules obligations auxquelles elles doivent satisfaire sont celles de la section 6 de la LGPL : autoriser la liaison de l'application avec de nouvelles versions de la bibliothèque, et permettre la rétroingénierie pour la déboguer.

Typiquement, chaque bibliothèque Java utilisée par une application est distribuée sous forme d'un 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'application est 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 s'y conformer. La licence de votre application doit autoriser les utilisateurs à modifier la bibliothèque et à faire de la rétroingénierie sur 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 application. Bien sûr, certains changements que peuvent faire les utilisateurs pourraient casser l'interface, rendant la bibliothèque inutilisable avec votre application. Vous n'avez pas à vous en inquiéter (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 obtiennent la bibliothèque par leurs propres moyens, vous n'avez pas besoin d'en fournir le code source.

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 clause spéciale 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.

Note de traduction

Autre traduction de proprietary : propriétaire. ↑