ライセンス（LPPL）

LPPL とは、LaTeX 本体とほとんどのパッケージが使っているライセンスです。どれくらい「ほとんど」かというと、TeX Live 2024 のパッケージ台帳でライセンスを申告している 4,292 件のうち 2,986 件（69.6%） が LPPL——GPL 系の 425 件（9.9%）を大きく引き離しています。そして、このライセンスについて誰もが覚えている一文——「改変したらファイル名を変えなければならない」——は、いま手元にある LPPL 1.3c の条文には一語も入っていません。「latex ライセンス 改変」で調べると今も出てくるこの規則がどこへ消えたのか、なぜ消えたのか、そして残った条文が実際に何を要求しているのかを、TeX Live 同梱の原文で確かめていきます。

「改変したらファイル名を変える」はどの版の条文か

答えは LPPL 1.2 の第 3 条で、現行の 1.3c ではありません。TeX Live 2024 に同梱されている texmf-dist/doc/latex/base/lppl-1-2.txt の 74 行目を開くと、改変版を配ってよい 8 条件のうち 3 番目として "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

では、なぜそんな条件が最初にあったのか。理由は modguide.tex（同じディレクトリにある 1995 年の文書）に、いまも具体例つきで書かれています。LaTeX の tools コレクションに array.sty があり、1994 年末に新しい機能が追加されました。そこで文書側は \usepackage{array}[1994/10/16] と書いて「この日付以降の版が必要だ」と宣言できます。もし別人が改造版の array を同じ名前で配ったら、日付だけ新しくて機能のないファイルが出回り、この宣言は無意味になる——というのが LaTeX Project の主張でした。そしてこの仕掛けは 30 年後の今も動きます。 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 のメーリングリスト上で長く議論されます。フリーソフトウェア財団の見解も微妙で、LPPL 1.2 について FSF は「自由ではあるが GPL とは非互換」とし、改名要求は辛うじて許容できる側に落ちる、と評しました。許容できる理由として FSF が挙げたのが、TeX にはファイル名を読み替える仕組みがあるという点です——つまり「foo を要求されたら bar を使え」と設定できるので、改名は面倒ではあっても致命的ではない。裏返せば、その仕組みがない世界に同じ条件を移植したら不自由になる、とも書いています。この議論を経て、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 を満たす最も確実で議論の余地のない方法。フォークして 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 か月以内に現れて要求すれば、その人が Current Maintainer に戻ります。この仕組みが実際に動いた例は身近にあります——多言語パッケージ babel のヘッダを見ると、著作権表記は 1989〜2012 年が Johannes Braams、2012〜2024 年が Javier Bezos と Braams で、現在の Current Maintainer は Javier Bezos と明記されています。

自分のパッケージに LPPL を付けるには何を書けばよいか

自作の .sty や .cls を LPPL で公開するのに必要なのは、各ファイルの先頭に置く数行の注記だけで、四つの要素を書けば揃います。(1) 著作権表示（自分の名前と、書いた年または最後に大きく手を入れた年）、(2) 「1.3 またはそれ以降の版」でライセンスすること、(3) 保守状態（maintained を選ぶのが定石）と Current Maintainer の名前、(4) どのファイルが「作品」を構成するかの列挙。最後の (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 は OSI に 2009 年 11 月 11 日付で承認され、Debian の DFSG にも適合し、FSF も自由なライセンスと認めています。それでも GPL とは非互換で、その理由は「改変版だと名乗れ」ではなく——ここを取り違えている解説が多い——第 6 条 d、すなわち「改変版を配るなら未改変の完全なコピーか、その入手方法を添えよ」という条件が、GPL の許さない追加条件にあたるからです。したがって、LPPL のコードを GPL のプロジェクトに取り込むことはできません。逆に、TeX まわりでも LPPL 以外は珍しくありません。たとえば多言語パッケージのうち babel は LPPL ですが、polyglossia は MIT ライセンスです。ライセンス欄を読む習慣は、パッケージを選ぶときにも役に立ちます。