Re: LPPL3 violates DFSG9?
On Wed, 2002-07-24 at 16:19, Frank Mittelbach wrote:
> David Turner writes:
> > OK, how about the following:
> > As a special exception to the section titled CONDITIONS ON DISTRIBUTION
> > AND MODIFICATION ("Section 57"), you may modify the Program by
> > processing them with automated translation and compilation tools
> > ("Tools") to generate derivative works ("Generated Files"), and
> > distribute these modifications. under the following conditions:
> > 1. The Tools must copy all copyright notices in the Program into the
> > Processed Files.
> > 2. The terms of this license (other than Section 57, paragraphs 5
> > through 8) are followed with respect to Generated Files.
> something along those lines might be better then the a reworked
> original,though I think (at first glance) it doesn't really convey what is
> Let me explain. LaTeX type software doesn't have "binaries" in the traditional
> sense, but it has "run-time" files as well as source files. As the run-time
> files are still ASCII there is no clear cut, ie you can have a single file
> with comments acting both as your source but being also used as the run-time
> Usually source files are converted into runtime files by short TeX programs
> that do not typeset anything but act like scripts or "compilers" (the beauty
> of this kind of scripting (or unpacking as we usually say) is that it works on
> any platform that has TeX; and if the platform doesn't has TeX then LaTeX
> doesn't make much sense either --- but i get carried away). The scripts
> combine source files remove comments, may rearrange bits and pieces and write
> the result out to a new file. so, for example, a typical small work might
> consist of
> foo.dtx % the real source
> foo.ins % the script
> and when running
> tex foo.ins
> then foo.sty is generated from foo.dtx by reading the latter file and
> outputing the former. With bigger works the situation might be more
> complicated, eg, the runtime files for the latex kernel are generated from
> many sources using a master .ins file and several sub-scripts but the concept
> is the same: you have a number of source files and a number of "binary" files
> within your work. For the sake of keeping distributions small, often only
> the source + scripts is distributed, but the main files to which LPPL has to
> apply are in fact those run-time files which are "implicit" present.
> This is like distributing C source plus Makefile
> Now the intention of this pargragraph was or is to enclose the those "binary"
> files into the definition of what are the files comprising the work (and thus
> the files the license has to apply to as well)
Don't the relavent parts of the license automatically apply to
derivative works? If so, you don't need this section at all.
> > > In fact the whole issue that let to this paragraph only did arise because we
> > > tried to allow distribution of source without binary to save distributors
> > > space (except that with LaTeX run-time files aren't really binaries so that I
> > > perhaps unwisely used the word "unpacking" here cause that is what people
> > > usually call the process of generating from some .dtx files some .sty files).
> > That's part of it. Frankly, the whole paragraph is rather incoherent,
> > especially the part in parens.
> the paragraph above or the paragraph in the license?
The paragraph in the license, sorry.
> > > Does that resolve that problem?
> > I'm still a bit confused about the nature of the problem, so, maybe.
> hope the above explanation (given abit earlier in theday :-) makes it
> clearer. Perhaps after that you have another suggestion for rewording.
I'm still a bit confused. You want to allow people to distribute
sources without the files generated from them. OK, you don't need any
special magic for that. But you also want to allow people to generate
files from these sources in some standard (?) way. OK, that's allowed
by your other terms. And you want these generated files to (if
distributed) obey some requirements. What requirements, exactly? And
> > > to me that falls under minor corrections to be sorted out with Jeff et al
> > > after there is finally a decision whether or not it is worth doing so in the
> > > first place
> > Well, I think it is worth doing anyway -- unclear terms are never good
> > for a license, whether or not Debian likes it.
> you are right, of course.
> thanks for the input
> ps you asked about cc. i'm on debian-legal as well so don't need it, are you too?
GPL Compliance Engineer
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com