GPL et MIT, deux licences libres et deux façons de partager le code

Licence GPL ou MIT, les deux textes laissent utiliser, copier et modifier un logiciel libre. La MIT, permissive, autorise l'intégration du code dans un produit propriétaire ; la GNU GPL impose son copyleft : toute version modifiée distribuée garde la même licence, code source compris.

Ce que la licence MIT et la licence GPL autorisent chacune

La licence MIT et la licence GPL sont deux licences de logiciel libre : toutes deux permettent d'utiliser un programme pour n'importe quel usage, d'en lire le code source, de le modifier et d'en distribuer des copies. Elles figurent sur la liste des licences approuvées par l'Open Source Initiative et sur celle des licences libres reconnues par la Free Software Foundation. Leur point de séparation se trouve dans les conditions attachées à la redistribution, et c'est lui qui change la vie d'un développeur ou d'une entreprise, bien plus que le reste du texte. Ce sujet relève du droit du numérique et des sites web, où le logiciel suit les règles du droit d'auteur.

La licence MIT, une permission presque sans réserve

La licence MIT tient en trois paragraphes. Le premier accorde gratuitement à toute personne qui obtient une copie du logiciel le droit de l'utiliser, de le copier, de le modifier, de le fusionner, de le publier, de le distribuer, de le sous-licencier et de le vendre, « sans restriction ». Le deuxième pose l'unique condition : l'avis de copyright et l'avis de permission doivent figurer dans toutes les copies ou parties substantielles du logiciel. Le troisième exclut toute garantie : le programme est fourni « tel quel » et l'auteur ne répond d'aucun dommage. Née au Massachusetts Institute of Technology à la fin des années 1980, elle porte aussi le nom de licence Expat chez la Free Software Foundation, parce que plusieurs textes circulent sous l'étiquette « MIT ». La licence Expat sert de référence quand on parle de MIT License au sens strict. Cette brièveté explique son succès : un développeur comprend la licence MIT en deux minutes, un service juridique la valide sans réunion.

La licence GPL, la liberté transmise à chaque copie

La licence GPL, ou GNU General Public License, a été rédigée par Richard Stallman pour le projet GNU ; la version 1 date de 1989, la version 2 de juin 1991 et la version 3 du 29 juin 2007. Elle accorde les mêmes libertés de base que la MIT (exécuter, étudier, modifier, redistribuer) mais ajoute une règle : quiconque distribue le programme, modifié ou non, doit le faire sous la même licence, en fournissant le code source ou une offre écrite de le fournir. Cette règle porte le nom de copyleft : le droit d'auteur sert à garantir que la liberté accordée à l'utilisateur ne disparaît pas dans une version dérivée. La GPL version 3 ajoute une licence de brevet explicite, une clause contre le verrouillage matériel des appareils et des règles de compatibilité plus souples. Le noyau Linux reste sous GPL version 2, sans l'option « ou toute version ultérieure ».

Quelle est la différence entre GPL et MIT ?

La différence entre GPL et MIT se résume à ce qu'un développeur devra rendre à la communauté s'il réutilise le code : rien avec la MIT, ses modifications avec la GPL dès qu'il distribue le programme. La licence MIT traite la réutilisation comme une liberté sans contrepartie ; la licence GPL la traite comme un échange, où chaque utilisateur qui redistribue offre à son tour les mêmes libertés. Cette différence de philosophie a des implications concrètes sur le modèle économique, la gestion des contributions et la sécurité juridique d'un projet. Une start-up qui construit un produit fermé à partir de briques open source a besoin de licences permissives ; une collectivité qui finance un logiciel métier et veut le maintenir ouvert, réutilisable par d'autres administrations, a intérêt au copyleft. Les deux licences restent également libres au sens de la Free Software Foundation : la GPL protège la liberté de l'utilisateur final, la MIT celle de l'intégrateur qui réutilise. Les logiciels qui utilisent la licence Expat et ceux utilisant la GPL cohabitent d'ailleurs dans la plupart des distributions Linux, chacun avec sa notice de copyright.

GPL et MIT comparées critère par critère

La comparaison entre licence GPL et licence MIT se joue sur une dizaine de critères concrets, ceux qu'une équipe de développement ou un juriste regarde avant d'intégrer une bibliothèque. Le tableau suivant reprend les textes officiels publiés par la Free Software Foundation et l'Open Source Initiative, sans les interpréter au-delà de leur lettre.

Pour l'utilisateur final qui installe un programme sur son poste, les deux licences produisent le même effet : il peut tout faire. Les écarts n'apparaissent qu'au moment où l'on redistribue le logiciel ou une version modifiée, et c'est pour cette raison qu'une entreprise qui se contente d'utiliser des outils GPL en interne n'a, en pratique, aucune obligation de partage.

Le copyleft de la GPL : quand les obligations se déclenchent

Le copyleft de la GPL ne s'applique qu'à la distribution : tant qu'un logiciel adapté reste dans une entreprise, sur ses serveurs ou sur les postes de ses salariés, la licence GPL n'impose de diffuser aucune ligne de code. Ce point surprend beaucoup de gens, qui croient qu'un simple usage d'un logiciel GPL « contamine » leur propre code. Le texte de la licence vise la transmission de copies à des tiers : vente d'un logiciel, livraison à un client, mise en téléchargement, préinstallation sur un appareil.

Au moment de cette distribution, trois obligations se cumulent. Le distributeur doit fournir le code source complet correspondant, ou une offre écrite valable au moins trois ans de le fournir. Il doit conserver les avis de copyright et signaler les fichiers modifiés, avec une date. Il doit enfin transmettre la licence sans y ajouter de restriction : interdire la redistribution, exiger une redevance par copie ou imposer une clause de confidentialité sur le code est incompatible avec la GPL.

Œuvre dérivée et simple agrégation

La notion d'œuvre dérivée concentre l'essentiel des débats juridiques autour du copyleft. Pour la Free Software Foundation, un programme qui se lie à une bibliothèque GPL, statiquement ou dynamiquement, et partage avec elle des structures de données forme un seul programme : l'ensemble doit être distribué sous GPL. À l'inverse, deux programmes distincts livrés sur le même support et qui communiquent par des mécanismes ordinaires (tubes, sockets, lignes de commande) forment une simple agrégation, et chacun garde sa licence. La frontière n'est pas tracée au millimètre par les tribunaux ; elle se juge sur l'architecture technique réelle du logiciel, pas sur le nom donné au module.

Le cas du logiciel utilisé comme service en ligne

Un logiciel GPL retouché et exécuté sur un serveur web, consulté par des internautes via leur navigateur, n'est pas distribué : aucune copie ne quitte le serveur. La GPL n'oblige donc pas l'éditeur d'une application en ligne à partager ses modifications. La Free Software Foundation a créé l'Affero GPL version 3, publiée le 19 novembre 2007, pour combler cet écart : son article 13 impose d'offrir le code source de la version adaptée aux utilisateurs qui interagissent avec le programme à distance. Un développeur qui veut que son code reste ouvert même en mode cloud choisit donc l'AGPL plutôt que la GPL classique ; la licence MIT, elle, n'offre aucune protection de ce type.

La licence MIT est-elle compatible avec la GPL ?

La licence MIT est compatible avec la GPL : du code sous licence MIT peut entrer dans un projet distribué sous GPL version 2 ou version 3, et l'ensemble est alors distribué sous GPL. La seule condition à respecter consiste à garder l'avis de copyright et le texte de la licence MIT des fichiers repris. L'inverse ne fonctionne pas : du code sous GPL ne peut pas rejoindre un projet distribué sous licence MIT sans que l'ensemble passe sous GPL. La compatibilité va donc dans un seul sens, du plus permissif vers le plus restrictif.

D'autres licences open source suivent la même logique, avec des nuances que le tableau suivant résume d'après la liste commentée de la Free Software Foundation. La licence Apache 2.0, par exemple, est compatible avec la GPL version 3 mais incompatible avec la GPL version 2, à cause de ses clauses de brevet. La licence BSD d'origine, avec sa clause de publicité, reste incompatible avec la GNU GPL, alors que les licences BSD à deux et trois clauses sont compatibles.

Le cas de la GPL version 2 « seule » mérite une attention particulière. Un projet qui l'utilise sans la mention « ou toute version ultérieure » ne peut pas absorber du code sous GPL version 3, et inversement : les deux versions de la même licence GNU deviennent alors incompatibles entre elles. C'est la situation du noyau Linux, dont les contributeurs ne peuvent intégrer aucun code publié uniquement sous GPL version 3.

La LGPL, un copyleft faible pour les bibliothèques

La LGPL, ou GNU Lesser General Public License, sert de compromis entre la licence MIT et la licence GPL pour les bibliothèques logicielles. Un programme propriétaire peut utiliser une bibliothèque LGPL, par liaison dynamique en particulier, sans passer lui-même sous licence libre ; seules les modifications apportées à la bibliothèque doivent être partagées sous LGPL. L'utilisateur doit en outre pouvoir remplacer la bibliothèque par une version modifiée. Les bibliothèques GNU C Library et de nombreuses briques multimédias sont distribuées sous license LGPL pour cette raison.

La Mozilla Public License 2.0 (MPL) applique un copyleft encore plus étroit, limité au code qu'elle couvre : un composant sous MPL modifié reste sous MPL, mais il peut cohabiter avec du code propriétaire dans le même programme. La MPL version 2.0, publiée en 2012, prévoit une compatibilité explicite avec la GPL, la LGPL et l'AGPL ; Firefox et de nombreuses extensions de l'écosystème Mozilla l'utilisent.

GPL ou MIT : vendre, modifier ou intégrer un code libre

Les questions qui reviennent dans les forums de développeurs et chez les juristes portent sur quelques cas limites, où la réponse courte ne suffit pas toujours.

Peut-on vendre un logiciel sous licence GPL ?

La licence GPL autorise à vendre des copies d'un logiciel, modifié ou non, au prix que l'on fixe. La seule exigence consiste à transmettre à l'acheteur le code source et les mêmes libertés : il pourra à son tour redistribuer le programme, gratuitement s'il le souhaite. La Free Software Foundation encourage même la vente de logiciels libres pour financer leur développement ; le modèle économique repose alors sur le support, la maintenance, l'hébergement ou la double licence.

Peut-on utiliser du code sous licence MIT dans un logiciel propriétaire ?

Du code sous licence MIT peut entrer dans un logiciel propriétaire, fermé et vendu, sans publier le code source du produit. La condition consiste à reproduire l'avis de copyright et le texte de la licence MIT, en général dans un fichier de mentions légales ou dans l'écran « À propos » de l'application. Oublier cet avis constitue la principale violation de la licence MIT constatée en pratique.

Peut-on changer la licence d'un projet après sa publication ?

Le titulaire des droits peut changer la licence de ses futures versions, mais pas retirer la licence accordée sur les versions déjà publiées. Dans un projet à plusieurs contributeurs, passer de la GPL à la MIT exige l'accord de chaque auteur dont le code reste dans le projet, ou la réécriture des parties concernées. Les projets qui veulent garder cette souplesse font signer un accord de contribution à chaque développeur.

Faut-il publier le code d'un site web qui utilise un logiciel GPL ?

Un site web qui exécute un logiciel GPL sur son serveur n'a pas à publier son code, car le programme n'est pas distribué aux visiteurs. La règle change pour le code envoyé au navigateur : un script JavaScript sous GPL transmis aux internautes est distribué, et ses conditions s'appliquent. Pour un logiciel sous AGPL, l'accès à distance suffit à déclencher l'obligation de partage.

Ce que le droit français fait d'une licence de logiciel libre

Une licence de logiciel libre est, en droit français, un contrat par lequel l'auteur autorise des usages que le Code de la propriété intellectuelle lui réserve. L'article L112-2 range les logiciels parmi les œuvres de l'esprit, et l'article L122-6 donne à l'auteur un droit exclusif sur la reproduction, la traduction, l'adaptation, la modification et la mise sur le marché du programme. Sans licence, réutiliser un code trouvé en ligne revient donc à reproduire une œuvre protégée sans autorisation, même si le code est visible publiquement. Le logiciel libre ne renonce pas au droit d'auteur : il s'en sert pour fixer ses conditions, ce qui rend la question de la titularité décisive, comme pour une œuvre de collaboration entre plusieurs coauteurs où chaque contributeur garde des droits sur l'ensemble.

Le non-respect d'une licence GPL ou MIT relève de la contrefaçon, et pas seulement d'une faute contractuelle. La Cour de justice de l'Union européenne l'a posé le 18 décembre 2019 dans l'arrêt IT Development (affaire C-666/18) : la violation d'une clause d'un contrat de licence de logiciel porte atteinte aux droits de propriété intellectuelle du titulaire. La cour d'appel de Paris en a tiré les conséquences le 14 février 2024 dans le litige qui opposait la société Entr'Ouvert à Orange : elle a retenu la contrefaçon pour l'usage de la bibliothèque Lasso, publiée sous GPL version 2, dans une plateforme fournie à l'administration sans respect des conditions de la licence. Le titulaire peut donc engager une action en contrefaçon, avec saisie-contrefaçon et dommages-intérêts, à la manière de toute victime qui veut identifier et agir contre une contrefaçon.

La France dispose aussi de ses propres licences libres. Les licences CeCILL, créées en 2004 par le CEA, le CNRS et l'Inria, sont rédigées en droit français et en français, avec une clause de compatibilité qui permet de passer à la GNU GPL. La licence publique de l'Union européenne (EUPL), dont la version 1.2 date de 2017, existe dans toutes les langues officielles de l'Union et liste les licences compatibles, dont la GPL. Ces textes répondent à une critique adressée aux licences américaines : leur rédaction en anglais et leur exclusion de garantie, qui se heurte en partie au droit français de la consommation.

Avantages de la licence MIT et restrictions de la GPL

Quels sont les avantages de la licence MIT ?

La licence MIT offre trois avantages principaux : sa simplicité, sa compatibilité avec presque toutes les autres licences et l'absence de restriction sur la réutilisation commerciale, y compris dans un logiciel fermé. Un texte d'environ 170 mots se lit sans juriste et laisse peu de place au conflit d'interprétation. La licence MIT est compatible avec la GPL, avec la licence Apache, avec la MPL et avec les licences propriétaires, ce qui maximise l'adoption d'une bibliothèque. De grands outils du développement web, comme React, Node.js, jQuery ou Ruby on Rails, l'ont adoptée pour cette raison. La contrepartie relative à ces avantages : ni protection contre la réutilisation fermée, ni clause de brevet, ni exigence de partage des améliorations.

Quelles sont les restrictions de la GPL ?

Les restrictions de la GPL portent toutes sur la redistribution : interdiction de distribuer une version modifiée sous une licence différente, obligation de fournir le code source complet, interdiction d'ajouter des conditions supplémentaires et, pour la version 3, interdiction de verrouiller un appareil grand public de façon à empêcher l'installation d'une version adaptée. L'utilisation privée, en entreprise ou à des fins commerciales reste libre, sans restriction. Ces conditions ne pèsent donc que sur celui qui diffuse le programme, pas sur l'utilisateur qui l'installe.

Pourquoi choisir la GPL plutôt que la MIT ?

Choisir la GPL plutôt que la MIT se justifie quand l'auteur veut que son travail profite à tous ses utilisateurs futurs, et pas seulement aux entreprises qui le réutilisent. Le copyleft garantit qu'une amélioration distribuée revient au projet, ce qui protège un logiciel communautaire contre la création d'une version propriétaire concurrente. La GPL rassure aussi les contributeurs bénévoles : leur code ne servira pas un produit fermé dont ils ne verront jamais les modifications. Pour un éditeur, elle ouvre la voie à la double licence, avec une version commerciale proposée aux clients qui refusent le copyleft. La FSF recommande la GPL pour la plupart des programmes, et la LGPL ou une licence permissive pour les bibliothèques qui affrontent des alternatives propriétaires déjà disponibles.

Quelle licence choisir selon son profil

Entre GPL et MIT, l'objectif poursuivi par l'auteur du code pèse plus que la technique : maximiser la diffusion, ou garantir que chaque version reste libre. Quatre profils reviennent souvent, avec une réponse assez nette pour chacun.

Le développeur qui publie une bibliothèque

Pour une bibliothèque destinée à être utilisée par le plus grand nombre, la licence MIT reste le choix le plus courant : les entreprises l'acceptent sans audit juridique, et l'adoption suit. La licence MIT est d'ailleurs la plus répandue sur GitHub d'après les relevés publiés par la plateforme. Le développeur accepte en contrepartie que des éditeurs intègrent son code dans des produits fermés sans rien rendre. Une licence Apache 2.0 offre la même liberté avec une licence de brevet explicite, utile si la bibliothèque touche à des techniques brevetables ; la LGPL convient à qui veut que les améliorations de la bibliothèque elle-même reviennent au projet.

Le projet communautaire qui veut rester libre

Un projet porté par une communauté de contributeurs, comme une application complète, un système ou un outil métier, a intérêt à choisir la GPL version 3. Le copyleft protège le travail collectif contre l'appropriation : une entreprise qui améliore le logiciel et le distribue doit partager ses modifications, ce qui maintient le projet au même niveau que ses dérivés. Linux, WordPress, GIMP ou VLC (passé en partie à la LGPL pour sa bibliothèque) illustrent ce modèle. Pour une application web, l'AGPL étend la même logique à l'usage en ligne.

L'entreprise qui intègre du code libre

Une entreprise qui intègre des composants open source dans ses produits doit tenir un inventaire des licences utilisées, car le problème ne vient presque jamais de la licence MIT. Les composants MIT, BSD ou Apache se gèrent avec une page de mentions et la conservation des avis de copyright. Les composants GPL imposent une décision d'architecture : soit l'ensemble est distribué sous GPL, soit le composant reste un programme séparé, soit il est remplacé. Le danger apparaît quand le produit est livré à un client ou embarqué dans un appareil ; tant que le logiciel tourne en interne, la GPL n'exige rien.

L'éditeur qui veut une double licence

Un éditeur qui détient tous les droits sur son code peut le proposer à la fois sous GPL et sous licence commerciale : la communauté utilise la version libre, les entreprises qui veulent un produit fermé achètent une licence propriétaire. MySQL et Qt ont rendu ce modèle célèbre. Il suppose de détenir réellement l'ensemble des droits, ce qui impose un accord de contribution signé par chaque développeur externe ; pour cette raison, un site vitrine ou une application commandée à un prestataire pose d'abord la question de savoir qui est propriétaire du code d'un site internet livré par une agence.

Comment savoir si un logiciel est sous GPL ou MIT ?

La licence d'un logiciel se lit d'abord dans le fichier License, License.txt ou Copying placé à la racine du dépôt de code source. La GPL se reconnaît à son titre « GNU General Public License » et à son numéro de version ; la MIT à sa phrase d'ouverture « Permission is hereby granted, free of charge » suivie d'une ligne de copyright avec l'année et le nom du titulaire. Le fichier Copying désigne traditionnellement la GPL dans les projets GNU.

Plusieurs indices complètent cette lecture :

• l'en-tête des fichiers source, qui reprend souvent l'avis de copyright et le nom de la licence, fichier par fichier ;
• l'identifiant SPDX, une référence normalisée comme « MIT », « GPL-2.0-only » ou « GPL-3.0-or-later », placée en commentaire ou dans le manifeste du package ;
• le champ license d'un fichier package.json, composer.json ou pyproject.toml, que les gestionnaires de dépendances affichent ;
• la page du dépôt sur GitHub ou GitLab, qui détecte automatiquement le texte de la licence et l'affiche dans la barre latérale ;
• la documentation ou l'écran « À propos » d'une application, où figurent les avis de copyright des composants tiers.

Un même projet peut contenir des fichiers sous des licences différentes : un logiciel distribué sous GPL embarque souvent des bibliothèques MIT ou BSD, chacune avec son propre avis. Les outils d'analyse de composition logicielle (ScanCode, FOSSology, ou les fonctions intégrées aux plateformes de sécurité) parcourent les dépendances et signalent les licences incompatibles avant la mise en production. Faute d'aucune licence visible, le code reste protégé par le droit d'auteur : il ne peut pas être réutilisé, même s'il est accessible publiquement.

Les limites et les pièges des deux licences

La licence MIT et la licence GPL ont chacune des faiblesses que l'on découvre souvent trop tard, au moment d'une levée de fonds, d'un audit ou d'un litige.

• Absence de clause de brevet dans la MIT : la licence MIT ne dit rien des brevets, ce qui laisse un doute sur la licence implicite accordée par un contributeur titulaire d'un brevet. Les juristes préfèrent Apache 2.0 ou GPL version 3 pour ce problème précis.
• Appropriation possible du code MIT : un concurrent peut reprendre une bibliothèque MIT, l'améliorer et commercialiser le résultat fermé. Plusieurs éditeurs de bases de données open source ont quitté les licences permissives pour cette raison.
• Effet du copyleft sur l'architecture : intégrer une bibliothèque GPL dans un produit propriétaire distribué oblige à tout ouvrir ou à tout réécrire ; le problème se révèle souvent lors d'une due diligence.
• Incompatibilités entre licences libres : GPL version 2 seule et GPL version 3, GPL version 2 et Apache 2.0, ou GPL et certaines licences à clause de publicité ne se mélangent pas.
• Exclusion de garantie et droit de la consommation : l'exclusion totale de responsabilité des deux textes ne vaut pas face à un consommateur en droit français, ce qui laisse un risque résiduel à celui qui vend le logiciel.

Une confusion revient aussi entre logiciel libre et domaine public : un code sous licence MIT ou GPL n'est pas dans le domaine public, son auteur garde ses droits et la licence fixe ses conditions. Pour un vrai abandon des droits, la Creative Commons CC0 sert de référence, même si Creative Commons déconseille ses autres licences pour du code.

Réutilisation de code libre : conformité, sécurité et gestion des licences

La réutilisation de code libre en entreprise passe par une politique de conformité des licences, car une application moderne embarque souvent des centaines de dépendances open source, y compris des dépendances indirectes, chacune avec sa licence et sa notice. La gestion de ces composants poursuit deux objectifs liés : sécuriser juridiquement la distribution du produit, et sécuriser techniquement le code contre les failles connues. Les équipes de sécurité emploient les mêmes outils pour les deux, avec un inventaire appelé SBOM (nomenclature logicielle) qui liste chaque composant, sa version et sa licence. Dans l'Union européenne, le règlement sur la cyberrésilience, adopté en 2024, rend progressivement obligatoire ce type d'inventaire pour les produits comportant des éléments numériques.

Une politique de conformité tient en quelques règles simples, adaptées à la catégorie de chaque licence :

• licences permissives (MIT, BSD, Apache 2.0) : réutilisation autorisée par défaut, avec la reprise des avis de copyright dans la documentation du produit ;
• copyleft faible (LGPL, MPL) : réutilisation autorisée sous conditions techniques, liaison dynamique ou composants séparés, avec partage des modifications de la bibliothèque elle-même ;
• copyleft fort (GPL, AGPL) : validation préalable par le service juridique, selon le mode de distribution du produit ;
• code sans licence ou licence inconnue : réutilisation refusée tant que le titulaire n'a pas répondu.

Par exemple, un même composant peut servir sans risque dans un outil interne et poser un problème dans un produit livré à des clients. La valeur de l'inventaire tient à cette distinction : il dit, composant par composant, ce que chaque licence permet et dans quel cadre. Pour un développeur indépendant qui diffuse un projet sur son site web personnel, la même discipline évite d'importer sans le savoir une dépendance GPL dans un code qu'il pensait distribuer sous MIT.

Appliquer une licence MIT ou GPL à son propre code

Appliquer une licence open source à un projet se fait en quelques fichiers, sans formalité ni dépôt auprès d'un organisme. Les étapes ci-dessous valent pour la licence MIT comme pour la licence GPL, à quelques détails près.

1. Vérifier que l'on détient les droits sur tout le code : le code écrit par un salarié dans l'exercice de ses fonctions appartient à l'employeur (article L113-9 du Code de la propriété intellectuelle), le code d'un prestataire suit son contrat.
2. Copier le texte intégral de la licence dans un fichier License à la racine du dépôt, sans le modifier ; pour la MIT, compléter la ligne de copyright avec l'année et le nom du titulaire.
3. Pour la GPL, ajouter en tête de chaque fichier source l'avis recommandé par la Free Software Foundation, qui précise la version choisie et l'option « ou toute version ultérieure ».
4. Indiquer l'identifiant SPDX dans le manifeste du package et dans le fichier Readme.
5. Recenser les dépendances et leurs licences, pour vérifier que leur combinaison est compatible avec la licence retenue.

Une licence choisie au démarrage du développement évite bien des difficultés : changer de licence plus tard suppose l'accord de tous les contributeurs. Le site choosealicense.com, maintenu par GitHub, et la liste commentée de la Free Software Foundation aident à comparer les licences libres, sans remplacer l'avis d'un avocat pour un produit commercial.