Re: Concluding the LPPL debate, try 2
On Thu, 2002-07-25 at 16:36, Henning Makholm wrote:
> 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 second-to-last paragraph seeks to address that concern.
> > 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.
Heh. It's not the first time someone has accused me of being dense. :-)
> 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.
The main thing to consider is that the LaTeX Project has the right to
modify the kernel (or whatever; nod to Lars) just as everyone else
does. They can put the code in Standard LaTeX to die if the right token
is not passed via this macro.
Now, if you want to modify LaTeX, we've already established that you'll
have to do some work in making sure to rename it, etc. You might need
to change the "cookie kill" code, or redefine it to point to your own
"cookie kill" macro, or remove it entirely if it offends your
sensibilities. But you've already identified yourself as not-LaTeX, so
that's OK under options 2 and 3.
Here's an analogy that might work: It's possible to modify login, init,
etc. to put user limits on systems, so you could sell a "5-user version"
of Debian. Nothing in the GPL, the DFSG, or any of the other licenses
prevents this; indeed, I could argue that a license that disallowed this
would itself violate the DFSG. However, you do have to provide the
source to the modified login, init, etc., and you can't prevent the user
from hacking the limit out or setting it to 32,768 users. This
limitation is similar: LaTeX itself will refuse to run macros that
aren't "blessed", but you are allowed to hack that restriction out.
> As detailed before, I now think that the renaming option *is* free
> (just barely).
Hmm. Others don't agree, and they have convincing arguments. So, I'm
looking for an option that works for everyone.
> > 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.
I won't presume to speak for Frank & Co., but they've indicated before
that they don't mind this as long as the result is clearly identified as
"not LaTeX".
Moreover, there's significant support in the Debian camp for the idea
that option 3 is required for DFSG-freeness.
> 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.
That is correct. However, causing a hacked, non-renamed, non-retokened
file to be loaded and run by Standard LaTeX would be a license
violation.
It would probably be a good idea for the license, or some supporting
document, to point out this danger. I expect that the "best practices"
document they put out will strongly discourage this method of hacking on
LaTeX, as changing the token will protect LaTeX hackers from such an
inadvertent license violation.
(I agree with Jeremy that a --disable-token-kill option might encourage
best practice even more, as you could run your local modifications with
a new token and not have to hack "register". But that's up to the LaTeX
people to decide; I don't think it's necessary for the DFSG.)
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: