Lizenzierung (LPPL)

Die LPPL ist die Lizenz, unter der LaTeX selbst und nahezu jedes Paket stehen. Wie nahezu? Von den 4.292 Einträgen der Paketdatenbank von TeX Live 2024, die eine Lizenz angeben, nennen 2.986 – also 69,6 % – eine Fassung der LPPL, gegenüber 425 (9,9 %) für die GPL-Familie. Und der eine Satz, den alle über diese Lizenz erinnern – dass eine veränderte Datei umbenannt werden muss –, steht in der LPPL 1.3c auf der eigenen Festplatte an keiner einzigen Stelle. Diese Seite verfolgt, wohin diese Regel verschwunden ist, warum sie verschwand und was die verbliebenen Klauseln tatsächlich verlangen – jede Behauptung geprüft am Lizenztext, den TeX Live mitliefert.

In welcher Fassung steht wirklich „veränderte Datei umbenennen“

Die Antwort lautet Klausel 3 der LPPL 1.2, nicht die aktuelle 1.3c. Zeile 74 von texmf-dist/doc/latex/base/lppl-1-2.txt, mitgeliefert von TeX Live 2024, führt sie als dritte der acht Bedingungen für die Verbreitung einer veränderten Datei: „You must not distribute the modified file with the filename of the original file.“ Die ältere 1.0 war noch strenger und schrieb sogar die Reihenfolge vor – die Datei vor jeder Änderung umbenennen. Sucht man dagegen im aktuellen lppl.txt desselben Verzeichnisses, dessen Kopfzeile LPPL Version 1.3c 2008-05-04 lautet, nach „renam“ oder „filename“, ergibt das null Treffer. Die Regel steht schlicht nicht mehr in der Lizenz.

# 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

Warum überhaupt eine solche Bedingung? Die Begründung steht mitsamt Beispiel bis heute in modguide.tex, einem Dokument von 1995 im selben Verzeichnis. Die LaTeX-Sammlung „tools“ enthält array.sty, dem Ende 1994 eine neue Funktion auf Anwenderebene hinzugefügt wurde. Ein Dokument kann daher \usepackage{array}[1994/10/16] schreiben und damit erklären, es brauche eine Fassung, die nicht älter ist als dieses Datum. Verteilte jemand ein verändertes array unter demselben Namen, kämen Dateien in Umlauf, die ein späteres Datum tragen, aber die Funktion nicht besitzen – und die Erklärung wäre wertlos. So lautete das Argument des LaTeX Project. Und der Mechanismus funktioniert drei Jahrzehnte später noch: Verlangt man von TeX Live 2024 ein nicht existierendes Datum, erscheint LaTeX Warning: You have requested, on input line 3, version ... but only version ... is available. Ein Dateiname ist in TeX Teil der Syntax, die Anwender sehen.

Warum sich die Klausel in 1.3 änderte: der Debian-Streit von 2003

Der unmittelbare Anlass war Debian, das 2003 erwog, LaTeX aus seiner Hauptdistribution zu entfernen. Der Streitpunkt war genau jene Filename-Klausel: Ob „du darfst eine veränderte Fassung nicht unter dem ursprünglichen Namen verbreiten“ mit den Debian Free Software Guidelines vereinbar sei, wurde auf der Liste debian-legal ausführlich diskutiert. Auch die Position der Free Software Foundation war fein abgewogen. Sie nannte die LPPL 1.2 frei, aber unvereinbar mit der GPL, und beurteilte die Umbenennungspflicht als gerade noch auf der akzeptablen Seite der Grenze liegend. Ihre Begründung ist aufschlussreich: TeX besitzt eine Einrichtung zum Umlenken von Dateinamen – man kann festlegen, dass bar benutzt wird, wann immer foo angefordert wird –, sodass Umbenennen lästig, aber kein Hindernis ist. Verpflanze man dieselbe Bedingung in ein System ohne diese Einrichtung, ergänzte die FSF, mache sie die Software unfrei. Aus dieser Auseinandersetzung ging die LPPL 1.3 hervor, veröffentlicht am 1. Dezember 2003, in der die Filename-Klausel fehlte.

Was 1.3c wirklich verlangt: die vier Pflichten aus Klausel 6

Der Hauptteil der 1.3c besteht aus zwölf Klauseln, und nur eine davon – Klausel 6 – betrifft wirklich, wer ein Paket verändert. Der Aufbau: Klauseln 1 bis 3 regeln Nutzung und unveränderte Weitergabe; Klausel 4 besagt, dass der Current Maintainer frei ändern und verteilen darf; Klausel 5 erlaubt auch allen anderen, ihre eigene Kopie zu ändern; und Klausel 6 stellt die Bedingungen für die Verbreitung einer veränderten Fassung durch Nicht-Maintainer – vier davon, a bis d. Der Angelpunkt ist 6a: Überall dort, wo sich die ursprüngliche Komponente beim interaktiven Lauf mit dem Base Interpreter (bei einem LaTeX-Werk also einem LaTeX-Format) gegenüber der nutzenden Person zu erkennen gibt, muss die Ersatzkomponente sich klar und eindeutig als veränderte Fassung zu erkennen geben. Die Forderung wechselte also von „benenne es um“ zu „mache eine Verwechslung unmöglich“.

Ist Umbenennen also überflüssig? In der Praxis bleibt es der richtige Schritt – doch die Grundlage dafür liefert modguide.tex, nicht die Lizenz. Dieses Dokument bittet ausdrücklich darum, einer verbesserten Klasse oder einem verbesserten Paket einen anderen Namen zu geben, und nennt die einfachste Lösung: \documentclass{article} durch \documentclass{myart} ersetzen. Die heutige Lage lässt sich daher so fassen: Umbenennen ist keine Pflicht, aber der sicherste und am wenigsten strittige Weg, 6a zu erfüllen. Wer etwas forkt und auf CTAN stellt, benenne es ohne Zögern um. Wer dagegen eine Hausklasse anpasst und nur intern nutzt, verbreitet gar nichts, und Klausel 6 greift nicht – wobei 1.3c „Distribution“ weit fasst und festhält, dass auch das Ablegen auf einem gemeinsam genutzten Dateisystem dazuzählt.

Maintainer und Current Maintainer: Wie ein verwaistes Paket den Besitzer wechselt

Current Maintainer ist ein Amt, maintained ein Zustand – wer beides verwechselt, kann die Lizenz nicht mehr lesen. Nach den Definitionen der 1.3c ist der Current Maintainer die im Werk als solche benannte Person; fehlt eine ausdrückliche Benennung, übernimmt der Rechteinhaber das Amt. Es ist ein Titel, und Klausel 4 macht ihn zur einzigen Position, aus der heraus frei geändert und weiterverbreitet werden darf. Die Wörter maintained, author-maintained und unmaintained beschreiben dagegen den Wartungszustand des Werks selbst und werden im Werk erklärt. Ein Werk gilt als maintained, wenn der Current Maintainer erkennen lässt, Fehlerberichte annehmen zu wollen – etwa durch eine funktionierende E-Mail-Adresse. Eine Pflicht, darauf zu antworten, besteht nicht. Die Angabe author-maintained bedeutet, dass nur die Autorin oder der Autor pflegen darf, und schaltet das unten beschriebene Übernahmeverfahren ab.

Für ein Werk, das unmaintained geworden ist, schreibt die Lizenz das Übergabeverfahren aus. (1) Auf angemessene Weise, etwa per Internetsuche, den Current Maintainer aufspüren – und den Rechteinhaber, falls das eine andere Person ist. (2) Wird er gefunden, nachfragen, ob das Werk noch gepflegt wird; falls ja, ihn bitten, seine Kontaktdaten binnen eines Monats zu aktualisieren. (3) Scheitert die Suche oder bleibt alles folgenlos, in der zuständigen Community die Absicht zur Übernahme ankündigen. (4) Wird diese Ankündigung drei Monate lang weder vom Maintainer noch vom Rechteinhaber noch von sonst jemandem angefochten, darf das Werk so geändert werden, dass es die neue Person als Current Maintainer nennt. (5) Taucht der zuvor unerreichbare Maintainer jedoch binnen drei Monaten nach der Änderung wieder auf und verlangt es, fällt ihm das Amt zurück. Ein lebendes Beispiel liegt nahe: Im Kopf des Mehrsprachenpakets babel steht Copyright 1989–2012 für Johannes Braams und 2012–2024 für Javier Bezos und Braams, und als Current Maintainer ist Javier Bezos genannt.

Was man schreiben muss, um ein eigenes Paket unter die LPPL zu stellen

Um eine eigene .sty oder .cls unter der LPPL zu veröffentlichen, genügt ein kurzer Hinweis am Anfang jeder Datei, und er läuft auf vier Bestandteile hinaus. (1) Eine Copyright-Zeile mit dem eigenen Namen und dem Jahr der Entstehung oder der letzten wesentlichen Überarbeitung. (2) Die Erklärung, dass Version 1.3 oder wahlweise jede spätere Fassung gilt. (3) Der Wartungsstatus – zu wählen ist maintained – und der Name des Current Maintainer. (4) Eine Aufzählung, welche Dateien das Werk bilden. Der letzte Punkt wird gern vergessen, doch die Lizenz verlangt, dass Distributionen alle Dateien des Werks enthalten; sagt die Autorin nicht, was das Werk ist, kann die empfangende Seite es nicht wissen. Bei vielen Dateien ist die einzelne Zeile % This work consists of all files listed in manifest.txt. ein anerkannter Ausweg. Und die LPPL ist keine Public Domain: Der Code darf frei genutzt werden, doch die genannten Hinweispflichten und Klausel 6 bleiben bestehen.

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

Zuletzt die Einordnung gegenüber anderen Lizenzen. Die LPPL 1.3c wurde am 11. November 2009 von der OSI anerkannt, sie erfüllt Debians DFSG, und die FSF hält sie für frei. Dennoch ist sie mit der GPL unverträglich – und zwar nicht wegen der Pflicht, sich als verändert auszuweisen, wie viele Darstellungen behaupten, sondern wegen Klausel 6d: Die Auflage, eine vollständige unveränderte Kopie des Originals oder den Weg dorthin mitzuliefern, ist eine Zusatzbedingung, die die GPL nicht zulässt. LPPL-Code lässt sich daher nicht in ein GPL-Projekt übernehmen. Umgekehrt ist die TeX-Welt keineswegs durchgehend LPPL. Unter den Mehrsprachenpaketen etwa steht babel unter der LPPL, polyglossia dagegen unter der MIT-Lizenz. Die Gewohnheit, das Lizenzfeld zu lesen, zahlt sich auch bei der Paketwahl aus.