Licences libres : comprendre la GPL, la MIT et l’Apache avant de réutiliser un logiciel

Pourquoi une licence libre est indispensable

Un logiciel libre n’est pas un logiciel dépourvu de règles. Son auteur conserve ses droits d’auteur et choisit d’accorder certaines libertés au moyen d’une licence. Cette licence encadre la copie, l’étude, la modification et la redistribution du code. Elle précise aussi les obligations à respecter lorsqu’un programme ou un composant est intégré à une application, un site web, un système embarqué ou un produit commercial.

La gratuité éventuelle du téléchargement ne constitue donc pas le critère principal. Un logiciel peut être gratuit tout en restant propriétaire et soumis à des restrictions fortes. À l’inverse, un logiciel libre peut être vendu, intégré dans une offre payante ou modifié, à condition de respecter les termes de sa licence.

Dans le langage courant, les expressions « logiciel libre » et « open source » sont souvent employées comme des synonymes. Elles renvoient à des philosophies proches, mais la licence demeure le document décisif. Le nom du projet, la présence d’un dépôt public ou la mention « free » ne permettent pas de déduire les droits accordés. Il faut identifier le texte exact de la licence et vérifier sa version.

Les quatre libertés et leurs conséquences pratiques

Les principes généralement associés au logiciel libre sont la liberté d’utiliser le programme, d’étudier son fonctionnement, de le modifier et de redistribuer le programme original ou une version modifiée. Ces libertés dépendent de l’accès au code source et des conditions prévues par la licence.

Ces droits entraînent des responsabilités concrètes :

• conserver certaines mentions de droit d’auteur ;
• fournir le texte de la licence aux destinataires ;
• indiquer les modifications réalisées lorsque la licence l’exige ;
• redistribuer le code source ou proposer un moyen prévu par la licence pour l’obtenir ;
• respecter les règles relatives aux brevets, aux marques et aux avis de garantie.

Les obligations ne s’appliquent pas toutes de la même manière. Une bibliothèque utilisée uniquement pendant la compilation peut relever de règles différentes d’un composant redistribué avec le logiciel final. La question centrale est donc de distinguer l’utilisation interne, la redistribution et la modification.

GPL : une licence à copyleft qui accompagne la redistribution

La GNU General Public License, souvent abrégée GPL, est une licence dite « copyleft ». Son objectif est de préserver les libertés du logiciel lorsque celui-ci, ou une œuvre dérivée, est redistribué. Les principales versions rencontrées sont la GPL version 2 et la GPL version 3. Elles ne doivent pas être considérées comme interchangeables sans analyse du texte applicable.

Lorsqu’un programme sous GPL est redistribué, le destinataire doit recevoir les droits nécessaires pour l’utiliser, l’étudier, le modifier et le partager. Si une version modifiée est distribuée, les conditions de la GPL s’appliquent généralement à l’ensemble correspondant du code dérivé. Le code source doit être fourni selon les modalités prévues par la licence, avec les avis de droit d’auteur et le texte de la licence.

La GPL ne prohibe pas la vente. Un logiciel sous GPL peut être vendu ou intégré dans une prestation commerciale. La contrainte porte sur les libertés accordées au destinataire, pas sur l’existence d’un prix. Une distribution payante ne permet donc pas de transformer le composant GPL en logiciel fermé pour les utilisateurs finaux.

La détermination du caractère dérivé peut dépendre de l’architecture et du mode de liaison entre composants. La liaison statique ou dynamique, l’incorporation de fichiers et les échanges entre programmes peuvent soulever des questions distinctes. Une communication par un protocole standard ne produit pas automatiquement le même effet juridique qu’une intégration étroite dans un même programme. Pour les cas sensibles, l’analyse du texte de la licence et un avis juridique sont nécessaires.

GPL version 2 et GPL version 3 : des points de vigilance distincts

La GPL version 2 est présente dans de nombreux projets historiques. La GPL version 3 ajoute notamment des dispositions relatives aux brevets, aux mesures techniques de protection et à certaines formes de verrouillage matériel. Un projet peut aussi indiquer « GPL-2.0-or-later » ou « GPL-2.0-only », ce qui ne donne pas les mêmes possibilités de choix de version.

La mention « version 2 ou toute version ultérieure » autorise, selon les termes du projet, l’utilisation d’une version plus récente. À l’inverse, « version 2 uniquement » limite la licence à cette version. Cette indication est importante lorsqu’un projet combine plusieurs dépendances ou lorsqu’une licence compatible est recherchée.

La GPL comporte également une variante appelée LGPL, conçue principalement pour les bibliothèques. Elle peut permettre une liaison avec des programmes distribués sous d’autres licences, sous réserve de respecter les obligations propres à la LGPL, notamment concernant les modifications de la bibliothèque et la possibilité pour l’utilisateur de remplacer certains composants. La présence du sigle GPL dans un nom de projet ne suffit pas à déterminer la licence exacte.

MIT : une licence permissive avec peu de contraintes de redistribution

La licence MIT est une licence permissive. Elle autorise généralement l’utilisation, la copie, la modification, la fusion, la publication, la distribution, la sous-licence et la vente de copies du logiciel. Le code modifié peut être intégré dans un produit propriétaire, sous réserve de respecter les conditions de la licence applicable.

L’obligation principale consiste à conserver l’avis de droit d’auteur et le texte de la licence dans les copies ou les parties substantielles du logiciel. En pratique, une application qui redistribue une bibliothèque sous MIT doit inclure les mentions correspondantes dans ses notices légales, son dossier de licences ou un emplacement équivalent accessible avec le produit.

La licence MIT comporte aussi une clause d’absence de garantie et de limitation de responsabilité. Elle ne constitue pas une promesse de fonctionnement, de sécurité ou d’adaptation à un usage particulier. Cette clause n’annule pas nécessairement toutes les protections prévues par le droit applicable, mais elle rappelle que le logiciel est fourni dans le cadre défini par la licence.

Une licence permissive ne signifie pas « aucune obligation ». Omettre le texte de la licence ou les mentions de copyright peut constituer un non-respect des conditions accordées. Le risque est souvent sous-estimé parce que le composant est court, courant ou utilisé dans une application dont le code principal est propriétaire.

Apache 2.0 : permissive, mais plus détaillée sur les brevets

La licence Apache 2.0 est également permissive. Elle autorise l’utilisation, la reproduction, la modification et la redistribution, y compris dans des produits propriétaires. Comme pour la licence MIT, les redistributions doivent conserver les mentions importantes, le texte de la licence et les indications relatives aux modifications lorsque les fichiers concernés en comportent.

Une particularité importante concerne les brevets. La licence Apache 2.0 prévoit une concession de droits de brevet de la part des contributeurs, dans le cadre défini par le texte, ainsi qu’une règle de retrait de cette concession dans certaines situations de litige en matière de brevets. Cette mécanique distingue Apache 2.0 de nombreuses licences permissives plus courtes.

Lorsqu’un projet sous Apache 2.0 est modifié, les fichiers modifiés doivent porter des indications appropriées. Les fichiers non modifiés conservent leurs notices. La licence demande aussi de transmettre les fichiers NOTICE lorsqu’ils existent, en respectant leur contenu et la manière dont les notices sont présentées.

Apache 2.0 ne transfère pas les droits sur les marques. Le fait de pouvoir réutiliser le code ne donne pas automatiquement le droit d’utiliser le nom, le logo ou l’identité visuelle du projet pour laisser croire à une approbation ou à une origine officielle.

Comparatif des obligations les plus courantes

Le tableau suivant donne une vue d’ensemble. Il ne remplace pas la lecture du fichier de licence et des notices propres au projet.

Point examiné	GPL	MIT	Apache 2.0
Utilisation commerciale	Autorisée, avec respect des conditions de redistribution	Autorisée	Autorisée
Modification du code	Autorisée, avec obligations renforcées lors de la distribution d’une œuvre dérivée	Autorisée	Autorisée, avec indications sur les fichiers modifiés
Code propriétaire autour du composant	Question de compatibilité et de qualification de l’œuvre dérivée à examiner	Généralement possible	Généralement possible
Texte de la licence à conserver	Oui	Oui	Oui
Source à fournir lors de certaines redistributions	Oui, selon les conditions de la GPL	Non, sauf obligation provenant d’une autre licence	Non, sauf obligation provenant d’une autre licence
Notices de droits d’auteur	À conserver	À conserver	À conserver
Règles spécifiques de brevet	Présentes selon la version	Limitées par rapport à Apache 2.0	Développées dans le texte de la licence

Les obligations dépendent du mode d’utilisation

Une même dépendance peut présenter des obligations différentes selon le contexte.

Utilisation interne. Une équipe qui installe un outil libre sur ses propres machines ne le distribue pas nécessairement à des tiers. Les obligations de redistribution peuvent alors ne pas être déclenchées, même si la conservation des informations de licence reste une bonne pratique de gestion logicielle.

Distribution d’une application. Lorsqu’un programme est transmis à des clients, des utilisateurs ou des partenaires, les composants intégrés et leurs licences doivent être recensés. Le paquet distribué peut devoir contenir un dossier de notices, le texte des licences et, pour certains composants sous GPL, le code source correspondant ou une offre conforme aux conditions de la licence.

Service accessible en ligne. Le fait d’exécuter un logiciel sur un serveur ne produit pas toujours les mêmes obligations que la distribution d’un binaire. La GPL classique se concentre sur la propagation et la distribution, tandis que certaines licences de type AGPL prévoient des obligations particulières lorsqu’un logiciel modifié est utilisé pour fournir un service réseau. Il faut donc vérifier la licence exacte plutôt que déduire une règle générale à partir du seul fonctionnement en ligne.

Bibliothèque et dépendance de développement. Un paquet utilisé uniquement pour les tests ou la compilation peut ne pas être inclus dans le produit final. Il faut toutefois vérifier les fichiers générés, les éléments embarqués et les dépendances transitives. Une bibliothèque peut elle-même dépendre d’autres composants soumis à des licences différentes.

Méthode en sept étapes pour auditer les licences d’un projet

Un contrôle précoce évite de découvrir une incompatibilité au moment de publier une application.

1. Inventorier les dépendances. Relever les bibliothèques directes, les modules indirects, les images, les polices, les scripts et les fichiers copiés depuis un autre projet.
2. Identifier le texte exact. Chercher le fichier LICENSE, COPYING, NOTICE ou les en-têtes présents dans les fichiers sources. Noter le nom complet de la licence et sa version.
3. Vérifier l’origine de chaque élément. Le nom d’un paquet ne suffit pas. Deux projets portant des noms proches peuvent avoir des auteurs, des licences ou des versions différentes.
4. Décrire l’usage prévu. Indiquer si le composant est modifié, compilé, lié, inclus dans un exécutable, exécuté sur un serveur ou distribué à des tiers.
5. Contrôler la compatibilité. Comparer les obligations de toutes les licences avec le modèle de distribution du produit. Une licence permissive ne neutralise pas les règles d’une dépendance sous copyleft.
6. Préparer les notices. Regrouper les textes de licence, les crédits, les avis de copyright, les fichiers NOTICE et les indications de modification dans un emplacement accessible aux utilisateurs.
7. Conserver une trace. Archiver la version des dépendances, les licences observées, la date du contrôle et les décisions prises. Cette documentation doit être mise à jour lors de chaque changement de version.

Des outils d’analyse de dépendances peuvent aider à produire un inventaire, mais leurs résultats doivent être vérifiés. Un fichier absent, une licence déclarée de manière incomplète ou un code copié manuellement peut échapper à l’analyse automatique.

Compatibilité, double licence et licences personnalisées

La compatibilité entre licences ne se résume pas à la comparaison des mots « libre » ou « open source ». Une licence peut imposer une obligation incompatible avec celle d’une autre licence. La GPL version 2, la GPL version 3, la LGPL, la MPL et les licences permissives ne forment pas un ensemble interchangeable.

La double licence signifie qu’un même code est proposé sous plusieurs licences distinctes. Le réutilisateur peut alors choisir la licence qui répond à son projet, à condition de respecter intégralement celle qu’il retient. Cette situation est différente d’un projet qui combine plusieurs composants portant chacun leur propre licence.

Les licences personnalisées nécessitent une prudence accrue. Un texte rédigé par un projet peut accorder des droits particuliers tout en utilisant des termes ambigus ou en omettant des permissions importantes. Une licence qui n’est pas clairement reconnue peut compliquer la compatibilité, la redistribution et l’évaluation juridique. Lorsque le code est destiné à un produit professionnel, une revue spécialisée est pertinente avant toute diffusion.

Les marques, les données, les contenus graphiques et les brevets doivent aussi être distingués du copyright du code. Une licence de logiciel ne donne pas automatiquement le droit de réutiliser les logos, les noms commerciaux, les bases de données ou les contenus associés.

Erreurs fréquentes à éviter lors de la réutilisation de code libre

• Confondre absence de prix et absence de conditions : un téléchargement gratuit peut rester soumis à une licence stricte.
• Supprimer les en-têtes de copyright : la modification d’un fichier ne permet pas de retirer les avis des auteurs précédents.
• Publier uniquement le code principal : les obligations peuvent concerner une bibliothèque intégrée ou une dépendance indirecte.
• Présumer qu’une licence MIT autorise tout : les mentions et le texte de la licence doivent être conservés.
• Oublier le fichier NOTICE : Apache 2.0 prévoit des règles particulières lorsque ce fichier accompagne le composant.
• Utiliser le nom du projet comme une marque libre : les droits sur le code et les droits sur une identité commerciale sont distincts.
• Attendre la publication pour auditer : remplacer une dépendance incompatible après la mise sur le marché peut demander une réorganisation coûteuse.
• Se fier à une seule déclaration : les métadonnées d’un gestionnaire de paquets peuvent être incomplètes ou ne pas couvrir les fichiers réellement distribués.

Checklist avant une mise à disposition

Avant de distribuer un logiciel qui contient du code libre, vérifier les points suivants :

• la liste des composants et de leurs versions est disponible ;
• la licence de chaque composant a été identifiée dans sa version exacte ;
• les modifications apportées sont documentées lorsque cela est requis ;
• les textes de licence, avis de copyright et fichiers NOTICE sont inclus ;
• les obligations de mise à disposition du code source ont été examinées pour les composants sous GPL ou une licence comparable ;
• les marques, logos, polices, images et contenus non couverts par la licence du code ont fait l’objet d’un contrôle séparé ;
• la compatibilité entre les licences et le mode de distribution a été vérifiée ;
• un registre interne permet de retrouver les décisions et les versions auditées.

La Free Software Foundation publie les textes et informations de référence relatifs à la GPL, tandis que l’Apache Software Foundation publie le texte de la licence Apache 2.0. Les textes des licences restent les documents de référence pour déterminer les obligations. En cas d’incertitude portant sur une distribution commerciale, une modification importante ou un risque de brevet, un conseil juridique spécialisé est recommandé.

FAQ sur les licences GPL, MIT et Apache

Peut-on vendre un logiciel qui contient du code sous licence GPL ?

Oui. La GPL autorise la vente, mais la redistribution doit respecter les libertés et obligations prévues par la version applicable, notamment la fourniture du code source selon les modalités requises pour les parties concernées.

Le code sous licence MIT peut-il être intégré dans une application propriétaire ?

En règle générale, oui. Il faut conserver l’avis de droit d’auteur et le texte de la licence dans les copies ou parties substantielles redistribuées. D’autres dépendances du projet peuvent imposer des obligations différentes.

Quelle est la principale spécificité d’Apache 2.0 par rapport à MIT ?

Apache 2.0 contient des dispositions plus détaillées sur les brevets, les modifications de fichiers et les fichiers NOTICE. La licence MIT est plus courte et impose principalement la conservation des avis et du texte de licence.

Une licence libre autorise-t-elle l’utilisation du logo du projet ?

Pas automatiquement. Les droits sur le code, les marques, les logos et les contenus graphiques sont distincts. Les règles relatives à la marque doivent être vérifiées séparément.

Que faire si la licence d’une dépendance n’est pas claire ?

Mettre la dépendance en attente dans l’inventaire, rechercher le texte officiel fourni avec la version utilisée et éviter la redistribution avant d’avoir clarifié les droits. Pour un produit professionnel, une analyse juridique permet de traiter les cas ambigus sans se baser sur une interprétation fragile.