许可证 (LPPL)

LPPL 是什么？它是 LaTeX 本体和几乎所有宏包采用的许可证。有多“几乎”？在 TeX Live 2024 的宏包台账中，申报了许可证的 4,292 条里有 2,986 条（69.6%） 采用 LPPL，远远抛开 GPL 系的 425 条（9.9%）。而人人都记得的那句关于这个许可证的话——「改了就必须改文件名」——在你硬盘上的 LPPL 1.3c 条文里一个字都找不到。本页追查这条规则去了哪里、为什么消失，以及留下来的条款究竟要求什么，每项说法都对照 TeX Live 随附的许可证原文核实。

“改了就要改文件名”出自哪一版条文

答案是 LPPL 1.2 的第 3 条，而不是现行的 1.3c。打开 TeX Live 2024 随附的 texmf-dist/doc/latex/base/lppl-1-2.txt 第 74 行，它作为分发改版文件的八项条件中的第三项赫然在目：“You must not distribute the modified file with the filename of the original file.”（不得以原文件名分发改动过的文件。）更早的 1.0 还要严格，连顺序都规定了——在做任何修改之前先改名。然而，在同一目录下检索现行的 lppl.txt（头部写着 LPPL Version 1.3c 2008-05-04）中的 “renam” 与 “filename”，结果是 0 处匹配。这条规则已经不在条文里了。

# 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

那么，当初为什么要设这样一条呢？理由至今仍写在同一目录下的 1995 年文档 modguide.tex 里，并附有实例。LaTeX 的 tools 集合中有 array.sty，1994 年末为它加入了一项新的用户级功能。于是文档可以写 \usepackage{array}[1994/10/16]，声明「需要不早于该日期的版本」。倘若别人以同一个名字发布改造过的 array，就会出现日期更新却没有该功能的文件，这条声明也就形同虚设——这正是 LaTeX Project 的论据。而且这套机制在三十年后依然有效： 在 TeX Live 2024 上索要一个不存在的日期，就会得到 LaTeX Warning: You have requested, on input line 3, version ... but only version ... is available.。对 TeX 来说，文件名是面向用户的语法的一部分。

为什么 1.3 改了条文：2003 年的 Debian 之争

直接的导火索是 Debian 在 2003 年考虑把 LaTeX 移出主发行版。争议焦点正是那条文件名条款：「不得以原名分发改版」是否符合 Debian 自由软件指导方针（DFSG），在 debian-legal 邮件列表上被长时间辩论。自由软件基金会的立场同样微妙。FSF 认为 LPPL 1.2 是自由许可证但与 GPL 不兼容，并判定改名要求只是勉强落在可接受的一侧。它给出的接受理由很有启发：TeX 拥有文件名重映射机制——可以配置成「请求 foo 时改用 bar」——所以改名只是麻烦，而非障碍。FSF 还补充说，若把同样的条件搬到没有该机制的系统上，软件就会变得不自由。这场争论的结果是 LPPL 1.3 于 2003 年 12 月 1 日发布，文件名条款从中消失。

1.3c 究竟要求什么：第 6 条的四项义务

1.3c 的正文由 12 条构成，其中真正与改动者相关的几乎只有 第 6 条。结构如下：第 1 至 3 条涉及使用和未改动的分发；第 4 条规定「若你是 Current Maintainer，可自由修改和分发」；第 5 条规定「即使不是，也可以在本地修改」；而 第 6 条规定「非 Current Maintainer 分发改版时的条件」——其下列出 a 到 d 四项。关键是 6a：当原始组件与 Base Interpreter（对 LaTeX 作品而言即 LaTeX 格式）一同交互运行、并向用户报出自己身份时，替换组件必须清楚且毫不含糊地表明自己是修改版。换言之，要求已从「改名」变成了「别让人认错」。

那么改名是不是就不必了？实务上仍以改名为正道，只是依据在于 modguide.tex 而非许可证本身。该文档明确请求：若你改良了某个类或宏包，请给它另起一个名字，并给出最简单的做法——把 \documentclass{article} 换成 \documentclass{myart}。因此今天的局面可以这样概括：改名不是义务，但它是满足 6a 最稳妥、最无争议的办法。 如果你打算 fork 之后放上 CTAN，请毫不犹豫地改名。反之，若只是把公司内部的类改一改自用，那根本谈不上分发，第 6 条也就不会触发——不过要注意，1.3c 对「分发」采取宽泛立场，明确写道把文件放在共享文件系统上也算分发。

maintainer 与 Current Maintainer 的区别：接手无人维护宏包的途径

Current Maintainer 是职位，maintained 是状态——混淆二者，条文就读不通了。按 1.3c 的定义节，Current Maintainer 指「在作品内被指定担任此职的人」；若未作明确指定，则由版权持有者兼任。它是一个头衔，而且依第 4 条，这是唯一可以自由修改和再分发的身份。相对地，maintained / author-maintained / unmaintained 描述的是作品本身的维护状态，写在作品内部作为声明。作品处于 maintained，意味着 Current Maintainer 表明了「愿意接收错误报告」（例如留下有效的邮箱地址）。但并没有义务回复这些报告。声明 author-maintained 则表示只有作者可以维护，同时也关闭了下文所述的接手程序。

对于已进入 unmaintained 的作品，许可证把交接程序写成了条文。(1) 通过网络搜索等方式合理地寻找现 Current Maintainer（若与版权持有者不是同一人，也一并寻找）。(2) 找到后询问是否仍在维护；若是，请其在 1 个月内更新联系方式。(3) 若寻找失败或没有回应，就在相关社区宣布自己接手维护的意向。(4) 若在该宣布之后 3 个月内，原维护者、版权持有者以及任何其他人都未提出异议，你便可以修改作品，把自己写为新的 Current Maintainer。(5) 但若原本联系不上的维护者在变更后 3 个月内重新出现并提出要求，该职位便归还于他。现成的例子就在手边：查看多语言宏包 babel 的文件头，可见版权 1989–2012 年归 Johannes Braams，2012–2024 年归 Javier Bezos 与 Braams，并明确写着 当前的 Current Maintainer 是 Javier Bezos。

要给自己的宏包加上 LPPL，该写些什么

要以 LPPL 发布自己的 .sty 或 .cls，需要的只是每个文件开头的几行说明，归结为 四个要素。(1) 版权行：你的名字，以及写作年份或最后一次大幅修改的年份。(2) 声明按 「1.3 版或（由你选择）任何后续版本」 授权。(3) 维护状态（选 maintained 是常规做法）以及 Current Maintainer 的姓名。(4) 列出哪些文件构成「作品」。最后一点最容易被忽略，但条文要求分发时必须包含作品的全部文件，若作者不说明什么是作品，接收方就无从判断。文件较多时，写一行 % This work consists of all files listed in manifest.txt. 也是公认的做法。另外，LPPL 并非公有领域：代码可以自由使用，但上述标示义务与第 6 条依然成立。

%% 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.

最后梳理一下它与其他许可证的关系。LPPL 1.3c 于 2009 年 11 月 11 日获 OSI 认证，符合 Debian 的 DFSG，FSF 也承认其为自由许可证。尽管如此，它仍与 GPL 不兼容——原因并不是「必须表明自己是修改版」（许多讲解在此弄错了），而是 第 6 条 d：分发改版时必须随附原作的完整未改动副本或其获取方式，这对 GPL 而言属于不被允许的附加条件。因此，LPPL 的代码无法并入 GPL 项目。反过来看，TeX 圈里也并非全是 LPPL。例如在多语言宏包中，babel 采用 LPPL，而 polyglossia 使用 MIT 许可证。养成阅读许可证字段的习惯，在挑选宏包时同样有用。