Licence GPL et GPL Classpath Exception : Qu'est ce que cela signifie ?
Les logiciels open source ont toujours été la preuve que la collaboration et le partage créent des logiciels puissants et fiables. La General Public Licence (GPL), l'une des licences OSS les plus connues, a joué un rôle déterminant dans la promotion de cette idée. Au cœur de la licence GPL se trouve un principe connu sous le nom de copyleft, qui garantit que tout travail dérivé d'un logiciel sous licence GPL reste libre et open source. Cependant, ce principe, bien que bénéfique dans de nombreux contextes, peut parfois être trop restrictif, en particulier lorsqu'il s'agit de bibliothèques. C'est là qu'intervient la GPL Classpath Exception, une clause essentielle qui offre plus de flexibilité pour intégrer les bibliothèques avec du code propriétaire ou sous une licence différente.
Comprendre la Licence GPL
Avant d'aborder la GPL Classpath Exception, il est important de comprendre la Licence GPL elle-même.
Formulée par la Free Software Foundation (FSF), la GPL est la pierre angulaire des licences copyleft. Selon la GPL, et en particulier sa dernière version, la GPL version 3, si vous modifiez et distribuez un logiciel sous Licence GPL, ces modifications doivent également être placées sous Licence GPL. L'objectif premier est de s'assurer que le logiciel reste libre, non pas en termes de coût mais plutôt libre d'accès. Essentiellement, la GPL propage l'idée que si vous bénéficiez du travail de la communauté, vous devez lui rendre la pareille. Pour mieux comprendre le fonctionnement de la GPL, examinons comment elle fonctionne dans le contexte d'une entreprise qui développe et distribue des logiciels propriétaires et comment la GPL interagit avec ce modèle.
Source: WhiteSource 2021
Scénario 1 : Utilisation du code GPL en l'état
Si une entreprise utilise un logiciel sous Licence GPL "tel quel" et le distribue (même s'il fait partie de son logiciel propriétaire), le logiciel sous Licence GPL doit rester sous GPL. L'entreprise doit fournir le code source (ou un avenant pour fournir le code source) du composant sous GPL et s'assurer que les destinataires sont conscients de leurs droits en vertu de la GPL. L'entreprise ne peut pas revendiquer de droits de propriété sur la partie sous GPL ou lui imposer des restrictions supplémentaires.
Scénario 2 : Utilisation interne d'un code GPL modifié
Si une entreprise modifie un logiciel sous Licence GPL mais ne l'utilise qu'en interne sans le distribuer (par exemple, par le biais d'outils internes, de serveurs, etc...) il ne sera pas nécessaire de publier les modifications. Les obligations imposées par la GPL découlent principalement de la distribution.
Scénario 3: La diffusion du code GPL modifié
Si l'entreprise modifie un logiciel sous licence GPL et distribue ensuite la version modifiée, elle doit également publier les modifications sous Licence GPL. L'entreprise ne peut pas garder la propriété des modifications.
En outre, si le code GPL est combiné avec le code propriétaire de l'entreprise d'une manière qui crée une œuvre dérivée, l'ensemble de l'œuvre combinée pourrait devoir être publiée sous GPL. C'est ici que la nature "virale" de la GPL est souvent évoquée. Ainsi, l'insertion de quelques lignes de code sous Licence GPL dans un projet propriétaire d'un million de lignes peut, en principe, transformer l'ensemble de la base de code en Licence GPL.
La question se pose naturellement de savoir ce qui constitue un "avenant". Par définition, le terme "avenant" englobe tout changement ou adaptation, qu'il s'agisse de rectifier un bug mineur, d'intégrer de nouvelles fonctionnalités ou de combiner l'œuvre originale avec un autre logiciel. Dans le contexte de la GPL, il n'existe pas de définition précise du terme "avenant". Elle aborde plutôt le concept de manière plus large, en se concentrant sur l'idée d'une "œuvre dérivée" ou d'un "travail dérivé". Une œuvre dérivée consiste à modifier ou à combiner un logiciel sous Licence GPL pour produire une œuvre basée sur l'original.
La partie délicate consiste à déterminer la limite de ce qui constitue une œuvre dérivée, en particulier lorsque le code GPL est combiné à d'autres codes. Le simple fait d'établir un lien avec un logiciel sous licence GPL crée-t-il une œuvre dérivée ? Que se passe-t-il si vous incluez une bibliothèque sous Licence GPL dans votre logiciel mais que vous ne modifiez pas le code de la bibliothèque ? Ces questions ont alimenté de nombreux débats. En réponse, la GPL avec Classpath Exception et la LGPL ont été créées pour clarifier ces frontières, principalement pour les bibliothèques logicielles.
Avec cette compréhension de la GPL, nous allons nous pencher sur une exception spécifique qui ajoute plus de flexibilité - la GPL Classpath Exception.
La GPL Classpath Exception expliquée
Qu'est-ce que la GPL Classpath Exception ?
La GPL Classpath Exception est un addendum à la GPL, spécialement conçu pour les bibliothèques. Cette exception permet à la bibliothèque d'être intégrée dans n'importe quel logiciel sans que celui-ci n'ait à adopter la licence GPL. Il faut pour cela que la bibliothèque soit invoquée par l'intermédiaire d'un "classpath" ou d'un mécanisme similaire, ce qui garantit que la bibliothèque et le code propriétaire restent des entités distinctes.
Le terme "classpath" désigne à l'origine un paramètre du langage de programmation Java qui spécifie l'emplacement des classes et des paquets définis par l'utilisateur. Toutefois, dans le contexte de cette exception, il a une connotation plus large et englobe les mécanismes d'autres langages de programmation qui permettent la séparation et l'invocation de bibliothèques externes.
GPL Classpath : Pourquoi une exception ?
Les bibliothèques, de par leur conception, sont des outils destinés à être utilisés par un large éventail de logiciels. Leur objectif premier est d'offrir des fonctionnalités qui peuvent être exploitées par diverses applications. Lorsqu'une bibliothèque est sous Licence GPL, sa licence stricte peut décourager son adoption, car tous les développeurs ou entreprises ne souhaitent pas ouvrir l'intégralité de leur application sous Licence GPL.
La GPL Classpath Exception comble cette lacune. Elle permet aux bibliothèques de rester libres et ouvertes (et donc de bénéficier des contributions de la communauté) tout en restant attrayantes pour un plus grand nombre de projets logiciels qui auraient pu les éviter pour des raisons de licence.
Implications et avantages
Pour les développeurs de logiciels, il est essentiel de comprendre l'exception du chemin de classe de la GPL. L'exception du chemin de classe de la GPL offre plusieurs avantages notables :
1. Meilleure adoption de la bibliothèque : les bibliothèques sous licence avec le Classpath Exception de la GPL sont plus attrayantes pour un large éventail de développeurs, y compris ceux qui travaillent sur des logiciels propriétaires, car elles n'imposent pas les exigences strictes de la GPL en matière de redistribution.
2. Maintien des libertés logicielles : même avec le Classpath Exception, la bibliothèque elle-même reste sous Licence GPL. Cela signifie que toute modification ou amélioration de la bibliothèque doit être libre, préservant ainsi l'essence de la liberté logicielle pour la bibliothèque.
3. Flexibilité pour les développeurs : les développeurs peuvent choisir d'utiliser la bibliothèque sous Licence GPL stricte (sans le Classpath Exception) ou avec le Classpath Exception, en fonction des besoins de leur projet.
4. Protection des intérêts propriétaires : les entreprises peuvent intégrer de puissantes bibliothèques GPL dans leurs solutions propriétaires sans mettre en péril leur propriété intellectuelle ou leur modèle commercial.
Mises en garde et considérations
Bien que la Classpath Exception GPL offre une plus grande flexibilité, il est essentiel de comprendre ses limites :
- Modifications : La Classpath Exception ne s'applique pas aux modifications de la bibliothèque elle-même. Toute modification apportée directement à la bibliothèque doit toujours être placée sous Licence GPL.
- Des entités distinctes : La bibliothèque et le logiciel qui l'utilise ne doivent pas être étroitement intégrés au point où ils deviennent un seul et même logiciel. Ils doivent rester des entités distinctes. Cette distinction est essentielle pour s'assurer que le logiciel utilisant la bibliothèque ne soit pas, par inadvertance, soumis à la GPL. Voici quelques éléments à prendre en compte pour que cette distinction soit claire :
- Etablir des liens : Que vous utilisiez la liaison dynamique ou statique, l'essentiel est de veiller à ce que la bibliothèque et le logiciel restent séparés. La Classpath Exception n'impose pas d'exigences spécifiques en matière de liaison, mais il est généralement plus sûr d'utiliser la liaison dynamique. Avec la liaison dynamique, le logiciel appelle les fonctions de la bibliothèque au moment de l'exécution sans intégrer la bibliothèque directement dans le programme.
- Éviter l'intégration : N'intégrez pas de parties de la bibliothèque dans le logiciel propriétaire. Il est préférable d'utiliser la bibliothèque comme elle est censée l'être : en tant que composant autonome. - Due Diligence : Les développeurs doivent rester vigilants et s'assurer qu'ils comprennent les licences de tous les logiciels qu'ils utilisent. Toutes les bibliothèques GPL ne bénéficient pas de la Classpath Exception. Les développeurs doivent s'assurer que la bibliothèque qu'ils ont l'intention d'utiliser comporte cette exception avant de l'intégrer dans un logiciel non GPL.
La GPL Classpath Exception en pratique
Lorsque vous intégrez un composant GPL avec un Classpath Exception dans votre logiciel, vous pouvez lier ou utiliser la bibliothèque comme vous le feriez avec n'importe quelle autre. La beauté du Classpath Exception réside dans sa flexibilité : le simple fait d'utiliser ou de lier la bibliothèque n'oblige pas votre logiciel à hériter de la Licence GPL. Néanmoins, il est essentiel de reconnaître une distinction cruciale : si vous modifiez la bibliothèque elle-même et choisissez de distribuer ces modifications, vous êtes tenu de vous conformer aux stipulations de la GPL pour ces modifications.
En approfondissant les nuances des dérivés en aval, la GPL Classpath Exception n'impose pas à ces dérivés ou aux logiciels liés de le maintenir. La prérogative de fournir cette exception appartient uniquement à l'auteur de la bibliothèque d'origine. Par conséquent, bien que les modifications et les distributions de la bibliothèque doivent respecter les directives de la GPL, le Classpath Exception garantit que tout logiciel lié à la bibliothèque reste à l'abri des mandats de la GPL.
En d'autres termes, si vous utilisez la bibliothèque avec le Classpath Exception dans votre logiciel, celui-ci est à l'abri des règles strictes de la GPL. Mais si vous modifiez la bibliothèque elle-même, ces modifications doivent respecter la GPL.
En approfondissant les nuances des dérivés en aval, la GPL Classpath Exception n'impose pas à ces dérivés ou aux logiciels liés de la maintenir. Lorsque vous intégrez un composant GPL avec une Classpath Exception dans un logiciel, vous pouvez librement lier ou utiliser la bibliothèque. Cependant, si l'utilisation ou la liaison n'oblige pas à placer votre logiciel sous Licence GPL, la modification et la distribution de la bibliothèque imposent le respect de la GPL pour ces modifications.
La prérogative de fournir cette exception appartient uniquement à l'auteur de la bibliothèque d'origine. Par conséquent, alors que les modifications et les distributions de la bibliothèque doivent respecter les directives de la GPL, le Classpath Exception garantit que tout logiciel lié à la bibliothèque reste à l'abri des mandats de la GPL.
En d'autres termes, si vous utilisez la bibliothèque avec le Classpath Exception dans votre logiciel, celui-ci est à l'abri des règles strictes de la GPL. Toutefois, si vous modifiez la bibliothèque, ces modifications doivent être conformes à la GPL. N'oubliez pas que cette exception ne s'applique pas à toutes les bibliothèques sous GPL ; vérifiez donc toujours les termes de la licence.
Comment le GPL Classpath Exception diffère de la "Lesser General Public License" de GNU (LGPL)
La compréhension de la GPL avec la Classpath Exception devient plus claire lorsque nous la juxtaposons à une autre licence de logiciel répandue, la GNU Lesser General Public License (LGPL). La LGPL est une autre création de la Free Software Foundation visant à promouvoir la liberté des logiciels. Contrairement à son homologue, la GPL, la LGPL est plus indulgente lorsqu'il s'agit de lier des logiciels à des bibliothèques. Elle est conçue pour garantir que même les logiciels propriétaires puissent bénéficier des avantages des bibliothèques open-source tout en préservant les libertés associées à ces bibliothèques. Voyons maintenant en quoi elle diffère de la GPL avec la Classpath Exception.
La LGPL et l'Etablissement de Liens
Liaison dynamique : Lorsqu'une application logicielle est liée à une bibliothèque LGPL de manière dynamique, cela signifie essentiellement que le logiciel et la bibliothèque restent séparés, même pendant l'exécution. Ils se connectent "à la volée" lorsque l'utilisateur exécute le logiciel. Dans ce cas, le logiciel n'hérite pas des règles strictes de la GPL, mais il y a tout de même des conditions :
- Le logiciel doit permettre aux utilisateurs de remplacer la bibliothèque LGPL par une version modifiée.
- Si le logiciel est distribué, le code source ou le code objet de la bibliothèque LGPL liée doit être accessible aux utilisateurs, afin de préserver leur liberté de modifier ou de mettre à niveau cette bibliothèque.
Liaison statique : dans ce cas, la bibliothèque est incorporée directement dans le binaire du logiciel lors de la compilation. Elle devient une entité unique, ce qui rend difficile son remplacement ou sa modification.
Pour garantir la liberté de l'utilisateur dans ce scénario, la LGPL stipule ce qui suit :
- Le logiciel doit fournir aux utilisateurs les moyens de modifier ou de remplacer le composant LGPL, même si cela nécessite un nouveau lien.
Classpath vs LGPL
À la base, la Classpath Exception offre une posture plus simple que la LGPL. Elle permet aux logiciels d'utiliser une bibliothèque GPL sans absorber les obligations de la GPL, à condition que le logiciel et la bibliothèque restent séparés. Cependant, si l'on modifie la bibliothèque GPL, les changements doivent être conformes à la GPL. L'objectif principal est de faire en sorte que la bibliothèque et le logiciel restent des unités distinctes, quelle que soit leur méthode de liaison.
En résumé, alors que la LGPL se concentre sur la garantie que les utilisateurs peuvent accéder au code de la bibliothèque et le modifier (avec des conditions adaptées à la méthode de liaison), l'exception Classpath fournit une approche directe. Elle souligne l'importance de maintenir une frontière entre le logiciel et la bibliothèque, sans restrictions sur les méthodes de liaison.
Les deux alternatives offrent une plus grande malléabilité par rapport à la GPL standard. Néanmoins, leurs termes et leurs points essentiels divergent : la LGPL met l'accent sur l'accès des utilisateurs et les droits de modification des bibliothèques, tandis que le Classpath Exception accentue la division entre logiciel et bibliothèque.
Conclusion
En conclusion, la GPL avec le Classpath Exception met en évidence la capacité d'adaptation de la communauté open source et sa compréhension aiguë des divers besoins en matière de logiciels. Si la GPL est une licence puissante qui a révolutionné le paysage du logiciel, le Classpath Exception garantit que les avantages des bibliothèques GPL ne sont pas limités mais sont accessibles à un public plus large. Pour les développeurs et les organisations, comprendre ces nuances permet non seulement de bénéficier de ressources partagées, mais aussi de contribuer de manière responsable à l'écosystème des logiciels libres.
Comme pour tout problème de licence, il est toujours bon pour les développeurs de consulter un expert juridique en cas de doute, afin de s'assurer qu'ils respectent les termes de la licence tout en bénéficiant des connaissances partagées de la communauté open source.
Note sur l'interprétation : Bien que cet article vise à simplifier et à expliquer les nuances de la GPL avec Classpath Exception, il est essentiel de noter que les licences de logiciels, en particulier dans le domaine de l'open-source, peuvent être complexes. Les interprétations peuvent varier en fonction des implémentations logicielles spécifiques, des juridictions et de la complexités de chaque projet. Cet article offre une compréhension de base, mais il faut toujours se référer aux textes originaux des licences et demander un avis juridique pour des applications ou des scénarios spécifiques.
Sources:
https://www.mend.io/blog/top-9-gpl-with-the-classpath-exception-questions-answered/ https://www.gnu.org/software/classpath/faq/faq.html https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL https://www.clendons.co.nz/resources/articles-and-publications/technology/using-gpl-code-your-software-essentials/ https://openjdk.org/legal/gplv2+ce.html https://www.mend.io/blog/top-10-gpl-license-questions-answered/#8_Can_you_mix_the_GPL_license_with_other_licenses_or_modify_and_distribute_GPL-licensed_software_under_a_different_license https://www.techtarget.com/searchdatacenter/definition/GNU-General-Public-License-GNU-GPL-or-simply-GPL https://torquemag.io/2016/11/explaining-and-understanding-the-gnu-general-public-license-gpl/ https://fossa.com/blog/open-source-software-licenses-101-lgpl-license/
Recommandés pour vous