Licence publique générale

Qu'est-ce que la GNU General Public License (GPL) ?

La GNU General Public License, souvent désignée par « GPL », est une licence open source de référence. Elle impose que chaque utilisation, modification ou distribution du code s'accompagne du maintien d'un code source ouvert et d'un partage selon les mêmes termes de licence. La GPL figure parmi les licences les plus influentes de l'univers open source.

Une « licence open source » définit les modalités par lesquelles un auteur autorise l’utilisation et la modification de son code—à l’image du partage d’une recette, avec possibilité d’améliorations. La GPL oblige à ce que toute version améliorée de la « recette » soit également rendue publique et partagée selon des règles identiques. Cette exigence de réciprocité garantit que la communauté bénéficie continuellement des évolutions apportées.

Quels sont les principes fondamentaux de la GPL ?

La GPL repose sur le principe du « copyleft », assimilé à un « copyright réciproque » : lorsque vous utilisez ou modifiez du code ouvert, toute distribution de vos modifications doit être ouverte, et les mentions de copyright et de licence d’origine doivent être conservées.

Principes essentiels :

• Divulgation du code source : la distribution de fichiers exécutables doit s’accompagner de l’accès au code source correspondant.
• Continuité de la licence : les œuvres dérivées doivent rester sous GPL.
• Conservation des mentions : les déclarations de copyright et de licence originales doivent être préservées.
• Absence de garantie : le logiciel est fourni « en l’état », sans aucune garantie des auteurs.
• Dispositions sur les brevets (v3) : la version 3 de la GPL introduit des mesures renforcées de protection des brevets.

Le noyau Linux utilise la GPL-2.0 depuis de nombreuses années (2025), ce qui en fait l’un des exemples les plus emblématiques de l’adoption de la GPL.

Quel est l’impact de la GPL sur le développement Web3 ?

La GPL conditionne la possibilité de distribuer des logiciels intégrant du code open source en version propriétaire, ou impose l’ouverture du code source lors de la distribution du projet. Dans le Web3, les exigences de la GPL peuvent concerner les clients de nœud, les portefeuilles, les frontends et les smart contracts.

Par exemple, si le frontend de votre dApp intègre un composant sous licence GPL et que vous distribuez une version exécutable aux utilisateurs, vous devrez probablement publier le code source de votre frontend et conserver toutes les mentions d’origine. Cette transparence favorise la collaboration, mais peut limiter les modèles commerciaux propriétaires.

On-chain, l’open source renforce l’auditabilité et la sécurité. De nombreuses équipes publient leur code critique pour instaurer la confiance, tout en évaluant la compatibilité des licences avec leur stratégie produit.

Comment la GPL s’applique-t-elle aux smart contracts ?

Les smart contracts sont généralement rédigés en Solidity, avec une indication de licence en tête de fichier via le SPDX-License-Identifier (ex. : « SPDX-License-Identifier: GPL-3.0-or-later »). Les exigences de licence réciproque de la GPL soulèvent plusieurs points pour les smart contracts :

Premièrement, la distribution : la compilation et le déploiement d’un contrat on-chain sont généralement considérés comme une distribution publique. Si votre contrat inclut ou modifie du code GPL, le déploiement public peut exiger l’ouverture de vos modifications. La qualification de distribution dépend du contexte—à évaluer dès la conception.

Deuxièmement, liaison et dérivation : l’héritage de contrat ou l’appel à des bibliothèques sont souvent assimilés à la création d’œuvres dérivées. Si vous héritez d’un contrat sous GPL, votre contrat distribué doit respecter la même licence.

Troisièmement, pratique courante : de nombreuses équipes optent pour des licences plus permissives, comme MIT ou Apache, pour les contrats principaux afin de limiter les obligations en aval. Si vous utilisez la GPL, fournissez le code source complet, les mentions de copyright et les instructions de build dans le dépôt pour faciliter l’auditabilité et la réutilisation.

En quoi la GPL diffère-t-elle des licences MIT et Apache ?

La différence majeure entre GPL, MIT et Apache réside dans le degré de réciprocité exigé.

• MIT : à l’image du partage d’une recette avec attribution—très permissive, n’impose pas l’utilisation de la même licence pour les dérivés. Adaptée aux produits propriétaires ou à la double licence.
• Apache-2.0 : similaire à MIT mais inclut des garanties explicites sur les brevets et des clauses de non-responsabilité—répondant aux besoins des entreprises.
• GPL : impose la licence réciproque, idéale pour les projets visant le partage communautaire continu des améliorations ; plus contraignante pour la distribution propriétaire.

En résumé : la GPL favorise une collaboration ouverte et le partage obligatoire des évolutions ; MIT ou Apache offrent une flexibilité accrue entre open source et commercialisation propriétaire.

Comment se conformer à la GPL dans un projet ?

Étape 1 : placer le fichier LICENSE (texte intégral de la GPL) à la racine du dépôt et indiquer les détails de licence dans le README.

Étape 2 : ajouter un en-tête SPDX-License-Identifier (ex. : « SPDX-License-Identifier: GPL-3.0-or-later ») en haut de chaque fichier source pour permettre l’identification de la licence par les chaînes d’outils.

Étape 3 : conserver les mentions de copyright et de licence des auteurs initiaux ; signaler clairement vos modifications avec la date, l’auteur et un résumé.

Étape 4 : fournir un moyen d’obtenir le code source pour tout exécutable distribué—par exemple, publier le code source, les scripts de build et la documentation des dépendances pour garantir la reproductibilité.

Étape 5 : vérifier la compatibilité des licences des dépendances tierces ; le cas échéant, privilégier la LGPL (plus adaptée aux bibliothèques).

Étape 6 : réaliser un audit de conformité avant la mise en production ; solliciter l’avis d’un juriste en cas d’utilisation commerciale pour limiter les risques.

Quelles sont les différences entre les versions de la GPL ?

Les principales versions sont v2 et v3 :

• v2 (ex. : noyau Linux) : version la plus ancienne et la plus répandue ; ne traite pas des problématiques modernes liées aux brevets ou au verrouillage matériel.
• v3 : renforce les garanties sur les brevets, ajoute des clauses anti-Tivoization (empêchant le blocage matériel des versions modifiées) et des dispositions relatives à la gestion des droits numériques—mieux adaptée aux modes de distribution actuels.

« Or later » vs « Only » : choisir « GPL-3.0-or-later » autorise l’adoption des versions futures pour plus de flexibilité ; « only » fige la version pour une meilleure maîtrise de la compatibilité.

Par ailleurs, la LGPL vise les bibliothèques (permettant la liaison sous des conditions plus souples), tandis que l’AGPL étend les obligations open source aux logiciels accessibles via le réseau—les services backend Web3 et les interactions frontend doivent surveiller attentivement les déclencheurs AGPL.

La GPL peut-elle être utilisée à des fins commerciales ?

Oui—la GPL autorise l’usage commercial. Toutefois, lors de la distribution d’œuvres dérivées intégrant du code GPL, il faut ouvrir le code source et conserver toutes les mentions. Les stratégies courantes en entreprise incluent :

• Double licence : publication du code principal sous GPL et offre d’une version sous licence commerciale aux clients professionnels.
• Modèle de service : monétisation via l’hébergement, le support, l’audit ou l’intégration, tout en respectant les exigences open source (attention aux obligations spécifiques de l’AGPL pour les usages réseau).
• Séparation des composants : dissociation des éléments à partager du cœur métier propriétaire ; utilisation de la LGPL ou d’alternatives propriétaires pour les bibliothèques afin de limiter les obligations de réciprocité.

Quels sont les risques et idées reçues courants sur la GPL ?

Parmi les idées reçues :

• « La GPL ne peut pas être utilisée commercialement »—Faux. L’usage commercial est permis, mais la distribution de dérivés implique des obligations open source.
• « Pas de conformité si pas de distribution »—Incomplet. Le déploiement peut être assimilé à une distribution selon le contexte ; le déploiement on-chain ou l’accès réseau peuvent constituer une publication publique.
• « La GPL se mélange librement avec MIT/Apache »—Attention. Les relations de dérivation peuvent imposer la GPL sur l’ensemble ; évitez de combiner des licences incompatibles.
• « Un usage mineur lève les obligations »—La façon d’intégrer le code (héritage, liaison statique/dynamique) peut tout de même générer une œuvre dérivée ; un audit de conformité s’impose.

Les risques portent sur les litiges de violation et de conformité, susceptibles d’impacter le financement, les listings ou les partenariats. Les projets traitant des fonds ou de la sécurité des contrats doivent anticiper la conception de licence et l’audit du code source.

Recommandations et synthèse pour le choix de la GPL

Si vous visez la collaboration communautaire, le retour des améliorations et l’auditabilité, la GPL est un choix robuste. Pour davantage de liberté en matière de modèles propriétaires ou de double licence, MIT ou Apache offrent plus de souplesse. Assurez une gestion cohérente et traçable des licences pour les smart contracts et frontends—intégrez les fichiers LICENSE et les en-têtes SPDX dans les dépôts, et standardisez les modalités de distribution du code source. Soyez attentif aux différences de versions, à la compatibilité des dépendances et à la qualification de votre cas (distribution ou dérivation). Effectuez systématiquement des contrôles de conformité et sollicitez un avis juridique avant toute commercialisation. Avec une stratégie de licence claire, vous favorisez une collaboration fiable et la conformité réglementaire dans l’écosystème Web3.

FAQ

Puis-je utiliser du code sous GPL directement dans des projets commerciaux ?

Oui—mais il vous faudra également publier le code dérivé en open source. Le caractère « viral » de la GPL implique que tout développement basé sur du code GPL et commercialisé doit être publié sous les mêmes termes de licence. Cette exigence est incompatible avec les modèles propriétaires. Si votre activité repose sur la confidentialité du code, privilégiez les bibliothèques sous licence Apache ou MIT.

Quels sont les risques juridiques si je référence un smart contract GPL dans mon projet Web3 ?

Le principal risque est une action en justice des auteurs originaux pour violation du droit d’auteur. Bien que le droit des smart contracts soit en évolution, de nombreux tribunaux ont reconnu l’applicabilité des obligations de la GPL—leur violation peut entraîner des dommages-intérêts. En cas de recherche de financement ou d’acquisition, les investisseurs peuvent être réticents face aux risques perçus de la GPL. Consultez un juriste dès le début ou privilégiez des licences moins restrictives pour limiter votre exposition.

Pourquoi dit-on que la GPL « contamine » un projet ?

C’est ainsi que l’on décrit couramment l’effet « viral » de la GPL. Dès que du code GPL est intégré—même indirectement—l’ensemble du projet peut être soumis aux conditions de la GPL (dans certains cas). Pour les développeurs souhaitant garder leur code propriétaire, cette « ouverture forcée » est perçue comme une « contamination ». Il s’agit d’un choix délibéré visant à protéger les principes du logiciel libre.

Si mon projet utilise uniquement l’API d’une bibliothèque GPL, dois-je publier mon projet en open source ?

Cela dépend du mode d’interaction et de la version de la GPL. Si vous appelez les API dynamiquement (ex. : services externes), vous n’avez généralement pas à publier votre projet. En revanche, une liaison statique ou la modification puis l’usage de code GPL imposent la publication du code source du projet sous GPL. Consultez un avocat spécialisé pour clarifier la notion d’« œuvre dérivée » et éviter toute ambiguïté juridique.

Que se passe-t-il si j’utilise du code GPL et MIT dans un même projet ?

Il faut respecter les deux licences—ce qui peut être complexe. La GPL impose l’ouverture de tous les dérivés ; MIT autorise l’usage propriétaire—ces conditions sont incompatibles. En pratique, le projet doit se conformer à la licence la plus stricte (GPL) pour garantir la compatibilité. Évitez autant que possible de mixer les licences ou séparez clairement les modules selon leur type de licence pour limiter les contraintes de conformité.