Licence MIT ou Apache 2.0 : le guide pour choisir la bonne licence de logiciel libre
Licence MIT ou Apache 2.0 : le guide pour choisir la bonne licence de logiciel libre
La licence MIT ou Apache 2.0 convient à un logiciel pouvant être utilisé, modifié et intégré dans un produit commercial, sans obligation générale de publier le code dérivé. La licence MIT réduit les obligations à la conservation de l’avis de droit d’auteur et de la licence, tandis que la licence Apache 2.0 ajoute notamment des exigences de notices et une concession explicite de droits sur les brevets.
Le bon choix dépend moins de la longueur du texte que du risque que le projet doit encadrer. Un outil simple et largement réutilisable peut privilégier la MIT ; un composant destiné à des intégrations d’entreprise ou à un domaine exposé aux brevets peut justifier Apache 2.0. Cette comparaison explique les permissions, les frictions de redistribution et les vérifications à effectuer avant publication.
En bref
🧩 La licence MIT autorise la réutilisation commerciale, sous réserve de conserver l’avis de droit d’auteur et le texte de licence. Elle est adaptée lorsque la simplicité de redistribution prime.
🔒 La licence Apache 2.0 prévoit une concession explicite de droits sur les brevets apportés par les contributeurs. Elle impose aussi de conserver les avis applicables et de signaler les fichiers modifiés.
📌 Les deux licences sont permissives : elles n’imposent pas, par principe, de publier le code source d’un produit dérivé. Une licence permissive n’est toutefois pas une absence d’obligations.
⚖️ Le choix d’une licence ne règle pas les droits sur les marques, les dépendances ou les contributions sans accord. Un projet avec plusieurs ayants droit mérite une vérification juridique ciblée.
À quoi sert une licence de logiciel libre ?
Une licence de logiciel libre est un contrat de droits d’auteur qui autorise des usages du code que le droit d’auteur réserverait autrement au titulaire. Elle précise ce qu’un utilisateur peut faire du logiciel, ce qu’il doit conserver lors d’une redistribution et les limites de responsabilité posées par les auteurs.
Sans licence explicite, publier un dépôt accessible ne donne pas automatiquement le droit de copier, modifier ou redistribuer son contenu. Le dépôt peut être visible, mais les droits d’exploitation restent en principe réservés à ses titulaires.
Les droits généralement accordés
Les licences MIT et Apache 2.0 autorisent l’utilisation, la copie, la modification et la distribution du logiciel. Elles permettent aussi l’intégration du code dans un produit propriétaire, y compris vendu, sous réserve de respecter leurs conditions documentaires.
- utiliser le logiciel dans un projet personnel, associatif ou commercial ;
- modifier le code pour l’adapter à un produit ou à une infrastructure ;
- redistribuer le code source ou une version compilée ;
- intégrer le composant dans un logiciel dont le code n’est pas public.
Pourquoi le choix dépasse la simple mention LICENSE
Une licence pilote la chaîne de distribution, pas seulement le dépôt initial. Le point sensible apparaît lorsqu’un paquet est intégré à une application, redistribué via un installeur ou combiné avec des bibliothèques sous d’autres licences.
Les équipes doivent également distinguer droits d’auteur, brevets et marques. Une licence open source couvre l’autorisation sur le code visé ; elle ne donne pas automatiquement le droit d’utiliser le nom du projet, son logo ou des éléments tiers présents dans la distribution.
Une licence permissive facilite la réutilisation, mais elle exige que les mentions et les droits incorporés soient suivis jusqu’au produit distribué.
Licence MIT : que permet-elle et quelles sont ses limites ?
La licence MIT est une licence open source permissive, historiquement associée au Massachusetts Institute of Technology dans les années 1980, qui autorise une réutilisation très large du code. Une personne ou une entreprise peut utiliser, modifier, fusionner, publier, sous-licencier ou vendre des copies du logiciel, à condition de conserver la licence et l’avis de droit d’auteur dans les copies ou parties substantielles.
Une obligation documentaire réduite
La licence MIT se distingue par un texte court. Lorsqu’un logiciel sous MIT est redistribué, le distributeur doit inclure la mention de copyright et le texte de la licence ; la licence comporte aussi une exclusion de garantie et de responsabilité.
La licence MIT n’oblige pas, à elle seule, à publier le code source des modifications ou du logiciel dérivé. Une entreprise peut donc intégrer une bibliothèque MIT dans une application propriétaire sans ouvrir l’ensemble de son code.
Les forces de la licence MIT
La simplicité réduit la charge de conformité pour les petites bibliothèques, les exemples de code et les projets dont l’objectif est une adoption large. Les obligations sont faciles à comprendre pour un intégrateur, à condition que le fichier de licence accompagne réellement les distributions.
- texte de licence court et facile à intégrer dans un dépôt ;
- compatibilité pratique fréquente avec des modèles de distribution commerciaux ;
- faible friction pour les utilisateurs et les contributeurs ;
- pas de mécanisme de copyleft imposant la publication du code dérivé.
Les limites à regarder avant de choisir MIT
La concision de la MIT ne crée pas de protection explicite comparable à la clause de brevets de la licence Apache 2.0. Ce point ne signifie pas que chaque projet sous MIT est dangereux ; il signifie que le texte de la licence répond moins directement à cette question.
La licence MIT ne règle pas non plus les droits d’un contributeur qui aurait copié du code tiers sans autorisation. Une licence choisie par le mainteneur n’efface jamais une dépendance incompatible, un brevet potentiellement applicable ou une contribution dont l’origine est incertaine.
Licence Apache 2.0 : pourquoi est-elle plus encadrée ?
La licence Apache 2.0 est une licence permissive approuvée par l’Apache Software Foundation en 2004. Elle autorise l’utilisation, la reproduction, la modification et la distribution sans redevance, y compris dans un logiciel commercial, mais elle encadre davantage les avis à transmettre et les droits de brevet liés aux contributions.
Les obligations à respecter lors d’une redistribution
La licence Apache 2.0 demande de conserver les avis de droit d’auteur, les avis de licence et les éventuelles mentions du fichier NOTICE lorsqu’elles s’appliquent. Les fichiers modifiés doivent aussi porter une indication claire signalant que des changements ont été apportés.
La contrainte Apache 2.0 porte surtout sur la traçabilité des avis et des modifications, pas sur une obligation générale de publier le code dérivé. Cette distinction évite de la confondre avec une licence à copyleft fort.
La clause de brevets Apache : un élément distinctif
La licence Apache 2.0 comporte une concession de brevet accordée par les contributeurs pour leurs contributions. Le texte prévoit aussi une terminaison de cette concession dans certaines situations de litige en matière de brevets engagées contre le logiciel ou une contribution couverte.
Cette clause ne garantit pas l’absence de contentieux et ne couvre pas tous les brevets existants dans le monde. Elle donne néanmoins un cadre explicite que la licence MIT ne formule pas de la même manière, ce qui peut peser dans un projet impliquant plusieurs entreprises ou des travaux de recherche et développement.
La clause de brevets Apache 2.0 réduit une zone d’incertitude contractuelle ; elle ne remplace ni l’audit des dépendances ni l’analyse d’un risque de brevet particulier.
Licence MIT ou Apache 2.0 : quelles différences concrètes ?
La différence entre licence MIT et Apache 2.0 se joue principalement sur le niveau de formalisation. La MIT est plus courte et demande surtout de conserver son texte ; Apache 2.0 ajoute des règles de notification, une gestion des fichiers NOTICE et une clause de brevets. Les deux licences permettent l’usage commercial et l’intégration dans un logiciel propriétaire.
| Critère | Licence MIT | Licence Apache 2.0 | Conséquence pratique |
|---|---|---|---|
| Usage commercial | Autorisé | Autorisé | Les deux conviennent à un logiciel propriétaire intégrant le composant. |
| Code source dérivé | Pas d’obligation générale de publication | Pas d’obligation générale de publication | Ces licences ne sont pas à copyleft fort. |
| Mentions à conserver | Copyright et texte de licence | Copyright, licence et avis applicables | Apache 2.0 demande un suivi documentaire plus complet. |
| Fichiers modifiés | Signalement non imposé par le texte MIT | Modifications à identifier | Apache 2.0 favorise la traçabilité des changements. |
| Brevets | Pas de concession explicite dans le texte | Concession explicite sous conditions | Apache 2.0 est souvent plus pertinente si ce sujet est central. |
| Charge de conformité | Faible | Modérée | Le processus de release doit gérer les avis Apache. |
Peut-on combiner du code MIT et Apache 2.0 ?
Un projet peut généralement inclure un composant sous licence MIT et un autre sous licence Apache 2.0, à condition de respecter les obligations de chaque composant. En pratique, la distribution finale doit conserver le texte MIT pour les portions MIT et les avis Apache 2.0, y compris les éléments NOTICE applicables.
Le piège consiste à remplacer tous les fichiers de licence par une seule licence maison. Une distribution combinée doit préserver les attributions et les avis exigés par les composants qu’elle intègre. La présence d’une dépendance GPL, AGPL ou sous licence propriétaire peut modifier l’analyse ; notre dossier sur les différences entre GPL et AGPL aide à situer ces licences à copyleft dans la décision.
MIT, Apache 2.0 ou GPL : trois logiques distinctes
La GPL constitue une alternative réelle mais poursuit un objectif différent. La GPL impose un copyleft fort : lorsqu’un logiciel dérivé est distribué dans son périmètre, le code correspondant doit être proposé sous la même licence. MIT et Apache 2.0 privilégient, elles, la réutilisation sans obligation générale de placer le dérivé sous la même licence.
- MIT : priorité à la simplicité et à la réutilisation maximale ;
- Apache 2.0 : priorité à la réutilisation avec un cadre plus explicite sur les brevets et les avis ;
- GPL : priorité au maintien des libertés de redistribution du code dérivé.
Comment choisir entre licence MIT ou Apache 2.0 selon son projet ?
Choisissez la licence MIT si votre priorité est un texte minimal et une adoption fluide par des développeurs ou éditeurs qui souhaitent réutiliser votre code avec peu de formalités. Choisissez Apache 2.0 si le projet reçoit des contributions variées, s’inscrit dans un environnement d’entreprise ou si la question des brevets mérite un cadre contractuel explicite.
La MIT est plus adaptée à certains projets simples
Une petite bibliothèque utilitaire, un outil de développement, un exemple de code ou un composant dont la diffusion large est l’objectif principal peut être publié sous MIT. Le mainteneur doit accepter que des tiers puissent créer une version dérivée fermée, à condition de préserver les mentions requises.
Apache 2.0 est plus pertinente pour des contributions structurées
Un framework, une plateforme technique ou un projet auquel plusieurs organisations contribuent peut préférer Apache 2.0. La clause de brevets et les exigences de notification donnent un cadre plus précis pour la redistribution, au prix d’une documentation de conformité plus rigoureuse.
Quand demander un avis juridique ?
Un avis d’avocat ou d’un spécialiste de la conformité open source devient pertinent lorsqu’un produit incorpore du code de nombreux fournisseurs, vise un secteur réglementé, fait l’objet d’un financement ou s’appuie sur des brevets identifiés. Une vérification est aussi recommandée lorsque plusieurs salariés, prestataires ou contributeurs externes ont participé sans accord de contribution clair.
Le texte d’une licence répond à des droits précis, mais il ne remplace pas la vérification de la chaîne de titularité du code. Cette information est générale et pédagogique ; elle ne constitue pas un conseil juridique personnalisé.
Comment ajouter une licence à son projet : les étapes utiles
Ajouter une licence ne consiste pas seulement à créer un fichier nommé LICENSE. La publication doit identifier le titulaire des droits, documenter les composants tiers et préparer la redistribution future. Cette discipline évite de découvrir, au moment d’un audit client, qu’un avis obligatoire a disparu d’une archive ou d’un paquet compilé.
- Vérifiez qui détient les droits sur le code : créateurs individuels, salariés, prestataires et contributeurs externes.
- Choisissez le texte intégral de la licence MIT ou Apache 2.0, sans le réécrire ni le tronquer.
- Ajoutez un fichier
LICENSEà la racine du dépôt et renseignez l’identifiant de licence dans les métadonnées du projet lorsque l’outil le prévoit. - Inventoriez les dépendances et conservez leurs textes de licence, attributions et éventuels fichiers NOTICE.
- Pour Apache 2.0, indiquez les modifications dans les fichiers concernés et préparez les avis à inclure dans les versions distribuées.
- Contrôlez l’archive, le conteneur, le paquet et l’installeur réellement livrés aux utilisateurs.
Quelles erreurs fréquentes compliquent la conformité ?
Les erreurs de licence apparaissent rarement dans le code qui vient d’être écrit. Elles surgissent à l’intégration, lors d’une livraison commerciale ou après l’arrivée d’un nouveau contributeur. Un contrôle léger mais régulier est plus utile qu’une correction massive juste avant un audit.
- Confondre open source et domaine public : le code reste protégé par le droit d’auteur ; la licence définit les permissions.
- Supprimer les avis dans une version compilée : une application distribuée doit continuer à transmettre les éléments requis par les licences embarquées.
- Oublier le fichier NOTICE sous Apache 2.0 : une redistribution peut devoir conserver les mentions applicables contenues dans ce fichier.
- Choisir une licence sans vérifier les dépendances : la licence du projet principal ne neutralise pas les obligations d’une bibliothèque tierce.
- Ignorer les marques : le droit d’utiliser le code n’autorise pas automatiquement l’usage du nom ou du logo d’un projet.
Sources utiles à consulter
Le texte officiel reste la référence lorsqu’une obligation de redistribution est en jeu. L’Apache Software Foundation publie le texte intégral de la licence Apache 2.0, y compris les clauses sur les avis, les modifications et les brevets.
L’Open Source Initiative publie également des textes de licence reconnus et des ressources de référence sur les licences open source. Pour une décision engageante, notamment en présence de brevets, de contrats clients ou de code tiers, un professionnel du droit compétent dans votre pays doit valider l’analyse.
À retenir
- 🧩 La licence MIT privilégie la simplicité documentaire et la réutilisation large.
- 🔒 Apache 2.0 ajoute une clause explicite sur les brevets des contributeurs.
- 📄 Les deux licences imposent de préserver certaines mentions lors de la redistribution.
- ⚙️ Apache 2.0 exige aussi d’identifier les fichiers modifiés.
- ⚖️ Les dépendances, marques et droits des contributeurs demandent une vérification séparée.
Questions fréquentes sur la licence MIT et Apache 2.0
Peut-on vendre un logiciel sous licence MIT ou Apache 2.0 ?
Oui. Les licences MIT et Apache 2.0 autorisent l’utilisation commerciale et la vente de copies du logiciel. Le vendeur doit toutefois respecter les obligations d’attribution, de licence et, pour Apache 2.0, les avis applicables.
Faut-il publier les modifications du code ?
Ni la MIT ni Apache 2.0 n’impose généralement de publier le code source dérivé. Apache 2.0 demande toutefois de signaler les fichiers modifiés lors de la redistribution. Une autre licence présente dans les dépendances peut imposer des obligations différentes.
Quelle licence encadre le mieux les brevets ?
Apache 2.0 contient une concession explicite de droits sur les brevets des contributeurs, avec des conditions prévues par son texte. Cette clause ne constitue pas une garantie contre tout litige ni une analyse de liberté d’exploitation pour un produit particulier.
Peut-on changer la licence après une première publication ?
Le titulaire des droits peut publier les versions futures sous une autre licence s’il détient les droits nécessaires sur l’ensemble du code. Les versions déjà distribuées restent disponibles sous la licence avec laquelle elles ont été publiées, et les contributions externes peuvent nécessiter un accord préalable.