Créez un fichier LICENSE : MIT, Apache 2.0, GPL 3.0 et 20 autres, avec votre nom et l'année
Fonctionne dans votre navigateur. Rien de ce que vous saisissez n'est envoyé nulle part. Vérifié le 16 octobre 2026.Un générateur de licence vous donne le texte complet d'une licence open source avec votre nom et l'année déjà remplis, prêt à enregistrer comme fichier LICENSE. Choisissez parmi 23 licences, dont MIT, Apache 2.0 et GPL 3.0, voyez ce que chacune permet et exige, et copiez l'identifiant SPDX pour package.json.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Touchez la licence qui convient, comme MIT pour une licence simple et permissive, ou choisissez l'une des 23 de la liste.
Saisissez le titulaire des droits d'auteur ; l'année est déjà remplie.
Cliquez sur Télécharger pour enregistrer le fichier LICENSE, puis placez-le dans le dossier racine du projet.
Copiez la ligne SPDX dans package.json ou en haut de chaque fichier source si vous voulez que les outils la lisent.
Un code sans licence n'est pas open source : par défaut, le droit d'auteur ne permet à personne d'autre de le copier, de le modifier ou de le partager, même si le dépôt est public. C'est l'ajout d'un fichier LICENSE dans le dossier racine qui accorde ces droits, et le choix de la licence décide à quelles conditions.
Choisir. La question principale est ce que les autres doivent faire de leurs modifications :
| Licence | Les autres peuvent fermer leurs modifications | Licence de brevets | Modifications partagées sous la même licence |
|---|---|---|---|
| MIT | Oui | Non | Non |
| Apache 2.0 | Oui | Oui | Non |
| BSD 3-Clause | Oui | Non | Non |
| MPL 2.0 | Oui, hors des fichiers modifiés | Oui | Fichiers modifiés uniquement |
| GPL 3.0 | Non | Oui | Tout le programme |
| AGPL 3.0 | Non, même via un réseau | Oui | Tout le programme, services web compris |
MIT est le choix le plus courant pour les bibliothèques ; Apache 2.0 ajoute une licence de brevets explicite, que les grandes entreprises préfèrent souvent ; GPL 3.0 garde ouverte chaque version du programme.
Remplir. La plupart des licences permissives comportent une ligne de copyright avec une année et un nom. Saisissez le titulaire des droits d'auteur, l'année est déjà là ; une plage comme 2019-2026 fonctionne aussi. Des licences comme GPL, Apache et MPL n'ont aucune ligne à remplir en haut : le texte est utilisé exactement tel qu'il a été publié.
D'où viennent les textes. Les 23 textes sont ceux de choosealicense.com, le site qu'utilise GitHub lorsque vous ajoutez une licence à un dépôt, à un commit fixe. Chacun a été comparé mot à mot avec le texte de la SPDX License List elle-même, et au moins 95 pour cent des mots correspondent dans l'ordre ; les différences sont les titres et les notes GNU sur la manière d'appliquer la licence.
Après l'enregistrement. Placez le fichier dans le dossier racine du projet, ajoutez l'identifiant SPDX à package.json ou en haut de chaque fichier source, et indiquez dans le README quelle licence vous utilisez. Cette page ne constitue pas un conseil juridique. Tout s'exécute dans votre navigateur.
Pour la plupart des bibliothèques, MIT : courte, permissive et comprise partout. Choisissez Apache 2.0 si vous voulez une licence de brevets explicite, GPL 3.0 si chaque version modifiée doit rester open source, et AGPL 3.0 si cela doit aussi s'appliquer aux logiciels proposés comme service web. MPL 2.0 se situe entre les deux et ne s'applique qu'aux fichiers que vous avez écrits.
Les deux permettent à quiconque d'utiliser, de modifier et de vendre le code, y compris dans des produits fermés. Apache 2.0 accorde en plus une licence sur les brevets que les contributeurs détiennent sur leurs contributions, met fin à cette licence pour quiconque intente une action en matière de brevets, et demande que les fichiers modifiés indiquent qu'ils ont été modifiés. MIT tient en quelques lignes et ne dit rien des brevets.
Ce sont alors les règles par défaut du droit d'auteur qui s'appliquent : vous conservez tous les droits, et personne d'autre ne peut copier, modifier ou distribuer le code, même s'il se trouve dans un dépôt public. On peut le consulter, mais l'utiliser dans ses propres projets n'est pas autorisé. C'est l'ajout d'un fichier LICENSE qui fait du code publié un code open source.
Dans le dossier racine du projet, sous le nom LICENSE, ou COPYING pour GPL 3.0 comme le suggère GNU. GitHub et npm l'y trouvent et affichent la licence sur la page du projet. Renseignez aussi le champ license de package.json avec l'identifiant SPDX, comme MIT, et mentionnez la licence dans le README.
L'année de première publication du code, ou une plage allant de la première à la dernière année de modifications, comme 2019-2026. Mettre l'année à jour est courant mais pas obligatoire : la mention indique quand l'œuvre a été créée. Utilisez le nom de la personne ou de l'organisation titulaire des droits d'auteur, souvent l'employeur pour du code professionnel.
Vous pouvez publier de nouvelles versions sous une autre licence si vous détenez la totalité des droits d'auteur, mais les copies déjà publiées gardent la licence avec laquelle elles ont été diffusées. Si d'autres personnes ont contribué du code, il vous faut leur accord pour changer la licence de leurs parties, sauf si elles ont signé un accord de contributeur qui le permet. Bien choisir dès le départ évite cela.
Les taux et les règles changent ; vérifiez la source avant de vous fier à un chiffre.
Toujours bloqué ? Poser une question sur Générateur de licence et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.