Re: Question(s) for clarifications with respect to the LPPL discussion
Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
> Henning Makholm writes:
> also not violating LPPL but violating the spirit of it would be to add an
> article.cls that just contained
> \input{article-with-recurity-problem-removed.cls}.
If such a simple-minded technique will not count in court as a license
violation, I can think of no argument against the LPPL that is based
on the "excessive burden" of the renaming requirement.
Actually, since we now have, documented for eternity in the list
archives, a statement from one of the leading figures in the LaTeX
community that such is the intention of the license, we can IMOsafely
assume it to be true.
The Big Boys [1] seem still to be arguing whether the renaming thing,
irrespective of how hard it is to comply with, conflicts with the
*letter* of the DFSG. For what it's worth: My own impression of the
*spirit* is that it ought to be called free, then, but that's my very
own impression and I ain't going to share it with nobody.
[1] meaning voting debian developers.
> within the spirit would be a way to generate this file upon users
> request (say by unpacking some tar, manually running scrip, etct)
> while explaining to him that this makes his distribution not output
> compatible with other distributions.
Hmm, I think that could be construed as a possible implenentation of
perhaps the big boys could construe this an implementation of "patch
files ... for the purpose of modifying the program at build time"
which are explicitly allowed by DFSG #4. The joker here is DFSG #2
which states that the license "must allow distribution in ... compiled
form", which, even if "compiled form" does not make much sense for
interpreted macro code, could imply that in that case, the patched
code must be distributable as the closest thing to compiled form we
have.
> > > > If you want to fork LaTeX you must do so-and-so (remove banners,
> > > > change all addresses, grep -i latex all over the source to make
> > > > sure nothing remains except in comments that give credit to what
> > > > you used as your starting points, rename latex.ltx to something
> > > > else {which is acceptable because its name does not occur in other
> > > > source files} etc etc etc).
> > > > Once you have done this, you will have a forked project which will
> > > > so far be completely technically equivalent to LaTeX, because
> > > > you're not allowed to modify anything until you've gone through
> > > > the procedure. Now go ahead and hack, and watch your karma drop
> > > > as you do it.
> if you mean that your suggestion allows you to get around the LPPL
> requirement of renaming, then no it doesn't.
I was trying to describe a scenario where one does *all* the renaming
that could ever be required, (semi)automatically once and for all in
the beginning, without breaking any functionality, and especially
without breaking the internal references between files or packages.
Afterwards one would be free to go on hacking without having to keep
track of the first change to each file and rename them as one goes.
The "\input-softlink" spirit-breaker you described above would be one
such, albeit crude, technique that could be implemented by anyone with
a handful of code lines in his favorite macro language.
> remember LPPL is not the license for the LaTeX kernel it is a
> license being applied these days to several hundreds of indepeneded
> works (individually!).
Oops. Is the kernel under a different license than LPPL?
--
Henning Makholm "Jeg kunne ikke undgå at bemærke at han gik på hænder."
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: