Re: Concluding the LPPL debate, try 2
Scripsit Jeff Licquia <licquia@debian.org>
> The license text would say something like this:
> -----
> The Program may be modified in any way as long as one of the following
> conditions are met:
>
> - No part of Standard LaTeX is changed.
>
> - The Program does not represent itself as Standard LaTeX in any way,
> including the name and any diagnostic output.
>
> The Project distributes a file with the Program, foo.tex, that describes
> some procedures we have set up to allow derived works to fulfill these
> conditions.
> -----
There is a systematic problem here in that, as Frank has described,
"Standard LaTeX" is a more slippery concept than the end-user of
something like teTeX usually imagines. But that could probably be
fixed somehow.
> The procedures file would reference an API call. The exact API is up to
> the LaTeX Project, of course; for now, we'll call it "register". All
> macro packages, extensions, etc. that are a part of Standard LaTeX would
> contain this API call, which would register the string "LaTeX".
I may be dense, but even though I've followed the thread, I find this
description hard to follow. It seems to me that the intended semantics
of "register" is, "please kill me unless you happen to like this cookie".
In that case, your scheme could be paraphrased as
"If you want to modify a package [say, one that is not part of the
core LaTeX distribution, but one whose author has independently
put it under the LPPL], you must either
1) [do the renaming stuff], or
2) make sure that your modified package refuses to run on top of
the standard LaTeX kernel."
If this is correct, I don't think that option (2) is not a free
option.
As detailed before, I now think that the renaming option *is* free
(just barely).
> 3. Change or remove the behavior of the "register" call entirely (which
> is a kernel modification), and make sure that the modified kernel does
> not represent itself as LaTeX in name, diagnostic output, etc.
> (Option 3 might be expressly discouraged by the LaTeX Project, but it is
> important nevertheless.)
I can't imagine that it would be acceptable for the LaTeX people that
a change in the LaTeX *kernel* would make it legal to hack in another
file that, from their point of wiev, is part of an entirely
different, separately distributed work.
Remember what the problem that the renaming thing is supposed to fix
in the first place is. Basically it stems from the fact that the TeX
language as specified by Knuth has a very feeble concept of filesystem
organization, if any at all. Knuth had worthy portability reasons for
doing it that way - after all, TeX was conceived of in an age where
machines without hierarchical directory structure was not just relics
in technical museums but systems that some people were using for
getting work done. (PC-DOS had had directory trees for just a few
months when the preface to the TeXbook was written in June 1983).
The upshot of this is that, at least the web2c implementation of TeX
that most people use in practice, largely ignores the directory
structure and looks at the raw names only. When TeX macro code asks
to have some named file read in, the implementation will search for
*any file* with that name *anywhere* in the directories in its search
path *or their subdirectories*, recursively. The first file found will
be read.
This means that if I hack a private copy of article.cls without
changing its name, and by some weird chance my private file gets
copied to a directory where TeX looks for files, there is a real
risk that the changed file will be read by a process that was supposed
to be ordinary LaTeX - even if the changed file is quite far away from
the directory where *people* would look for LaTeX stuff.
[Sheesh. Just by explaining these basic facts explicity, I feel I'm
sounding like Boris in his Debian-people-are-completely-clueless-when-
it-comes-to-TeX mode. Hope nobody will take offense].
Obviously there is quite a bit of room of disagreement about how
likely it is for changed-but-not-renamed files to accidentally end up
in unlikely places (as someone who has had the experience of running
rm -rf on a directory containing two weeks' worth of source code that
I was just about to back up for the first time, I can testify that any
kind of havoc that can possibly be wrought using fileutils has a
nonzero probablility of happening somewhere somewhen), and how much
is reasonable to force someone who knows what he's doing to jump
trough hoops to prevent it. But even if we don't *agree* that the
fear justifies the means, we should nevertheless *understand* what it
is.
The "option 3" you propose would entail that two directory trees
existed, one which is the original LaTeX, and one where the kernel is
modified and renames but the rest of the files (say, third-party style
files) may be modified *without* renaming. Thus there would still
be a danger if the search path for the pristine software were to be
contaminated with references to the hacked tree.
Or am I misunderstanding what option 3 is about?
--
Henning Makholm "... and that Greek, Thucydides"
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: