Re: LaTeX Public Project License, Version 1.3 (DRAFT)
On Mon, 2002-07-15 at 17:36, Frank Mittelbach wrote:
> Jeff Licquia writes:
>
> > First of all, this license is nasty.
>
> possibly (not not in spirit only in wording in our opinion)
Well, let me get this off my chest: I don't mean to imply any malice in
the Project. I am only reporting what I see, and my reaction to it.
Never attribute to malice what can be ascribed to incompetence. :-)
> > 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
I was referring to the business of Current Maintainers and the
"maintained" state of the Program; claims embedded in the Program itself
do not change as the current circumstances change, so one must
investigate.
> > 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.
OK. Sorry if I implied anything otherwise.
> > 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
That's the part that you need to define, then. You might use words like
"archive file" and "component file".
> > 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.
I talked about it further down. Basically, a proper definition of
"file" would close the loophole.
> > > ...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
> reasons
>
> - 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)
As legal notices, .ins files are OK to remain invariant. However, .ins
files do more than just provide legal information.
It's OK to restrict the legal statements inside the .ins file in this
way, but not the part that's involved in the generation.
> - 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 ...)
The part about not restricting distribution isn't a problem; indeed, I
don't think it goes far enough.
> 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.
Definitely.
> > > 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?
It seemed to be restrictive at the time. I don't think it is anymore,
because you're not dictating the exact form of the change; you're just
asking that the reporting address be changed, which is akin to the "no
endorsement" clauses in other free licenses.
> sorry give up for tonight more at some point later
Cool.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: