MIT ou Apache 2.0 : quelle licence choisir pour son projet ?

Vous publiez une bibliothèque : quel choix faire ?

Vous préparez la publication d’une bibliothèque et vous hésitez entre MIT et Apache 2.0. Vous voulez permettre sa réutilisation, y compris dans des produits vendus dont les sources restent privées. Les deux licences répondent à cet objectif, sous réserve de respecter leurs conditions. Le caractère commercial du futur produit ne suffit donc pas à les départager.

Pour du code dont je maîtrise les droits, je retiendrais MIT si la priorité est un texte court et peu de formalités de redistribution. Je privilégierais Apache 2.0 si le projet veut accorder explicitement certains droits de brevets des contributeurs et accepte des obligations de notices plus détaillées. Ce sont des critères de décision ; les contraintes des composants utilisés restent à vérifier avant de choisir.

Comparer les conséquences pour ceux qui réutilisent le code

Une équipe qui reprend votre code doit pouvoir déterminer ce qu’elle transmettra à ses propres utilisateurs. Voici les différences du texte standard, critère par critère :

• Usage commercial et code privé : MIT et Apache 2.0 permettent la vente et n’imposent pas, à elles seules, de publier les sources du produit ou ses modifications. Aucune des deux n’exige de reverser les changements au projet d’origine.
• Mentions à transmettre : MIT exige le maintien du copyright et de l’avis de permission dans les copies ou portions substantielles du logiciel. Apache 2.0 exige une copie de sa licence aux destinataires et le maintien des avis applicables dans les sources dérivées distribuées. Je conserverais dans les deux cas le texte complet fourni avec le composant.
• Fichiers modifiés : Apache 2.0 exige des mentions visibles dans les fichiers changés. MIT ne formule pas cette obligation particulière. Les avis d’origine restent à conserver selon la licence concernée.
• Fichier NOTICE : si la distribution Apache 2.0 d’origine en comporte un, les attributions pertinentes doivent être reprises dans les œuvres dérivées distribuées, à l’un des emplacements autorisés. Apache 2.0 n’impose pas de créer systématiquement ce fichier. MIT ne prévoit pas ce mécanisme spécifique.
• Brevets : Apache 2.0 comporte une concession explicite, limitée aux revendications que chaque contributeur peut licencier et qui sont nécessairement enfreintes par sa contribution seule ou avec le logiciel concerné. MIT n’a pas de clause explicite équivalente ; cela ne tranche pas la question d’éventuels droits implicites.
• Garantie : les deux textes prévoient une fourniture en l’état et des exclusions de garantie et de responsabilité. Choisir Apache 2.0 ne transforme pas le projet en logiciel garanti contre les réclamations de tiers.

La clause de brevets Apache prévoit aussi l’extinction des licences de brevets accordées pour le logiciel si vous engagez certaines actions en contrefaçon visant ce logiciel ou une contribution incorporée. Ce mécanisme vise un litige défini par la section 3. Il faut le lire avec la portée de la concession, sans en déduire une protection générale contre tous les brevets.

Choisir pour votre code, conserver les conditions des dépendances

Le choix suppose de détenir les droits nécessaires sur le code publié. Les contributions d’autres personnes, les règles d’un employeur et les fichiers repris d’un projet existant peuvent limiter ce choix. Remplacer LICENSE à la racine ne suffit pas à obtenir des droits manquants.

Prenons un exemple fictif : vous publiez votre propre outil sous MIT et il embarque un composant Apache 2.0. Votre choix ne fait pas disparaître Apache 2.0 du composant. Vous devez encore respecter ses conditions de redistribution, dont le traitement du NOTICE s’il existe. Inversement, utiliser du code MIT dans un projet Apache 2.0 demande de conserver les mentions MIT applicables.

Pour une application existante, je commencerais par inventorier ce qui est effectivement distribué et les licences de ses versions exactes. Le nom de la licence principale donne une entrée dans cette analyse, sans décrire tous les fichiers du projet.

Des situations qui font pencher la décision

Imaginons un petit outil de conversion dont vous avez écrit tout le code. Vous voulez une permission facile à lire et vous n’avez pas d’exigence particulière de concession explicite de brevets. Après vérification des droits, MIT serait mon premier choix. Cette recommandation vient de votre priorité de lisibilité ; la taille du projet ou son langage n’impose pas cette licence.

Autre exemple fictif : plusieurs organisations contribuent à un kit de développement et veulent que les réutilisateurs disposent d’une clause explicite sur les brevets des contributeurs. Je privilégierais Apache 2.0, avec une vérification des droits permettant ces contributions. Il faut alors prévoir le suivi des fichiers modifiés et des attributions dans les distributions. Le nombre d’entreprises ne suffit pas, à lui seul, à justifier ce choix.

Si votre objectif est d’imposer la publication des modifications redistribuées, aucune des deux licences ne fournit cette réciprocité. Il faut alors examiner une licence à copyleft dont les conditions correspondent au périmètre souhaité. Ajouter une obligation personnelle au texte MIT ou Apache produirait une licence modifiée, avec un autre travail d’analyse pour les utilisateurs.

Faire passer la compatibilité avant la préférence

Votre code doit-il rejoindre un ensemble soumis à une autre licence ? La FAQ Apache confirme une compatibilité avec la GPL version 3, mais pas avec la GPL version 2 seule. Dans un scénario où du code Apache 2.0 doit être combiné à un ensemble GPL-2.0-only, cette contrainte passe avant votre préférence pour la clause de brevets. Une simple utilisation côte à côte et la création d’un ensemble dérivé demandent aussi de distinguer ce qui est réellement combiné.

Vérifiez la version exacte des licences et les possibilités de choix qu’elles accordent. Un projet portant la mention GPL-2.0-or-later demande une lecture différente d’un projet limité à GPL-2.0-only. Choisir MIT à la racine ne résout pas automatiquement une incompatibilité entre les composants déjà inclus.

Garder une décision vérifiable dans le dépôt

Une fois les contraintes vérifiées, je consignerais une justification courte : « MIT pour un texte court et des conditions de redistribution limitées » ou « Apache 2.0 pour sa concession explicite de brevets ». Cette phrase doit correspondre à un objectif réel du projet.

1. Inclure le texte standard complet dans LICENSE et renseigner correctement les titulaires des droits dans les avis adaptés au projet.
2. Aligner les métadonnées du paquet avec le choix, en utilisant l’identifiant MIT ou Apache-2.0. Conserver séparément les licences et attributions des composants tiers.
3. Ouvrir l’archive livrée et vérifier que les mentions requises arrivent bien au destinataire. Pour Apache 2.0, contrôler aussi les fichiers changés et les attributions du NOTICE amont lorsqu’il existe.

Ces repères servent à choisir entre les textes standard. Si les droits sur les contributions ou la compatibilité d’un assemblage restent incertains, ce point précis doit être résolu avant la diffusion.

Sources et liens utiles

• Open Source Initiative : texte standard de la licence MIT
• Apache Software Foundation : conditions et clause de brevets d’Apache 2.0
• Apache : FAQ sur les contributions, la redistribution et la compatibilité GPL
• GitHub Choose a License : droits et obligations sous MIT
• GitHub Choose a License : droits et obligations sous Apache 2.0
• GitHub Open Source Guides : choisir selon les objectifs, les dépendances et les droits des contributeurs
• Reprendre un projet : inventorier ses dépendances avant de décider