Re: LaTeX Public Project License, Version 1.3 (DRAFT)
Jeff Licquia writes:
> First of all, this license is nasty.
possibly (not not in spirit only in wording in our opinion)
> The restrictions on modification
> are complex; the license itself predicts failure to understand its
well, I hope that could be mended if that is really the case, though I'm not
quite sure that this way of discussion can really help. for the moment I'm
following it nevertheless (ie point after point), probably not being able to
come to the later posts tonight
> Some of its terms are dependent on external factors that cannot
> be determined objectively by examining the Program alone.
that should not be the case. we'll see. if so there is indeed something wrong
not sure i have seen you make that explicit
> Additionally, it's pretty clear that the intent of this license is to
> create a cabal of "approved" maintainers, and to place "unapproved"
> maintainers in a complex legal trap that's easy to trip. Such elitism
> is completely against the spirit of the DFSG and the motivations of the
> Debian Project, and offends the sensibilities of the whole community.
before this goes totally in the wrong direction, let me clarify here something
up front: the idea of the "maintainers" is something in LPPL 1.3-draft
only. It wasn't there before and it came up during dicussion within the LaTeX
community. I tried to incorporate the wishes expressed there in a very first
draft and it certainly is something that needs further thought.
> If LaTeX adopts this license, then I would recommend moving LaTeX to
> non-free immediately and forking it if possible to preserve the
> (ostensibly free) current status it enjoys.
ahh, well, but LaTeX core and most of of all the external additions are under
LPPL 1.2 which is like 1.3-draft - maintainer - (something which I really
thought was non-free (by mistake) and for which Richard Stallman gave the idea
to fix it in a free manner)
> > Individual files of The Program...
> Note that no definition of the word "file" is provided. I believe this
> could be construed as a loophole of some kind, and is definitely a flaw
> in the license.
that is indeed a big problem, and giving a large proportion of the later part
of the mail shows that what was meant by "file" is not what you (probably
correctly) applied to it as its meaning.
it was for example never intended to be applied to packaging or distribution
methods, eg nobody in the LaTeX world would apply it to anything other those
files that directly influence the results of formatting documents, eg .sty and
.cls files but not something like foo-1.0.tgz
> Consider Program "foo", distributed as "foo-1.0.tar.gz" under the LPPL.
> "foo-1.0.tar.gz" is a file by any reasonable definition, and can be
> reasonably construed to not contain additional restrictions beyond the
> LPPL. If Debian changes the file name to, say, "foo_1.0.orig.tar.gz",
> doesn't it then follow that Debian can change any part of that file at
> They attempt to close this loophole below, with the "unpacking" clause.
> I don't think they're successful.
can you explain why not? that unpacking is actually the crux of the matter in
some sense as in most cases latex related software is distributed in a sort or
archived literate programming form, eg you have foo.dtx and foo.ins, the
latter will generate foo.sty which is important to be identical of different
sites to provide reliability. so what the license ask is when changing
foo.sty give it a new name, even though the .sty is "generated" rather than
already provided, from foo.dtx.
on the other hand, nobody would ask for foo-1.0.tgz to be the only form of
> > ...may bear supplementary
> > and/or superseding conditions on modification of themselves and on the
> > distribution of modified versions of themselves, but *no* file of The
> > Program may bear supplementary or superseding conditions on the
> > distribution of an unmodified copy of the file. A distributor wishing
> > to distribute a complete, unmodified copy of The Program therefore
> > needs to check the conditions only in this license and nowhere else.
> Assuming the LPPL is found to be DFSG-free by itself, it cannot
> guarantee that a Program is DFSG-free without reading about each file's
> additional restrictions. (Yes, this can be true anyway, but no other
> free license I know of explicitly supports this practice, and some
> attempt to prevent it.)
some history, clarification, and a proposal:
- that paragraph (and some related ones) were added to LPPL for exactly two
- to allow certain files to be modifiable with less fuss (no name change)
- to prevent .ins files from changes as they were used to add LPPL
to generated files, eg foo.ins turned foo.dtx into foo.sty by stripping
comments off and adding a header that added "this file is distributed
under LPPL ..." to it.
(on top of GPL there is
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
which is the same idea, ie .ins files contain LPPL license pointers)
- now the second part was a problem for the simple reason that
a) the way it was written it could have been used to distribute a whole
program under LPPL without allowing to change anything (not intended by
us and never done to my knowledge ,but ...)
b) it would have been better to explicitly say that the generated files are
part of the program and thus get rid of the issue completely.
- this is what I tried and that is essentially 1.3-draft (if you forget the
maintainer part for the moment that came later.
- what i missed is that with that change (assuming your remark above being
mistaken) one can (and should) also change the related paragraphs. eg the
one under the knife right now should only speak about allowing less
restrictions or perhaps one could through it out completely.
> > You may distribute a complete, unmodified copy of The Program.
> > Distribution of only part of The Program is not allowed.
> This clause is also important for reasons that will be clear later.
> > 3. You must not distribute the modified file with the filename of the
> > original file.
> > 4. In the modified file, you must acknowledge the authorship and
> > name of the original file, and the name (if any) of the program
> > which contains it.
> > 5. You must change any identification string in the file to indicate
> > clearly that the modified file is not part of The Program.
> > 6. You must change any addresses in the modified file for the
> > reporting of errors in the file or in The Program generally to
> > ensure that reports for files no longer maintained by the original
> > maintainers will be directed to the maintainers of the modified
> > files.
> These mandatory modifications may make it non-free. 3, 4, and 5 are
> probably OK, but I'm not sure about 6.
sorry you lost me. what makes what non-free???? 6?
sorry give up for tonight more at some point later
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org