Qu’est-ce que la GPL ? Comprendre la licence publique générale GNU

GPL signifie General Public License, ou licence publique générale. Dans le domaine du logiciel, ce sigle désigne généralement la GNU General Public License : une licence de logiciel libre qui permet d’exécuter, d’étudier, de modifier et de partager un programme. Sa caractéristique principale est le copyleft. Lorsque vous distribuez une œuvre couverte, vous devez préserver les libertés accordées à ses destinataires et respecter les exigences relatives au code source.

La licence GPL autorise l’utilisation commerciale et la distribution payante. Elle n’impose pas de publier en ligne chaque modification privée et ne donne pas automatiquement accès à l’abonnement d’assistance ou au compte cloud d’un développeur. Ces distinctions concernent aussi bien l’installation d’un plugin WordPress que la création d’une application ou le partage d’un programme modifié.

Ce que la licence GPL signifie pour votre copie

La GNU GPL est publiée par la Free Software Foundation. GNU désigne le projet à l’origine de la licence ; GPL est le nom de la licence elle-même. Les expressions anglaises « GPL license » et « GPL licence » renvoient au même concept, avec deux variantes orthographiques. Les conditions applicables dépendent de la version et de la mention de licence qui accompagnent le logiciel.

Le mot libre exprime une liberté, sans garantir un prix nul. Une personne peut faire payer un programme couvert par la GPL. Dès lors que vous recevez une copie sous cette licence, le fait de l’avoir achetée ne supprime pas les droits qu’elle vous accorde. GNU explique cette distinction dans sa définition du logiciel libre.

Ces droits permettent plusieurs activités courantes :

• Exécuter le logiciel : l’utiliser pour vos propres besoins, y compris dans un cadre professionnel.
• L’étudier : examiner le code source pour comprendre son fonctionnement.
• Le modifier : adapter le code à vos exigences.
• Le partager : redistribuer les copies autorisées, y compris les versions modifiées, en respectant les conditions de la GPL applicable.

Par exemple, une petite entreprise peut utiliser une application GPL pour gérer ses dossiers internes. Un développeur peut modifier une fonction afin de l’intégrer à une autre organisation du travail. Un distributeur peut proposer des copies accompagnées d’une aide à l’installation. La licence permet ces activités, mais les obligations varient selon ce qui est effectivement transmis.

Il est donc plus utile de lire la licence que de demander uniquement si un programme est « gratuit ». Vérifiez ce que couvre la mention de licence, quelle version de la GPL s’applique et si d’autres composants sont soumis à des conditions distinctes.

Le copyleft préserve les permissions lors du partage

Le code couvert par la GPL reste protégé par le droit d’auteur. Ses auteurs utilisent une licence pour accorder des permissions assorties de conditions. Un logiciel GPL se distingue donc d’un logiciel placé dans le domaine public.

Le copyleft signifie qu’un distributeur ne peut pas prendre une œuvre dérivée couverte et priver ses destinataires des libertés GPL qui lui sont attachées. Il préserve la possibilité, pour la personne suivante, de travailler avec le programme, au lieu de réserver cette permission à son premier destinataire. L’explication du copyleft par GNU décrit ce mécanisme.

Prenons un exemple : vous améliorez l’affichage des fuseaux horaires dans une application de planification sous GPL. Vous pouvez utiliser votre copie modifiée à titre privé. Si vous distribuez cette application modifiée couverte, vous devez respecter les exigences de la GPL applicable à l’œuvre distribuée. Une mention telle que « vous pouvez l’utiliser, mais jamais la redistribuer » contredirait les droits que les destinataires doivent recevoir.

Cela ne signifie pas que tous les fichiers sans rapport présents sur votre ordinateur passent sous GPL. Pour déterminer si un code constitue une œuvre dérivée ou combinée couverte, il faut examiner sa relation avec le programme GPL. Le simple partage d’un support de stockage ou d’un serveur avec une autre application ne tranche pas cette question. L’intégration de bibliothèques et la création de produits combinés exigent d’étudier l’architecture réelle avant de prendre une décision de licence.

Utiliser un logiciel et le distribuer sont deux actions différentes

La question la plus utile est la suivante : donnez-vous à quelqu’un une copie du logiciel couvert ? Le fait de facturer constitue une question distincte.

La GPLv3 emploie le terme anglais convey, traduit ici par « transmettre », pour désigner les activités qui permettent à d’autres personnes de réaliser ou de recevoir des copies. Elle les distingue expressément d’une interaction par réseau sans transfert de copie. La GPLv2 utilise le vocabulaire de la distribution. Les sections 0 à 2 du texte de la GPLv3 présentent ces définitions et les permissions de base.

Un programme d’installation, une archive téléchargeable ou un ensemble de code exécuté côté client peuvent modifier l’analyse, car l’utilisateur reçoit alors éventuellement du logiciel. De même, remettre un paquet modifié à une organisation distincte diffère du fait de le garder sur votre propre machine. Ce tableau fournit une orientation ; il ne tranche pas tous les cas possibles de prestataires, de groupes d’entreprises ou de déploiements.

La GPL exige-t-elle de rendre votre code source public ?

Elle n’impose pas une obligation universelle de téléverser chaque changement dans un dépôt public. Pour un logiciel couvert que vous distribuez, vous devez respecter les règles d’accès au code source correspondant à la version applicable et au mode de distribution choisi.

Une précision compte : certaines modalités fondées sur une offre écrite bénéficient aussi à des personnes autres que l’acheteur direct. Par exemple, la section 3(b) de la GPLv2 décrit une offre de fournir le code source à tout tiers. Dire que « le code source ne va jamais qu’à vos clients » serait donc également trop général. Consultez la modalité retenue dans la section 3 du texte de la GPLv2.

Pour un distributeur, la question pratique est plutôt : la personne qui a droit au code source correspondant peut-elle réellement obtenir le bon code pour cette copie ? Une référence vague au projet d’origine apporte moins de clarté qu’un dispositif de fourniture précis, associé à la version distribuée.

Qu’est-ce que le code source correspondant ?

Le code source est la forme que les développeurs utilisent pour modifier l’œuvre. Dans la GPLv3, le code source correspondant comprend les éléments nécessaires pour générer, installer, exécuter et modifier le code objet couvert, sous réserve des exclusions définies par la licence.

Imaginons un distributeur qui modifie la logique de traitement d’une application, puis fournit une version compilée à ses clients. Envoyer seulement le code source original du projet laisserait de côté la modification qu’ils ont reçue. Le dispositif de fourniture du code source doit correspondre à cette version compilée, avec les éléments de compilation pertinents. Cet exemple concerne la cohérence entre la copie distribuée et son code source ; les modalités exactes de fourniture restent fixées par la licence applicable.

La conservation du texte de licence et des mentions pertinentes compte également. Un dossier de code source lisible ne remplace pas ces exigences. Gérez ensemble le code source, les mentions et le mode de distribution lors de la préparation d’une version.

GPLv2 et GPLv3 : lire la mention avant de choisir

La GPLv2 et la GPLv3 sont deux versions distinctes de la GNU GPL. La GPLv2 date de 1991 et la GPLv3 de 2007. Toutes deux sont des licences copyleft, mais leur rédaction et leurs exigences ne sont pas interchangeables. Une licence plus récente ne remplace pas automatiquement celle qui accompagne un programme existant.

La GPLv3 comprend des dispositions explicites sur les brevets, des dispositions de compatibilité révisées et des exigences relatives aux informations d’installation dans certaines situations définies concernant les « produits utilisateur » ou User Products. Ces changements répondent à des cas qui dépassent le simple téléchargement de code source. Le guide rapide de GNU sur la GPLv3 les explique.

Les informations d’installation se prêtent particulièrement aux généralisations abusives. La GPLv3 ne demande pas à tout vendeur de logiciel de remettre tous ses mots de passe d’exploitation. Sa section 6 concerne le code objet couvert transmis dans, avec, ou spécifiquement pour une utilisation dans certains User Products, selon des conditions et exceptions précises. Cette distinction concerne les produits qui pourraient autrement empêcher un destinataire d’installer une version modifiée.

Pour la plupart des lecteurs, la première étape est plus simple : retrouver la mention de licence du programme.

• GPLv2 uniquement : la permission se limite à cette version, sauf autre permission applicable.
• GPLv2 ou toute version ultérieure : la mention permet de choisir la GPLv2 ou une version ultérieure publiée par la FSF.
• GPLv3 uniquement : le programme est sous GPLv3, sans autorisation générale d’utiliser une version ultérieure.

Le code GPLv2 uniquement et le code GPLv3 ne sont pas automatiquement compatibles pour une œuvre combinée. Une mention GPLv2 ou ultérieure peut ouvrir la possibilité d’utiliser la GPLv3. La liste de compatibilité des licences de GNU explique cette différence.

Ne déduisez pas « ou ultérieure » d’un titre de page qui indique seulement GPL. Si le paquet contient plusieurs dépendances, vérifiez aussi leurs mentions. La permission d’utiliser une version ultérieure pour un composant ne réécrit pas la licence de toutes les dépendances.

GPL, LGPL, AGPL et MIT répondent à des besoins différents

Ces noms correspondent à des régimes de licence distincts. Comprendre leurs différences de base permet de trouver le bon texte, sans considérer toutes les licences open source comme équivalentes.

La Lesser General Public License, ou licence publique générale amoindrie, est souvent utilisée pour les bibliothèques. Elle ne permet pas d’ignorer leurs conditions de licence. Par exemple, la section 4 de la LGPLv3 comprend des conditions concernant les œuvres combinées, les mentions et la possibilité pour l’utilisateur de travailler avec une bibliothèque modifiée.

L’Affero General Public License traite plus directement les interactions à distance. La section 13 de l’AGPLv3 exige qu’une version modifiée propose de manière bien visible son code source correspondant aux utilisateurs qui interagissent avec elle à distance par un réseau informatique. La GPLv3 ordinaire ne crée pas cette même obligation du seul fait qu’un programme tourne sur un serveur.

La licence MIT autorise une réutilisation étendue tout en imposant de conserver ses mentions de droit d’auteur et d’autorisation. Du code sous MIT peut généralement être incorporé dans un projet couvert par la GPL si ces conditions sont préservées. Cela ne transforme pas le code déjà couvert par la GPL en code MIT et ne supprime pas les obligations GPL de l’œuvre combinée.

Il n’existe pas de licence universellement préférable parmi celles-ci. Pour un auteur, le choix exprime la manière dont il souhaite organiser le partage ultérieur. Pour l’utilisateur d’un projet existant, les permissions disponibles partent de la licence effectivement accordée par les titulaires des droits.

Quand la GPL peut limiter un projet

La principale limite apparaît lorsque les conditions de distribution envisagées contredisent le copyleft. Si vous voulez fournir le code exécutable d’une œuvre combinée couverte tout en interdisant à ses destinataires de la redistribuer ou d’accéder à son code source correspondant, la GPL peut être incompatible avec ce projet de diffusion. La préparation du code source et la compatibilité des dépendances demandent aussi du temps dans le processus de livraison.

Le choix pratique oppose la préservation des libertés des destinataires au maintien de certaines restrictions de distribution. Il n’empêche pas de bâtir une activité commerciale autour du logiciel. Évaluez ce choix avant d’intégrer un composant GPL dans un produit à livrer, pour éviter de découvrir des engagements contradictoires au moment de la livraison.

Ce que la GPL signifie pour WordPress, les plugins et les thèmes

WordPress indique que son logiciel est publié sous GPLv2 ou ultérieure. Sa page officielle consacrée à la licence explique également la position du projet : les plugins et les thèmes sont des œuvres dérivées. Elle reconnaît toutefois les zones d’incertitude juridique entourant la définition d’une œuvre dérivée.

Cela explique pourquoi la GPL revient si souvent dans les discussions sur les extensions WordPress. Elle permet de partager le logiciel couvert selon ses conditions, y compris par une distribution commerciale. Mais le nom d’un produit ou une étiquette de place de marché ne révèle pas tout sur un paquet précis.

Lorsque vous examinez un plugin, distinguez trois éléments :

1. La licence de droit d’auteur : quelles permissions s’appliquent au code couvert ?
2. Le paquet fourni : quels fichiers et éléments sous licences distinctes sont réellement inclus ?
3. Les services : qui fournit les téléchargements, les mises à jour, l’assistance et les éventuelles fonctions hébergées ?

Une clé de compte du développeur peut contrôler l’accès à un service ou à un canal de mise à jour. Cette question diffère des permissions de droit d’auteur attachées au code reçu. La GPL elle-même ne promet ni compte fournisseur, ni service distant payant, ni assistance future.

Les exigences des répertoires WordPress ont également leur propre périmètre. Les règles du répertoire des plugins exigent que le code, les données et les images soumis utilisent des licences compatibles avec la GPL. Il s’agit d’une règle du répertoire, qui ne prouve pas que toutes les archives téléchargeables ailleurs possèdent les mêmes contenus ou les mêmes droits.

Si votre question pratique porte sur ce qu’inclut un téléchargement WordPress provenant d’un tiers, consultez le guide des paquets de plugins WordPress sous GPL. Il approfondit le choix du paquet et des services. La présente explication porte sur la licence, plutôt que sur la comparaison des vendeurs ou des plugins individuels.

Quatre exemples pour comprendre les limites

Les situations suivantes sont des exemples. Elles montrent quel fait modifie la question posée ; elles ne relatent pas des tests de produits.

Un commerce utilise une application GPL en interne

Un commerce installe un outil de gestion des stocks sous GPL et l’utilise pour suivre ses marchandises. Il fait payer ses clients pour des produits physiques. Cette activité commerciale ne distribue pas, à elle seule, l’application de gestion. L’action pertinente concernant le logiciel est l’exécution du programme, que la GPL autorise à des fins commerciales.

Le commerce devrait néanmoins conserver une trace du logiciel installé et de sa licence. S’il fournit ensuite l’application à une autre organisation, cette nouvelle action nécessite d’examiner les exigences de distribution.

Un développeur transmet une application modifiée à un client

Un développeur modifie le format des rapports d’une application GPL et remet l’application modifiée à un client. Le client reçoit une copie du logiciel : les exigences de distribution applicables doivent donc être respectées. La rémunération du travail de développement ne les supprime pas.

Avant la livraison, le développeur doit identifier les modifications couvertes, conserver les mentions requises et organiser la fourniture du code source correspondant. Un contrat peut définir le travail et l’assistance, mais ne doit pas promettre de restrictions incompatibles avec les droits GPL transmis au client.

Un site utilise un logiciel GPL côté serveur

Une entreprise modifie un programme GPLv3 pour effectuer des calculs sur son serveur. Les visiteurs envoient des données et reçoivent des résultats sans recevoir de copie du programme. L’interaction réseau seule n’est pas une transmission au sens de la GPLv3.

Changeons maintenant un fait : le site envoie du code couvert aux appareils des visiteurs. La question de la distribution revient. Changeons un autre fait : le programme serveur est sous AGPLv3 et l’entreprise l’a modifié. La disposition AGPL sur la fourniture du code source aux utilisateurs du réseau devient pertinente. « C’est un site web » ne suffit donc pas pour déterminer les obligations applicables.

Une graphiste crée du contenu avec un outil GPL

Une graphiste utilise une application graphique sous GPL pour produire une illustration originale. La licence GPL de l’application ne rend pas automatiquement l’illustration GPL. Le contenu du résultat compte : la GPLv3 ne couvre la sortie que si celle-ci constitue elle-même une œuvre couverte.

La graphiste doit examiner séparément les polices, modèles ou éléments utilisés dans l’illustration. La licence de l’outil d’édition et les permissions relatives à ces éléments sont des faits distincts. GNU présente ce principe dans sa FAQ sur les résultats produits par un programme.

Comment utiliser la GPL pour votre propre logiciel

Vous n’obtenez pas la GPL en achetant une clé d’activation spéciale. Si vous possédez les permissions de droit d’auteur nécessaires, vous pouvez publier votre propre logiciel sous cette licence. Le guide de GNU sur l’application de ses licences décrit la procédure.

Commencez par identifier le code dont vous maîtrisez les droits. Un projet peut inclure des contributions, du travail appartenant à un employeur, des dépendances et des éléments aux droits différents. Choisir la GPL pour vos fichiers originaux ne vous autorise pas à changer la licence des créations d’autrui.

Choisissez ensuite la version de la licence et décidez si votre mention autorise les versions ultérieures. Joignez au code source le texte complet de la licence et les mentions appropriées. Rendez ce choix visible dans la documentation du projet et préparez les modalités de fourniture du code source propres à la distribution avant de livrer des versions compilées.

Pour un petit utilitaire écrit entièrement par un seul auteur, le travail peut être simple : ajouter un fichier de licence, appliquer les mentions appropriées et publier le code source avec des instructions de compilation claires. Un projet plus vaste, comportant des dépendances, exige un examen composant par composant. Copier une étiquette GPL dans un README ne suffit pas si le contenu du paquet indique autre chose.

Réponses courtes aux autres questions sur la GPL

Peut-on vendre un logiciel sous licence GPL ?

Oui. La GPL autorise la distribution payante du logiciel couvert si ses conditions sont respectées. Les acheteurs reçoivent les droits de la GPL applicable, notamment le droit de redistribution. Les explications de GNU sur la vente de logiciels libres montrent comment faire payer et préserver les libertés peuvent aller de pair.

La GPL et l’open source sont-ils la même chose ?

La GPL est une licence open source, mais l’open source englobe d’autres licences aux conditions différentes. Une licence permissive comme MIT et une licence copyleft comme GPL permettent toutes deux une collaboration autour du code source, tout en fixant des règles différentes pour la distribution ultérieure.

La GPL autorise-t-elle l’utilisation de la marque d’un projet ?

Les permissions de droit d’auteur sur le logiciel ne règlent pas automatiquement les droits de marque. Redistribuer du code ne permet pas nécessairement de prétendre que le développeur original approuve votre version. WordPress dispose, par exemple, d’une politique distincte relative aux marques.

Une étiquette GPL prouve-t-elle qu’un téléchargement est sûr ?

Non. Les conditions de licence décrivent des permissions et des obligations. Elles n’établissent ni l’origine, ni l’intégrité, ni le suivi d’une archive donnée. Ces vérifications restent distinctes, que le logiciel soit sous GPL, sous licence permissive ou propriétaire.

Partir de la copie et de l’action envisagée

Pour appliquer ces explications à un projet réel, relevez la mention de licence du logiciel, identifiez ce que vous voulez faire et déterminez si une personne reçoit du code couvert. Vérifiez ensuite les conditions de cette version et de ce mode de distribution.

Pour un achat WordPress, examinez aussi, séparément, le paquet et les services dont vous avez besoin. Pour une livraison de développement, vérifiez les dépendances et le code source correspondant. Ces faits concrets vous renseigneront bien davantage que le seul sigle GPL.