LicenseKit

Devant un dépôt vide, il y a toujours ce moment où il faut choisir une licence. On sait vaguement que MIT est permissive et que la GPL oblige à quelque chose, on copie ce qu’on a vu ailleurs, et on passe à autre chose. Les outils que je connaissais généraient bien un fichier LICENSE, mais aucun ne m’expliquait ce que je venais de signer.

Il y avait aussi une envie plus perso. J’ai téléchargé des centaines d’outils comme celui-là, et j’avais toujours voulu essayer d’en faire un, que n’importe qui puisse lancer en une commande.

LicenseKit est parti de là. C’est un outil en ligne de commande qui aide à choisir une licence, à la comprendre et à l’ajouter à son projet. Il se lance sans rien installer :

npx @drosscend/licensekit

Comprendre avant de choisir

Pour chaque licence, l’outil dit ce qu’elle permet, ce qu’elle exige et ce qu’elle exclut, en quelques mots plutôt qu’en jargon juridique. Pour MIT, avec info mit, ça donne ça :

L’interface parle français ou anglais, selon la langue du système ou l’option --lang. Seul le résumé de la licence reste en anglais, tel que GitHub le fournit.

La commande compare met deux licences côte à côte. MIT et la GPL-3.0 autorisent toutes les deux l’usage commercial, mais seule la GPL oblige à documenter ses modifications et à redistribuer sous la même licence.

Un assistant qui donne mon avis

Lancé sans argument, l’outil passe en mode guidé. Il pose quelques questions sur le projet (son type, l’usage commercial, le copyleft, les brevets) et affiche les licences les mieux classées. Pour celle qu’on choisit, il écrit le fichier LICENSE avec l’année en cours et le nom de l’auteur, qu’il va chercher dans la configuration Git, puis il propose de mettre à jour le champ license du package.json.

Derrière le classement, il n’y a rien d’intelligent. C’est un tableau de points écrit à la main, où chaque réponse ajoute ou retire des points à certaines licences. Répondre « une librairie ou un framework » favorise MIT, Apache et les BSD, « un produit commercial » retire deux points aux GPL, et « de la documentation » fait remonter CC0.

Ce sont donc mes convictions transformées en points, et je préfère le dire. L’outil aide à comprendre et à faire un premier tri, mais il ne remplace pas un avis juridique.

Ce qu’il y a dedans

Les textes des licences ne sont pas recopiés à la main. Un script les récupère sur l’API de GitHub, avec leurs droits et leurs obligations, et les range dans le paquet, donc l’outil marche hors ligne. Seul le classement par famille (permissive, copyleft, copyleft faible, domaine public) est fait à la main, parce que GitHub ne le donne pas.

Pour le reste, il n’y a que trois dépendances : commander pour les arguments, @clack/prompts pour les questions et picocolors pour la couleur. Avec npx, tout se télécharge au premier lancement, avant même la première question, donc je voulais en avoir le moins possible.

Mon premier paquet npm

Je l’ai écrit avec Claude Code, en deux soirées de février. C’était mon premier paquet npm, et la publication m’a appris autant que le code.

Le nom, d’abord. license-kit existait déjà, et npm refuse un nouveau nom qui n’en diffère que par la ponctuation. D’où le paquet à mon nom, @drosscend/licensekit.

Le premier soir, je l’ai publié dès qu’il a marché. Sauf qu’il ne se lançait qu’avec Bun installé, parce que son fichier de démarrage commençait par #!/usr/bin/env bun. Or ceux qui passent par npx ont Node, pas forcément Bun. La version corrigée est partie quelques minutes plus tard.

Le lendemain soir, j’ai voulu que la publication se fasse toute seule. Il suffit maintenant de poser un tag de version, et GitHub Actions publie le paquet si les vérifications passent.

Il m’a fallu cinq essais pour y arriver. Avec un jeton classique, npm réclamait un code de double authentification, qu’une CI ne peut pas taper. Je suis passé à la publication par OIDC, le trusted publishing de npm. GitHub prouve à npm que c’est bien ce dépôt qui publie, et il n’y a plus aucun jeton à garder quelque part, donc rien qui puisse fuiter. Et il fallait encore un npm assez récent. Avec Node 20, il répondait juste un 404, et avec Node 24, c’est passé. Depuis, chaque version porte aussi une attestation de provenance, qui la relie au commit d’où elle sort.

Le CLAUDE.md du dépôt explique à Claude la marche à suivre : vérifier, monter la version, poser le tag et pousser. La CI fait le reste.

Cinq mois plus tard

En juillet, j’ai demandé à Claude des captures du terminal pour cet article. Sur celle de la comparaison, toutes les limitations étaient vides, alors que chaque licence limite au moins la responsabilité et la garantie. GitHub appelle ces limites liability et warranty, et le code attendait no-liability et no-warranty. La fiche d’une licence passait par une table d’équivalences, la comparaison l’avait oubliée. Claude a aussi vu que --version affichait 0.1.1 alors que npm en était à la 0.1.3, parce que le numéro était écrit à la main. La capture plus haut est celle d’après la correction.

J’ai fait corriger les deux et publier une 0.1.4. La publication a échoué, sur du code qui n’avait pas bougé depuis février. La CI appelait TypeScript sans que sa version soit déclarée dans le projet, donc elle prenait la dernière. Entre-temps, TypeScript 7 était sorti, et il ne charge plus tout seul les types de Node. Sans eux, il ne savait plus que process.exit() arrête le programme, et il voyait des erreurs dans tout le code qui comptait dessus. J’ai fait passer toutes les dépendances à leur dernière version, TypeScript 7 compris, avec les types de Node déclarés, et la 0.1.4 est partie.

Où en est le projet

Il est publié et il marche, mais je ne m’en sers pas vraiment. En octobre, en vérifiant cet article, Claude a trouvé deux autres étiquettes de GitHub mal lues, et le français n’avait aucun accent. J’ai tout fait corriger dans la 0.1.6. Il vit sa vie sur npm, avec une vingtaine de téléchargements par mois.