Re: Question(s) for clarifications with respect to the LPPL discussion
Henning Makholm writes:
> Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
> > Henning Makholm writes:
>
> > > I'm sure it will be possible to find a way to *allow* a reasonably
> > > painless fork without actually encouraging it.
>
> > but we do encourage fork!
>
> I think we have a language program, then. As far as I understand, the
language problem you mean? possibly, so let's try to clarify it
> whole point of your licence is to legally prevent people from
> distributing something that does almost but not quite what LaTeX does
> (viz a lot of arguments about the necessity of having page breaks
> being in the same places and so on). That is what I call a fork.
if you insist that a fork is something that is a derived work but must sail
under the name of the original, then indeed, I was wrong: we don't encourage
such forks. however i don't think you meant that.
anyway, my understanding of a fork is a changed version of some work not done
by its author(s) but by somebody else (without any qualification on whether it
is good or bad or necessary --- that is irrelevant). by the way i'm not saying
anything here about the name of of the work after the fork.
Now, what we encourage are forks that coexists with their original and
therefore contribute to the concept that LaTeX documents produce everywhere
identical results. Eg a fork of the article class to produce documentation for
Debian and at the same time fix a number of glaring or not so glaring
typographical monsters in article.cls (yes they exist:-) would, if forked as
debianart.cls, enrich the LaTeX language, as every user could benefit from it
if he starts (some of) his new documents with
\documentclass{debianart}
Now don't jump at me that i said "new documents", i'm well aware of the fact
that this fork is not going to fix a bug in article.cls for that user, unless
he goes into his old documents and changes the line
\documentclass{article}
(nor would it fix a security problem in article.cls, which I don't argue can't
be constructed theoretically and practically). I will come back to that later.
On the other hand, if the fork would patch article.cls within the debian
distribution, then users using the debian distribution would perhaps get
typographically better looking documents, but at the same time they would be
deprived of sharing document sources successfully with other users that use
non-debian distributions of LaTeX.
Now my claim is that in 99+% of the cases it is better to let the user decide
for his documents whether to apply the original article or the changed one,
simply because in nearly all cases you are not deciding between something with
or without a certain bug or feature, but deciding between different
typographical treatments (and that isn't a closed-and-shut type of case but at
best a decision between schools of typography but usually not even that ---
i'm not trying to make a statement here against the use or need for such
derivations, I'm just making a case for them most often being adding another
choice of treatment).
Even if you have a clear case of a "bug" by most standards, for example, for
the article class we have
latex/3421: 3rd page is even (twoside, titlepage, abstract)
it is not as simple as, say, a bug in the code generation of gcc. The reason
being (again) that LaTeX is a macro language. That means that the above bug is
most likely fixed in one way or the other by classes that load
article.cls as their basis (remember, you can, at any time change any part of
the LaTeX language within the LaTeX language). Thus by changing article.cls in
one distribution, you are not only have the effect that this distribution
produces different documents than others, you also have the effect that you
potentially wrack a large number of already produced documents if you try to
rerun them. Thus even then it is often better to have the user select between
alternate implementations.
But coming back to an example of security problem due to a but of dangerous
code accidentially or deliberately added to article.cls. Then my arguments
above die down, don't they?
well they do to some extend but not really. The simplest solution for a
distributor would be (beside informing the authors of articl.cls) simply not
to distribute article.cls but only article-with-recurity-problem-removed.cls
(no i'm not really suggesting thisas a name:-) and inform his users about the
problem and the reason for the removal of article.cls.
That would be allowed by even by the current LPPL (i think) though it means
that you are actually distributing a modified work, ie it isn't made very
clear and it should be made clearer what you should or can do in this case. As
we don't say anything about the form of distribution, it could be done
alternatively as follows:
- have in current tetex tex/latex/base normal stuff minus article.cls
- add tex/latex/debian-fixes/article-with-recurity-problem-removed.cls
- put article.cls in a tar labeled fixed-or-updated-latex-base-files.tar
- in a sensible place explain what you done here and why.
This way you are actually distributing the original work unchanged (only
rearranged so that you help your users not to get trapped by the detected
security problem).
you might even add a sh script that copies
article-with-recurity-problem-removed.cls to article.cls and tell the user to
run that script to get your version of article.cls rather than no version as
long as you tell at the same time that in that case he is not allowed to
distribute his installation further (or rather not this file).
Since executing that script of yours be a concious act by the user and one on
his own machine only all of that would be covered by LPPL.
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}. 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. Alternatively it
could be made even clearer by forking LaTeX kernel to a non-latex kernel (just
in the identification)
As i said the above wouldn't violate LPPL but its spirit. So while it would be
allowed it would give any distribution that does something like this behind
the scene (!!!!!) a very bad press once it is detected. This so happened, when
somebody improved the CM fonts --- most people made sure not to use that
distribution after it was detected any more ever.
This is why we are not so afraid of that type of circumvention.
> > it usually leads to new good results for the whole community.
>
> If you understood the same thing by "fork" that I do, that would count
> as a major contradiction of the goals you stated earlier. What do you
> understand by "fork" - or rather, how would you prefer that I refer to
> the thing I've been calling a fork?
i hope i made clear with the above what i mean by a fork. Now back to your
example. It is also a fork. And it is one of the few cases where you sensibly
(not that the example was so great :-) start from forking at the kernel level.
To stop discussing nonsense cases I offer a real example myself (close to
yours actually): suppose you want to output LaTeX documents for use by visibly
challenged people, eg either outputting to braile or perhaps even to a speech
synti.
Now in that case very many if not nearly all LaTeX packages need a
reinterpretation.
However even in this case I would recommend that the forking method (outlined
in cfgguide but not made completely general there unfortunately, ie the way
that for each LaTeX file type (of which there exisits only a handful) you
specify a derivitive file type) is perferable as it would allow everbody to
have both std latex as well as brail-latex in parallel on his machine (if so
desired) rather than making it an either or.
was this any helpful?
=============================
on the remaining part of the message:
> > > 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.
>
> > okay, so far, that would already be acceptable under LPPL;
>
> I cannot see how the current license (or the draft) allows such a
> thing. Could you please spell out in greater detail how such a
> procedure would be compatible with the renaming requirement?
if you mean that your suggestion allows you to get around the LPPL requirement
of renaming, then no it doesn't.
> > but then what? what exactly do you want to hack then?
>
> Anything I want. As I said earlier, the question is not whether I have
> a valid reason to change something. I want to be sure that whenever
> someone makes up some reason to change something, whether or not I
> agree with their particular reason, they will be allowed to do so.
what i meant is what do you think which files you are allowed hack
thereafter. 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!).
and i think upon reflection you will probably agree that it doesn't follow
that if you fork, say the latex-base distribution that this has any bearing
(legally or otherwise) upon other works related to LaTeX whether release under
LPPL or some other license. E.g, if somebody releases a package for LaTeX
under GPL your for of the kernel will not change its status, not will it
change the status of a package release under a Microsoft license or under LPPL
>
> > what is it what you term "LaTeX" here?
>
> Basically all the stuff that implements the relation between .tex
> input and .dvi output that is documented by the not-so-short guide
> and The LaTeX Companion.
that is, as i tried to explain in the paragraph above never following from
your fork as such things are all licensed individually, thusyou have to fork
them individually (if their license allows that), or not?
and this is why i asked the question, as i suspected you mean the whole of the
LaTeX world.
cheers
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: