Re: LPPL3 violates DFSG9?
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
intended.
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
file.
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)
> BTW, you should number your sections.
probably a good suggestion (definitely for this type of discussion) but also
in general
> > 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?
> > 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.
> > 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
frank
ps you asked about cc. i'm on debian-legal as well so don't need it, are you too?
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: