Re: Towards a new LPPL draft
On Tue, 2002-07-23 at 11:46, Frank Mittelbach wrote:
> Jeff Licquia writes:
>
> > If each piece of the work had to be downloaded separately, then this
> > would be a valid way of thinking. When the LaTeX Project collects a
> > bunch of these separate works and combines them into "LaTeX", though,
> > they create a derived work, with its own licensing requirements.
>
> well, but that is how the situation is, isn't it?
>
> The LaTeX Project is not collecting a bunch of seperate works and combines
> them into LaTeX. It only provides 3 or 4 core parts of what is known to be
> LaTeX as well as providing a license (LPPL) which helps to keep that thing
> "LaTeX" uniform between different installations.
I see. I was under the impression that what you distribute included
lots of third-party stuff.
Debian is really only concerned here with the core license on the core
parts of LaTeX. If others within the LaTeX community don't like what
you've done with the license, then they can add modification
restrictions, and Debian can then decide to distribute them or not, or
negotiate directly with them, or whatever.
But before we can deal with the add-ons, we need to deal with the core.
> I mean I know that tetex (as a debian package) has done the downloading of
> individual LaTeX-macro works of many individual authors combined it with the
> scripts by Thomas Esser and with a web2c implementation of TeX and a few other
> independent works.
>
> As a whole (the packaging etc) tetex may have its own copyright and license,
> but that doesn't mean that the indivdual works it combines lose their license
> just because somebody puts them together. This is why we thought it to be a
> bad joke on this list when people claimed they not use TeX but tetex which is
> "free and under GPL". its organisation might be under GPL, the scripts may be
> under GPL, etc., but TeX the program within tetex and the 72 Computer Modern
> fonts within tetex are under Knuth's license and the 500 latex packages inside
> tetex are under LPPL or some other license (which is why there is the vague
> reference that individual parts may have different copyrights and licenses
> inside, which most people here like to ignore or overlook).
Right. This turned out to be an inaccuracy within the copyright file
Debian requires of all packages. A bug has been filed to fix it.
> > The license already allows sub-works within LaTeX to have additional
> > modification requirements beyond the LPPL. If you thought that some of
> > the sub-authors would disagree with relaxing the file naming requirement
> > when changing the name of the work from "LaTeX", you could allow them to
> > add that restriction to their file(s).
>
> What i was pointing out in my second reply to Brian is this: suppose you would
> only want to modify the work overcite.sty which consists of single file, or
> the work geometry which consists of geometry.sty + .dtx + a number of test
> files and manual then to be able to modify that without renaming you would
> need to build a "nonLaTeX" format with its own tree and place it in that
> tree. Now that "nonLaTeX" format wouldn't work at all unless you also copy a
> good proportion of the standard latex tree (couple of 1000 files if you
> include the fonts etc) into the new tree as well. That is certainly possible
> but i think it is far more painful than
>
> providing a nonLaTeX format with filename remapping and put
>
> overcite.fst and geometry.fst into the main tree
>
> thereby having LaTeX use the main tree (ignoring those two new files)
> and nonLaTeX using the main tree and loading overcite.fst when overcite.sty
> would by loaded by LaTeX and the same for geometry.
Please clarify something for me. What are the .fst files? Are they
patches?
> > > If you think of LPPL applying to the whole of a LaTeX sty/cls tree of files
> > > at once, we could, i think
> > > live with the idea (it is even described so in modguide or cfgguide as a
> > > possible though not encouraged
> > > solution (thereby actually violating the license as it is right now)), that
> > > you produce sniffenlatex
> > > which has its own complete tree and in there has identical file names to the
> > > pristine LaTeX tree so
> > > that both trees live side by side.
> >
> > >From the objections I have seen in trying to wrap up this thread, this
> > is likely to be an important point. I would strongly advise making this
> > concession if you can.
>
> as I exlained above I don't think it is a practical solution for what you want
> and far more painful than anything else (for you) unless as a result of this
> you start to only distribute nonLaTeX --- and if that is the intention behind
> it then all the arguments "we really don't want do this, we only want the
> right to be able to do something if necessary" are simply off because then you
> are essentially starting to produce a new nearly-latex distribution so that
> the exchangability of documents would after a short period be in real danger
> again.
Correct. I want to distinguish here between the rights Debian needs to
have and the rights Debian intends to exercise.
In point of fact, I would expect that any problems we have in LaTeX
would be communicated to you, and you would choose to address the
problem in some way or another in official LaTeX. We would then
distribute your fix to the problem. This is standard practice for the
vast majority of packages.
The rights we demand are usually for special cases. For example,
someone might want to create LaTeX Plus with some of his/her new ideas
for how document formatting should be done. Or, you guys might get hit
by a bus, and our obligation to our users requires us to make sure that
LaTeX is taken care of in your absence while the Project figures out who
should take over. Or maybe no one wants to take over, and we maintain
it as a legacy package (which we do for lots of the things we ship).
So yes, forking debTeX would generally be a bad idea and be more work
than it's worth in the normal case. But we still need to be able to do
it.
> > Would it work for you to require the following?
> >
> > - if the whole is named "LaTeX", every changed file must be renamed
> >
> > - if the whole is named something else, files may be changed without
> > renaming
> >
> > (We would need to come up with a suitable definition for "naming", of
> > course.)
>
> if there is provision that a pristine LaTeX is distributed as well so that the
> user has the choice, probably, otherwise I think not.
OK. Now I'd like to hear the Debian side. Here are the conditions for
modification that are being proposed as I understand them:
- you must rename all modified files, or
- you must rename the whole of LaTeX in your modified copy AND
distribute a pristine copy of LaTeX as well.
Comments? Branden, Walter, Mark, and Jeremy, I'm especially interested
in your opinions, since you three are the current objectors.
> i'm also very interested to hear any comments on
>
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00472.html
>
> because that may be a different way to come together.
I have an errand to run and some things to do, but I can reply to that
in more detail. The short version: distributing
foo.c (original) + foo.diff + foo (patched binary)
is a minimal requirement for DFSG 3 and 4 for C files. We have rejected
licenses before that did not allow this (pine, djb-ware).
> by the way, there was a concern that the global filename remapping feature
> could be lost or taken out of LaTeX: the simple answer is "it can't because
> that is something provided by the underlying virtual machine and if the
> license is redrafted suitably (as intended by Jeff who offered to help us here)
> it would be a prerequisite to have LPPL apply in the first place.
>
>
> Personally I think also we could go one step further (though others my call me
> back): already provide two formats
>
> - pristine latex
> - nonportable-latex (for the lack of a better name, for them moment)
>
> where nonportable-latex is a latex-variant format that contains the
> fileremapping feature builtin. Then then for each file type in pristine LaTeX
> there would be a "shadow" file type that could be used to modify things to
> your hearts wishes as long as you use the nonpartable-latex. if properly
> drafted
> it could be assured by LPPL that shadow files can't be restricted from
> modifying in place. would that help?
It sounds like this is a "subcase" of the case I mentioned above, where
you can change the name of LaTeX and distribute a pristine LaTeX, but
then can otherwise modify files without renames for not-LaTeX. Let me
know if I'm missing something.
> I didn't intend to bring that up last time, but really, if you think that the
> proposed conclusion by Jeff is violating DSFG then you have to be honnest
> enough to through out the software by Knuth as well, eg top of cmr10.mf says
>
> % THIS IS THE OFFICIAL COMPUTER MODERN SOURCE FILE cmr10.mf BY D E KNUTH.
> % IT MUST NOT BE MODIFIED IN ANY WAY UNLESS THE FILE NAME IS CHANGED!
>
> in some other thread I pointed out the copyright statements and the licensing
> stuff (which turned out to be in the books by Don that contain the printed
> version of TeX Metafont and the Computer Modern fonts)
>
> Contrary to Walter's and some others believe it is not just a single binary
> that is not allowed to have the name TeX when modified: it is a bunch of
> essential files that form a tex system, without them you don't have something
> that is able to process any documents.
As I mentioned before, the fonts are in a limbo state while we figure
out if we think data files should be required to meet the DFSG. As for
the rest of TeX, I suspect that this will be a future topic of
discussion here.
But whatever the outcome for TeX, if LaTeX is deemed DFSG-free in the
final analysis, you won't have that taken away from you if TeX is moved
to non-free.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: