The LPPL is the licence used by LaTeX itself and by almost every package. How nearly every? Of the 4,292 entries in the TeX Live 2024 package database that declare a licence, 2,986 — 69.6% — declare some version of the LPPL, against 425 (9.9%) for the GPL family. And the one sentence everybody remembers about this licence — that a modified file must be renamed — appears nowhere in the LPPL 1.3c sitting on your disk. This page follows where that rule went, why it went, and what the surviving clauses actually require, checking each claim against the licence text shipped with TeX Live.
Which version actually says “rename the modified file”
The answer is clause 3 of LPPL 1.2, not the current 1.3c. Open line 74 of texmf-dist/doc/latex/base/lppl-1-2.txt, shipped with TeX Live 2024, and there it is as the third of the eight conditions for distributing a modified file: “You must not distribute the modified file with the filename of the original file.” The older 1.0 was stricter still, specifying the order of operations — rename the file before you make any changes. Yet search the current lppl.txt in that same directory — the one whose header reads LPPL Version 1.3c 2008-05-04 — for “renam” or “filename”, and you get zero matches. The rule is simply no longer in the 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
0Why impose such a condition in the first place? The reasoning is still there, with a worked example, in modguide.tex — a 1995 document sitting in the same directory. The LaTeX tools collection contains array.sty, and a new user-level feature was added to it at the end of 1994. A document can therefore write \usepackage{array}[1994/10/16] to declare that it needs a version no older than that date. If somebody else shipped a modified array under the same name, files would circulate that carry a later date but lack the feature, and the declaration would be worthless. That was the LaTeX Project’s argument. And the mechanism still works three decades later: ask TeX Live 2024 for a date that does not exist and you get LaTeX Warning: You have requested, on input line 3, version ... but only version ... is available. A filename, in TeX, is part of the user-facing syntax.
Why the clause changed in 1.3: the Debian argument of 2003
The immediate trigger was Debian, which in 2003 considered dropping LaTeX from its main distribution. The sticking point was precisely that filename clause: whether “you may not ship a modified version under the original name” could be squared with the Debian Free Software Guidelines was argued at length on the debian-legal list. The Free Software Foundation’s position was finely balanced too. It called LPPL 1.2 a free licence but incompatible with the GPL, and judged the renaming requirement to fall only just on the acceptable side of the line. Its stated reason for accepting it is illuminating: TeX has a facility for remapping filenames — you can configure it to use bar whenever foo is requested — so renaming is an annoyance rather than an obstacle. Transplant the same condition into a system without that facility, the FSF added, and it would make the software non-free. Out of that argument came LPPL 1.3, released on 1 December 2003, from which the filename clause had vanished.
| Version | Release date, and what it demanded |
|---|---|
1.0 | 1999-03-01. Rename the file before making any changes: even the order was prescribed |
1.1 | 1999-07-10. An interim revision that tidied up the details of 1.0 |
1.2 | 1999-09-03. The filename clause sits at clause 3. Three versions appeared in 1999 alone |
1.3 | 2003-12-01. The filename clause is gone, replaced by clause 6a: identify yourself as modified |
1.3c | 2008-05-04. The current text. It differs from 1.3, 1.3a and 1.3b only in small clarifications; SPDX id LPPL-1.3c |
What 1.3c actually requires: the four duties of clause 6
The body of 1.3c consists of twelve clauses, and only one of them — clause 6 — really concerns anyone modifying a package. The shape is this. Clauses 1 to 3 cover use and unmodified distribution; clause 4 says that if you are the Current Maintainer you may modify and distribute freely; clause 5 says that even if you are not, you may modify your own copy; and clause 6 sets the conditions for distributing a modified version when you are not the Current Maintainer — four of them, a through d. The pivot is 6a: wherever the original component identifies itself to the user when run interactively with the Base Interpreter (for a LaTeX work, that means a LaTeX format), the replacement component must clearly and unambiguously identify itself as a modified version. The demand, in other words, changed from “rename it” to “make it impossible to mistake”.
| Clause | What it obliges you to do |
|---|---|
6a | If the modified component can stand in for the original, it must clearly and unambiguously announce itself as modified when run interactively |
6b | Carry prominent notices describing the changes, or a prominent pointer to a changelog distributed with the work |
6c | Say nothing that implies the original authors support the derived work, unless they have said so themselves |
6d | Ship a complete unmodified copy of the original work, or the information needed to get one. This clause is the reason the licence is GPL-incompatible |
10a | A derived work may be distributed under a different licence, provided that licence itself honours the conditions of clause 6 |
So renaming is no longer required — yet in practice it remains the right move, and the authority for that is modguide.tex, not the licence. That document asks outright that you give an improved class or package some other name, and points out the simplest possible fix: replace \documentclass{article} with \documentclass{myart}. The situation today is therefore best stated as follows: renaming is not an obligation, but it is the surest and least arguable way to satisfy 6a. If you intend to fork something and put it on CTAN, rename it without hesitating. Conversely, if you tweak a house class and use it only inside your own group, you are not distributing at all and clause 6 never fires — though note that 1.3c takes a broad view of “distribution” and states that putting files on a shared file system counts.
Maintainer vs Current Maintainer: how an abandoned package changes hands
Current Maintainer is a post; maintained is a state — confuse the two and the licence stops making sense. By the definitions in 1.3c, the Current Maintainer is the person nominated as such within the work, and where no such nomination is made, the copyright holder holds the post by default. It is a title, and clause 4 makes it the one position from which you may modify and redistribute freely. The words maintained, author-maintained and unmaintained, by contrast, describe the maintenance status of the work itself, declared inside the work. A work is maintained when the Current Maintainer has indicated a willingness to receive error reports — by supplying a working e-mail address, say. Nothing obliges them to answer those reports. Declaring author-maintained means only the author may maintain it, and switches off the takeover procedure described below.
| Status | Definition, and how many declare it in TeX Live 2024 |
|---|---|
maintained | The Current Maintainer has indicated a willingness to receive error reports. 1,261 .sty files declare it |
author-maintained | Only the author may maintain it; the takeover procedure does not apply. 105 files. The licence itself recommends maintained instead |
unmaintained | No maintainer, or unreachable for six months with no sign of activity. 17 files declare themselves unmaintained outright |
For a work that has become unmaintained, the licence spells out the handover procedure. (1) Make a reasonable attempt, by internet search or similar, to trace the Current Maintainer — and the copyright holder if that is a different person. (2) If you find them, ask whether the work is still maintained; if it is, ask them to update their contact details within one month. (3) If the search fails, or nothing happens, announce your intention to take over maintenance in the pertinent community. (4) If, three months after that announcement, neither the maintainer nor the copyright holder nor anyone else has challenged you, you may have the work amended to name you as the new Current Maintainer. (5) But if the previously unreachable maintainer resurfaces within three months of the change and asks, the post returns to them. A live example is close at hand: look at the header of the multilingual package babel and you find copyright 1989–2012 to Johannes Braams and 2012–2024 to Javier Bezos and Braams, with the Current Maintainer named as Javier Bezos.
What to write to put your own package under the LPPL
To release your own .sty or .cls under the LPPL, all you need is a short notice at the top of each file, and it comes down to four elements. (1) A copyright line with your name and the year the work was written or last substantially revised. (2) A statement that it is licensed under version 1.3 or, at your option, any later version. (3) The maintenance status — choose maintained — and the name of the Current Maintainer. (4) A list of which files constitute the Work. That last point is the one people forget, but the licence requires that distributions carry all the files of the Work, so unless the author says what the Work is, a recipient cannot tell. If there are many files, the single line % This work consists of all files listed in manifest.txt. is an accepted escape hatch. Note also that the LPPL is not the public domain: you may use the code freely, but the notice duties above and clause 6 remain.
%% 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.Finally, where the LPPL sits among other licences. LPPL 1.3c was approved by the OSI on 11 November 2009, it satisfies Debian’s DFSG, and the FSF recognises it as free. It is nonetheless incompatible with the GPL — and the reason is not the “identify yourself as modified” rule, which many explanations get wrong, but clause 6d: the requirement to ship a complete unmodified copy of the original, or the means of getting one, is an extra condition the GPL does not allow. LPPL code therefore cannot be absorbed into a GPL project. In the other direction, the TeX world is not uniformly LPPL. Among the multilingual packages, for instance, babel is LPPL while polyglossia is under the MIT licence. Getting into the habit of reading the licence field pays off when choosing packages, too.