Licence (LPPL)

La LPPL est la licence qu’emploient LaTeX lui-même et presque tous les packages. À quel point presque ? Sur les 4 292 entrées de la base de packages de TeX Live 2024 qui déclarent une licence, 2 986 — soit 69,6 % — déclarent une version de la LPPL, contre 425 (9,9 %) pour la famille GPL. Or la seule phrase que tout le monde retient de cette licence — qu’un fichier modifié doit être renommé — ne figure nulle part dans la LPPL 1.3c présente sur votre disque. Cette page suit la trace de cette règle : où elle est passée, pourquoi elle a disparu, et ce que les clauses subsistantes exigent réellement, chaque affirmation étant vérifiée sur le texte livré avec TeX Live.

Quelle version dit réellement « renommez le fichier modifié »

La réponse est la clause 3 de la LPPL 1.2, et non la 1.3c actuelle. Ouvrez la ligne 74 de texmf-dist/doc/latex/base/lppl-1-2.txt, livré avec TeX Live 2024 : elle y figure comme troisième des huit conditions de diffusion d’un fichier modifié — « You must not distribute the modified file with the filename of the original file. » La 1.0, plus ancienne, était plus stricte encore et fixait jusqu’à l’ordre des opérations : renommer le fichier avant toute modification. Or, si l’on cherche « renam » ou « filename » dans le lppl.txt actuel du même répertoire, celui dont l’en-tête indique LPPL Version 1.3c 2008-05-04, on obtient zéro occurrence. La règle ne figure tout simplement plus dans la licence.

# TeX Live 2024 ships every version of the licence side by side.
$ cd texmf-dist/doc/latex/base
$ grep -c -iE "renam|filename" lppl-1-2.txt   # LPPL 1.2, 1999-09-03
7
$ grep -c -iE "renam|filename" lppl.txt       # LPPL 1.3c, 2008-05-04
0

Pourquoi imposer une telle condition au départ ? Le raisonnement figure toujours, exemple à l’appui, dans modguide.tex, un document de 1995 rangé dans le même répertoire. La collection « tools » de LaTeX contient array.sty, auquel une nouvelle fonctionnalité utilisateur a été ajoutée fin 1994. Un document peut donc écrire \usepackage{array}[1994/10/16] pour déclarer qu’il lui faut une version pas plus ancienne que cette date. Si quelqu’un diffusait un array modifié sous le même nom, il circulerait des fichiers portant une date plus récente mais dépourvus de la fonctionnalité, et la déclaration ne vaudrait plus rien. Tel était l’argument du LaTeX Project. Et le mécanisme fonctionne encore trente ans plus tard : demandez à TeX Live 2024 une date inexistante et vous obtenez LaTeX Warning: You have requested, on input line 3, version ... but only version ... is available. Dans TeX, un nom de fichier fait partie de la syntaxe visible par l’utilisateur.

Pourquoi la clause a changé en 1.3 : la querelle Debian de 2003

Le déclencheur immédiat fut Debian, qui en 2003 envisagea de retirer LaTeX de sa distribution principale. Le point d’achoppement était précisément cette clause de nom de fichier : la compatibilité de « vous ne pouvez pas diffuser une version modifiée sous le nom d’origine » avec les Debian Free Software Guidelines fut longuement débattue sur la liste debian-legal. La position de la Free Software Foundation était elle aussi finement pesée. Elle qualifiait la LPPL 1.2 de licence libre mais incompatible avec la GPL, et jugeait l’obligation de renommage tout juste du bon côté de la limite acceptable. Sa raison est éclairante : TeX dispose d’un mécanisme de réécriture des noms de fichiers — on peut lui dire d’utiliser bar chaque fois que foo est demandé —, si bien que renommer est une gêne et non un obstacle. Transplantez la même condition dans un système dépourvu de ce mécanisme, ajoutait la FSF, et elle rendrait le logiciel non libre. De cette controverse est sortie la LPPL 1.3, publiée le 1er décembre 2003, dont la clause de nom de fichier avait disparu.

Ce qu’exige réellement la 1.3c : les quatre devoirs de la clause 6

Le corps de la 1.3c compte douze clauses, et une seule — la clause 6 — concerne vraiment celui qui modifie un package. Voici la structure. Les clauses 1 à 3 traitent de l’usage et de la diffusion sans modification ; la clause 4 dit que le Current Maintainer peut modifier et diffuser librement ; la clause 5 autorise quiconque à modifier sa propre copie ; et la clause 6 fixe les conditions de diffusion d’une version modifiée par un non-mainteneur — quatre conditions, de a à d. Le pivot est la 6a : partout où le composant d’origine s’annonce à l’utilisateur lors d’une exécution interactive avec le Base Interpreter (pour une œuvre LaTeX, un format LaTeX), le composant de remplacement doit s’identifier clairement et sans ambiguïté comme une version modifiée. L’exigence est donc passée de « renommez » à « rendez la confusion impossible ».

Renommer n’est donc plus obligatoire — mais reste en pratique le bon geste, et l’autorité en la matière est modguide.tex, non la licence. Ce document demande explicitement de donner un autre nom à une classe ou à un package qu’on a amélioré, et signale la solution la plus simple : remplacer \documentclass{article} par \documentclass{myart}. La situation actuelle se résume donc ainsi : renommer n’est pas une obligation, mais c’est la façon la plus sûre et la moins discutable de satisfaire la 6a. Si vous comptez forker et déposer sur CTAN, renommez sans hésiter. À l’inverse, si vous retouchez une classe maison pour votre seul usage interne, vous ne diffusez rien et la clause 6 ne s’applique pas — sachant que la 1.3c retient une acception large de la « distribution » et précise que déposer des fichiers sur un système de fichiers partagé en relève.

Maintainer et Current Maintainer : comment un package abandonné change de mains

Current Maintainer est une fonction, maintained un état — confondre les deux rend la licence illisible. Selon les définitions de la 1.3c, le Current Maintainer est la personne désignée comme telle dans l’œuvre ; à défaut de désignation explicite, le titulaire des droits occupe la fonction. C’est un titre, et la clause 4 en fait la seule position depuis laquelle on peut modifier et rediffuser librement. Les mots maintained, author-maintained et unmaintained décrivent au contraire le statut de maintenance de l’œuvre elle-même, déclaré à l’intérieur de celle-ci. Une œuvre est maintained lorsque le Current Maintainer indique accepter les rapports d’erreur — en fournissant par exemple une adresse électronique valide. Rien ne l’oblige à y répondre. Déclarer author-maintained signifie que seul l’auteur peut maintenir l’œuvre, et désactive la procédure de reprise décrite plus bas.

Pour une œuvre devenue unmaintained, la licence détaille la procédure de reprise. (1) Tenter raisonnablement, par une recherche en ligne ou équivalente, de retrouver le Current Maintainer — et le titulaire des droits s’il s’agit d’une autre personne. (2) S’il est retrouvé, lui demander si l’œuvre est encore maintenue ; dans l’affirmative, lui demander de mettre à jour ses coordonnées sous un mois. (3) Si la recherche échoue ou reste sans suite, annoncer dans la communauté concernée son intention de reprendre la maintenance. (4) Si, trois mois après cette annonce, ni le mainteneur, ni le titulaire des droits, ni personne d’autre ne s’y oppose, on peut faire modifier l’œuvre pour s’y désigner comme nouveau Current Maintainer. (5) Mais si le mainteneur jusque-là injoignable réapparaît dans les trois mois suivant le changement et le demande, la fonction lui revient. Un exemple vivant est à portée de main : l’en-tête du package multilingue babel porte un copyright 1989-2012 à Johannes Braams et 2012-2024 à Javier Bezos et Braams, avec Javier Bezos nommé Current Maintainer.

Que faut-il écrire pour placer son package sous LPPL

Pour publier votre propre .sty ou .cls sous LPPL, il suffit d’une courte notice en tête de chaque fichier, qui tient en quatre éléments. (1) Une ligne de copyright avec votre nom et l’année de rédaction ou de dernière révision substantielle. (2) La mention que l’œuvre est placée sous la version 1.3 ou, à votre choix, toute version ultérieure. (3) Le statut de maintenance — choisir maintained — et le nom du Current Maintainer. (4) La liste des fichiers qui constituent l’œuvre. C’est ce dernier point qu’on oublie, alors que la licence exige que toute distribution comporte l’ensemble des fichiers de l’œuvre : si l’auteur ne dit pas ce qu’est l’œuvre, le destinataire ne peut pas le deviner. Avec beaucoup de fichiers, la ligne unique % This work consists of all files listed in manifest.txt. est une issue admise. Enfin, la LPPL n’est pas le domaine public : le code s’utilise librement, mais les obligations de mention ci-dessus et la clause 6 demeurent.

%% mypkg.sty
%% Copyright 2026 M. Y. Name
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3
% of this license or (at your option) any later version.
% The latest version of this license is in
%   https://www.latex-project.org/lppl.txt
% and version 1.3 or later is part of all distributions of LaTeX
% version 2005/12/01 or later.
%
% This work has the LPPL maintenance status 'maintained'.
%
% The Current Maintainer of this work is M. Y. Name.
%
% This work consists of the files mypkg.dtx and mypkg.ins
% and the derived file mypkg.sty.

Enfin, sa place parmi les autres licences. La LPPL 1.3c a été approuvée par l’OSI le 11 novembre 2009, elle satisfait les DFSG de Debian, et la FSF la reconnaît comme libre. Elle reste pourtant incompatible avec la GPL — non pas à cause de l’obligation de se déclarer modifié, comme le prétendent beaucoup d’exposés, mais à cause de la clause 6d : l’obligation de fournir une copie complète et non modifiée de l’original, ou le moyen de l’obtenir, est une condition supplémentaire que la GPL n’autorise pas. Du code LPPL ne peut donc pas être absorbé par un projet GPL. Dans l’autre sens, le monde TeX n’est pas uniformément LPPL. Parmi les packages multilingues, babel est sous LPPL tandis que polyglossia relève de la licence MIT. Prendre l’habitude de lire le champ « licence » sert aussi au moment de choisir un package.