Licencia (LPPL)

La LPPL es la licencia que emplean el propio LaTeX y casi todos los paquetes. ¿Cuán casi? De las 4.292 entradas del registro de paquetes de TeX Live 2024 que declaran licencia, 2.986 —el 69,6 %— declaran alguna versión de la LPPL, frente a 425 (9,9 %) de la familia GPL. Y la única frase que todo el mundo recuerda de esta licencia —que un archivo modificado debe renombrarse— no aparece en ningún sitio de la LPPL 1.3c que tiene en su disco. Esta página sigue el rastro de esa regla: adónde fue, por qué desapareció y qué exigen realmente las cláusulas que quedan, contrastando cada afirmación con el texto que acompaña a TeX Live.

Qué versión dice realmente «renombre el archivo modificado»

La respuesta es la cláusula 3 de la LPPL 1.2, no la 1.3c actual. Abra la línea 74 de texmf-dist/doc/latex/base/lppl-1-2.txt, incluido en TeX Live 2024: allí está, como la tercera de las ocho condiciones para distribuir un archivo modificado — «You must not distribute the modified file with the filename of the original file.» La 1.0, más antigua, era aún más estricta y fijaba hasta el orden de las operaciones: renombrar el archivo antes de tocarlo. Sin embargo, si se busca «renam» o «filename» en el lppl.txt actual del mismo directorio, aquel cuya cabecera dice LPPL Version 1.3c 2008-05-04, se obtienen cero coincidencias. La regla sencillamente ya no está en la licencia.

# 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

¿Por qué imponer semejante condición de entrada? El razonamiento sigue ahí, con ejemplo incluido, en modguide.tex, un documento de 1995 alojado en el mismo directorio. La colección «tools» de LaTeX contiene array.sty, al que a finales de 1994 se le añadió una función nueva de nivel de usuario. Un documento puede entonces escribir \usepackage{array}[1994/10/16] para declarar que necesita una versión no anterior a esa fecha. Si otra persona distribuyera un array modificado con el mismo nombre, circularían archivos con fecha posterior pero sin la función, y la declaración no valdría nada. Ese era el argumento del LaTeX Project. Y el mecanismo sigue funcionando tres décadas después: pídale a TeX Live 2024 una fecha inexistente y obtendrá LaTeX Warning: You have requested, on input line 3, version ... but only version ... is available. En TeX, un nombre de archivo forma parte de la sintaxis que ve el usuario.

Por qué cambió la cláusula en 1.3: la disputa de Debian en 2003

El detonante inmediato fue Debian, que en 2003 se planteó retirar LaTeX de su distribución principal. El punto de fricción era precisamente aquella cláusula de nombre de archivo: si «no puede distribuir una versión modificada con el nombre original» encajaba con las Debian Free Software Guidelines se debatió largamente en la lista debian-legal. La postura de la Free Software Foundation también estaba finamente calibrada. Calificó la LPPL 1.2 de licencia libre pero incompatible con la GPL, y juzgó que la exigencia de renombrar caía justo en el lado aceptable de la línea. Su razón es reveladora: TeX dispone de un mecanismo para remapear nombres de archivo —puede configurarse para usar bar cada vez que se pida foo—, de modo que renombrar es una molestia y no un obstáculo. Trasplante la misma condición a un sistema sin ese mecanismo, añadía la FSF, y volvería no libre al software. De esa controversia salió la LPPL 1.3, publicada el 1 de diciembre de 2003, de la que la cláusula de nombre de archivo había desaparecido.

Qué exige realmente la 1.3c: los cuatro deberes de la cláusula 6

El cuerpo de la 1.3c consta de doce cláusulas, y solo una —la cláusula 6— atañe de verdad a quien modifica un paquete. La estructura es esta. Las cláusulas 1 a 3 cubren el uso y la distribución sin cambios; la cláusula 4 dice que si usted es el Current Maintainer puede modificar y distribuir con libertad; la 5 permite a cualquiera modificar su propia copia; y la cláusula 6 fija las condiciones para distribuir una versión modificada cuando no se es el Current Maintainer — cuatro condiciones, de la a a la d. El eje es la 6a: allí donde el componente original se anuncia al usuario al ejecutarse de forma interactiva con el Base Interpreter (para una obra LaTeX, un formato LaTeX), el componente sustituto debe identificarse clara e inequívocamente como versión modificada. La exigencia pasó, pues, de «renómbrelo» a «haga imposible la confusión».

Entonces, ¿renombrar ya no hace falta? En la práctica sigue siendo lo correcto, pero la autoridad en ese punto es modguide.tex, no la licencia. Ese documento pide explícitamente que se dé otro nombre a una clase o paquete que se haya mejorado, y señala la solución más simple: sustituir \documentclass{article} por \documentclass{myart}. La situación actual se resume así: renombrar no es una obligación, pero es la forma más segura y menos discutible de satisfacer la 6a. Si piensa bifurcar algo y subirlo a CTAN, renómbrelo sin dudar. En cambio, si retoca una clase interna y la usa solo dentro de su grupo, no está distribuyendo nada y la cláusula 6 nunca se activa — eso sí, la 1.3c entiende «distribución» en sentido amplio y afirma que colocar archivos en un sistema de archivos compartido cuenta como tal.

Maintainer y Current Maintainer: cómo cambia de manos un paquete abandonado

Current Maintainer es un cargo; maintained es un estado — confundirlos vuelve ilegible la licencia. Según las definiciones de la 1.3c, el Current Maintainer es la persona designada como tal dentro de la obra; a falta de designación explícita, el titular de los derechos ocupa el cargo. Es un título, y la cláusula 4 lo convierte en la única posición desde la que se puede modificar y redistribuir con libertad. En cambio, las palabras maintained, author-maintained y unmaintained describen el estado de mantenimiento de la obra misma, declarado dentro de ella. Una obra está maintained cuando el Current Maintainer indica que acepta informes de error — por ejemplo, facilitando una dirección de correo válida. Nada le obliga a responderlos. Declarar author-maintained significa que solo el autor puede mantenerla, y desactiva el procedimiento de traspaso descrito más abajo.

Para una obra que ha quedado unmaintained, la licencia detalla el procedimiento de traspaso. (1) Intentar razonablemente, mediante una búsqueda en internet o similar, localizar al Current Maintainer — y al titular de los derechos si es otra persona. (2) Si aparece, preguntarle si la obra sigue mantenida; en caso afirmativo, pedirle que actualice sus datos de contacto en un mes. (3) Si la búsqueda fracasa o no hay respuesta, anunciar en la comunidad pertinente la intención de asumir el mantenimiento. (4) Si tres meses después de ese anuncio ni el mantenedor, ni el titular de los derechos, ni nadie más lo impugna, puede modificarse la obra para nombrarse nuevo Current Maintainer. (5) Pero si el mantenedor antes ilocalizable reaparece dentro de los tres meses siguientes al cambio y lo solicita, el cargo vuelve a él. Hay un ejemplo vivo a mano: la cabecera del paquete multilingüe babel lleva copyright 1989-2012 a Johannes Braams y 2012-2024 a Javier Bezos y Braams, con Javier Bezos nombrado Current Maintainer.

Qué hay que escribir para publicar el propio paquete bajo la LPPL

Para publicar su propio .sty o .cls bajo la LPPL basta con una nota breve al comienzo de cada archivo, y se reduce a cuatro elementos. (1) Una línea de copyright con su nombre y el año de redacción o de la última revisión sustancial. (2) La declaración de que se licencia bajo la versión 1.3 o, a su elección, cualquier versión posterior. (3) El estado de mantenimiento —elija maintained— y el nombre del Current Maintainer. (4) La lista de qué archivos constituyen la Obra. Ese último punto es el que se olvida, pero la licencia exige que las distribuciones lleven todos los archivos de la Obra, así que si el autor no dice qué es la Obra, el receptor no puede saberlo. Si hay muchos archivos, la línea % This work consists of all files listed in manifest.txt. es una salida admitida. Y la LPPL no es dominio público: el código puede usarse con libertad, pero siguen en pie las obligaciones de aviso anteriores y la cláusula 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.

Por último, su lugar entre las demás licencias. La LPPL 1.3c fue aprobada por la OSI el 11 de noviembre de 2009, cumple las DFSG de Debian y la FSF la reconoce como libre. Aun así es incompatible con la GPL — y el motivo no es la regla de «identifíquese como modificado», que muchas explicaciones confunden, sino la cláusula 6d: la exigencia de entregar una copia completa y sin modificar del original, o el medio de obtenerla, es una condición adicional que la GPL no permite. El código LPPL, por tanto, no puede absorberse en un proyecto GPL. En sentido inverso, el mundo TeX no es uniformemente LPPL. Entre los paquetes multilingües, por ejemplo, babel está bajo LPPL mientras que polyglossia está bajo la licencia MIT. Acostumbrarse a leer el campo de licencia también ayuda a la hora de elegir paquetes.