Licence MIT : utiliser du code et le redistribuer

Une bibliothèque MIT dans une application vendue

Vous trouvez une bibliothèque qui répond à votre besoin. Son fichier LICENSE indique MIT et vous souhaitez l’intégrer dans une application vendue à des clients. Pouvez-vous garder votre code privé ? Devez-vous payer son auteur ou afficher son nom sur chaque écran ?

La licence MIT autorise l’usage commercial et la redistribution sans imposer l’ouverture du code de votre application. Sa condition centrale concerne les mentions qui accompagnent le logiciel repris. Je commencerais donc par lire le fichier de licence de la version utilisée, puis par vérifier ce que contient le livrable envoyé au client.

Ce qu’autorise une licence permissive

Une licence indique les permissions accordées par les titulaires des droits. MIT appartient aux licences permissives : elle autorise notamment la copie, la modification et la vente de copies. Vous pouvez adapter une bibliothèque pour un besoin interne, distribuer votre adaptation ou l’intégrer dans un produit propriétaire, sous réserve de conserver les mentions requises.

Elle ne comporte pas de copyleft, c’est-à-dire d’obligation de redistribuer le code dérivé sous la même licence. Elle ne demande pas non plus de proposer vos modifications au projet d’origine. La publication du code source de votre produit reste donc un choix, dans les limites des licences de ses autres composants.

Le code MIT conserve ses conditions d’origine. Ajouter des conditions commerciales à votre application ne vous autorise pas à supprimer les droits et les mentions attachés à cette partie. L’usage gratuit permis par la licence n’empêche pas de facturer un produit ou un accompagnement.

Le copyright et la licence doivent suivre le code

Le texte MIT exige de conserver l’avis de copyright et l’avis de permission dans toutes les copies ou portions substantielles du logiciel. En pratique, je conserverais le texte complet fourni avec le composant, y compris la clause d’absence de garantie. Un lien vers le dépôt ou la seule mention « MIT » ne remplace pas ce texte.

Prenons un exemple fictif : une application livrée à un client embarque une bibliothèque MIT dans son JavaScript. Un fichier de notices tierces joint à la livraison peut rassembler le nom de cette bibliothèque, les copyrights d’origine et son texte de licence complet. Le nom du fichier reste un choix d’organisation ; il faut que les mentions accompagnent effectivement la copie distribuée.

La licence n’impose pas un bandeau publicitaire sur chaque page. Une rubrique de licences peut rendre ces informations accessibles, mais il faut aussi vérifier les archives et les paquets distribués. Un outil de compilation peut supprimer les commentaires qui les contenaient.

Placer son propre projet sous MIT

Pour un projet dont vous détenez les droits nécessaires, reprenez le texte MIT de référence dans un fichier LICENSE à la racine. Renseignez l’année et le titulaire des droits. Conservez les avis existants si vous réutilisez du code tiers : votre nom ne remplace pas celui de ses auteurs.

Dans un paquet npm, le champ license peut annoncer l’identifiant SPDX MIT. Cet identifiant standard aide les outils à reconnaître la licence ; il complète le fichier et doit correspondre à son contenu. Voici uniquement le champ à ajouter au package.json de votre propre projet MIT.

{
  "license": "MIT"
}

Avant publication, examinez séparément les dépendances et les ressources incluses. Une licence placée à la racine ne transforme pas automatiquement les droits sur une image, une police ou un fichier copié d’un autre projet. Un dépôt public sans licence explicite ne donne pas, à lui seul, les permissions de MIT.

Les limites à connaître avant de choisir MIT

MIT prévoit une fourniture en l’état, avec exclusion de garantie et limitation de responsabilité. Le texte ne promet ni maintenance ni correction des bugs. Pour un produit que vous exploitez, la capacité de maintenir la dépendance reste donc un sujet à examiner.

Elle ne contient pas de concession explicite de licence de brevets comparable à celle d’Apache 2.0. Cette différence compte si vous cherchez une clause précise sur les brevets des contributeurs ; elle ne permet pas, à elle seule, de conclure à l’absence ou à la présence de droits implicites.

Ces repères expliquent le texte standard, sans trancher un cas contractuel particulier. Pour votre prochaine livraison, choisissez une dépendance MIT, retrouvez les mentions de sa version exacte et ouvrez l’archive finale. Vous devez pouvoir y retrouver le texte transmis avec le code concerné.

Sources et liens utiles

• Open Source Initiative : texte de la licence MIT
• SPDX : identifiant MIT et texte de référence
• GitHub Choose a License : permissions et application de MIT
• GitHub : licence d’un dépôt et droits en l’absence de licence
• npm : le champ license du fichier package.json
• Apache 2.0 : la concession explicite de brevets, section 3
• Reprendre un projet : inventorier ce qu’il faut maintenir