Towards a new LPPL draft
it seems to me that by now we are turning around in cycles rehashing arguments
that are important in general (can LaTeX have security problems, yes or no?;
how does one do software development ...) but not with respect to the problem
at hand which still is (to me at least) the following two things:
1) determine whether or not the fundamental believes of the LaTeX Mafia
comply with the those of the Debian people
2) if so to draft a new LPPL license that reflects both believes, i.e., is
DSFG-complient (as well as being understood to be DSFG-complient) while at
the same time allowing the majority of the people in the LaTeX world to
work as they feel appropriate.
If (1) is a no-go we don't have to attempt (2) and I for my part have no
intention to. But if (1) is possible, and it seems that this is the case, then
please stop arguing on the level
File name requirements is something that can be circumented so remove it.
We have explained over and over again, that despite that clearly true
observation we think that it gives a good way to evolve the LaTeX language
while allowing to have other modifications (including the sidestepping)
happening outside of what LaTeX users consider conformant LaTeX.
For a last time: the argument we have is that a fork on the level of a LaTeX
package (not on the level of the LaTeX kernel) --- and that is the majority of
the "forks" that are happening --- is something that through LPPL simply
enlarges the LaTeX language and thus keeps an univerally conformant LaTeX that
then embraces the fork (if so desired by its author) making it a bigger
conformant LaTeX, while at the same time a fork at the kernel level using the
general file-name mapping feature allows a) to do anything you like (in an
easy manner, no cascading problem) while b) it is not threatening any
conformant LaTeX as it can live side by side. So for us this combines the best
of both approaches.
So to come back to (1):
Axiom: after all discussions the LaTeX Mafia, the LaTeX users that spoke on
this list, and the Debian users that mailed me privately, still believe that
the requirement for renaming files LaTeX source files when doing modification
for distribution is essential and helpful.
What i learned from the discussion is that the license should restrict this to
what we actually need (eg not makefiles, tar balls, etc).
Starting with this axiom I get:
From: email@example.com (Thomas Bushnell, BSG)
I think as the FSF's comments on the latex situation exemplify, the
question ends up being a matter of "how much of a pain is it". Since
latex apparently has a global file-mapping feature (something not
previously noted on the discussion on debian-legal, AFAICT) the
problem is not actually hugely severe--and easily worked around, as
other threads have indicated.
From: Jeff Licquia <firstname.lastname@example.org>
However, as it turns out, there is a process where you can limit
filename changes and provide "macro substitution" at runtime on
filenames, so that (for example) "article-foo" can be called when
"article" is referenced in a document. This reduces the problem back
down to the level of changing C source file names; it's an annoyance to
have to write the redefinitions, but nothing more. This also requires
changing the name of the "binary", but that's OK too.
So, it's my understanding that this is DFSG-free.
The catch that I see is from Walter's recent post:
I just want to make sure that we don't allow a license that can only
be applied to LaTeX. When Thomas Bushnell writes:
it seems like Thomas thinks that the LPPL is OK for LaTeX, but
probably not for anything else. That troubles me.
Well, if it would be OK for LaTeX or related software, like Omega, TeX,
pdftex, etc, ie for macroprocessors that have the ability to support a global
file-name mapping feature then it would be useable not only for LaTeX "core"
but for several megabytes of code written --- i don't know how big CTAN is
these days but it is distributed as compressed files on three CDs.
I can understand if Debian people would judge such a license as DFSG-complient
only if the renaming requirement is not "too painful". As LPPL is currently
drafted to be usable with any program that would mean to either
- explicitly limit a new draft to software for macroproessors which have the
ability needed to make the requirement file renaming painless (ie no
- or to explicitly put the right kind of statement into the license that
makes it only applicable to programs which have that feature
The latter might be difficult (finding a precise definition, not just "needs to
be painless:), I don't know. The former would bring Walter's argument back up,
but I would think that
(a) there is nothing anywhere in DSFG that prohibits licenses to be
applicable only to certain domains
(b) the domain is large: it is not the latex kernel as distributed by the
LaTeX Project team but it is potentially all software written for and around
TeX and related programs which means software for several million users.
So to sumarize:
To go forward I propose
A) I would like you to come to a conclusion on (1) assuming the above Axiom
B) if you do and the outcome is not a flat no, but at least a grunted yes (or
if you like "its stupid and pointless but within the limits"), then I'm happy
to get back to the early posts by Jeff and take together with him and anybody
else interested the license completely apart to make its wording and
statements reflect what is intended without needing long explanations of
intend for the reader (as it is currently the case) and remove or rephrase
those parts that are completely wrong or unnecessary.
C) if the conclusion on (1) is a flat no, then I fear I have to suggest to
you to remove LaTeX from Debian, which I think many (me included) would think
would be a pitty.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org