Re: LaTeX Public Project License, Version 1.3 (DRAFT)
On Thu, 2002-07-18 at 10:54, Lars Hellström wrote:
> At 06.07 +0200 2002-07-17, Jeff Licquia wrote:
> >The problem is that *most of your good
> >points simply aren't in the license*, and the license is all I can rely
> >on when I try to figure out my rights.
>
> Some of my points certainly refer more to what is the custom (for how the
> license is interpreted) than to what is necessarily in it. Frank has
> however made clear that the entire text of the license certainly is under
> the knife and hence that these points are not clear in the draft isn't,
> IMHO, a serious problem. What most (La)TeX users participating in this
> discussion are interested in isn't primarily that the text of the license
> is preserved, but that the *spirit* of it (as reflected in common practice)
> is.
I think we understand this now. The problem is that a license is a very
poor "community standards" document, just as the law in general is a
very poor "community standards" document. The understandings that you
have amongst yourselves aren't available to newcomers reading your
license for the first time.
> > - no, a "file" is not "something covered by the LPPL".
>
> My point was that the LPPL by itself has no built-in relevance for a file.
> There must also be a legal notice (created by the copyright holder for that
> file) stating that the terms of the LPPL applies for this file. In the case
> of LaTeX (the work), this legal notice is in the file legal.txt, and it
> defines LaTeX (the work) to be the contents of a set of files, which are
> listed by name (in the file manifest.txt). In the case of the `pig' package
> that is used as an example in the LPPL, we find
>
> % This program consists of the files pig.dtx and pig.ins
> % and the derived file pig.sty.
>
> so that there is again a definition of which are the files of The Program.
Yes, but people are not generally distributing two files that generate a
third; they are distributing a tarball. The tarball is a derivative
work of the individual files contained within it, and as such has its
own copyright and licensing questions.
The license is clear that it applies to each of the files in the Program
separately, regardless of their status as part of an archive file. The
problem is that the archive file itself appears to be in a legal limbo.
By default, the archive file is assumed to be covered under the same
license as the files within it; however, the Project thinks of it in a
different way.
Where this becomes important is when a user asserts a right under the
LPPL that you didn't think you had granted.
> > - no, since you aren't allowed to distribute the Program in modified
> >form, non-free "additional restrictions" cannot be removed.
>
> I have not claimed the contrary. A program with additional non-free
> restrictions is not free, but that doesn't say the LPPL by itself is a
> non-free license, just that works that from a _modification_ viewpoint are
> non-free can be _distributed_ under the terms of the LPPL. What we ask is
> that (some version of) the LPPL without additional conditions is approved
> by Debian, not that all possible extensions of the LPPL are approved.
The problem is that our approval of the LPPL by itself tells us very
little. The presence of a single non-free file makes our evaluation of
the LPPL moot, since we cannot (in fact) distribute the combined work
under the LPPL with such a file.
This is one of the things we like about the GPL. When a work is
licensed under it, you know what your rights are with the whole of the
work, with each piece, and with any combinations.
> >> Noone would license foo-1.0.tar.gz under the LPPL. What is licensed under
> >> the LPPL are files archived in foo-1.0.tar.gz.
> >
> >Then the file foo-1.0.tar.gz itself has no license, and cannot be
> >distributed at all.
>
> The matter of whether a file has a license has absolutely no relevance for
> whether it is techincally possible to distribute a file. Is it legally
> relevant? A license certainly grants various rights and so on, but I doubt
> it would be required by any existing legal system. Is it necessary for
> Debian to distribute it? That's mainly a matter of policy.
Actually, pretty much every existing legal system I know of requires a
license to copy any copyrighted file. If you don't have a license, you
can't make verbatim copies and distribute them, period.
> The point of view that I believe to be relevant here is that creating a
> tarball is equivalent to copying the contents to a new file system.
This is an interesting point of view. Unfortunately, it is not
expressly written out in the license as presented. This means that it
has no value as a tool of enforcement; if I choose to interpret the
legal status of the tarball differently, then it becomes a matter for
the courts to decide who's right. And if I can show that my
interpretation is reasonable, then mine could be held to trump yours.
What the court would say to you if you protested would be "well, if
that's what you meant when you said 'file', why didn't you just say that
in the license?" Which is, of course, my point as well.
> The
> owner of the "medium" (a file in another file system) in which this file
> system resides certainly has some rights to it, but licenses guarding files
> in this file system can restrict those rights. The situation is not unlike
> that which the publisher of an anthology is faced with: he has the right
> (largly acquired through various agreements) to print (and so on) the
> anthology, but the rights to the works contained in the anthology remain
> with the authors (or other copyright holders) of these works.
Anthology authors aren't generally concerned with the grant of rights to
third parties or the right to sublicense; generally, anyone who wants
rights to a work is expected to negotiate directly with the authors of
the individual works. By contrast, in free software, nearly everyone is
a third party in relation to the copyright holder, and nearly all rights
are granted through sublicense. This makes the situation much more
complicated.
> >> "Unpacking" may be a suboptimal term in this case. What is primarily meant
> >> is the generation of .sty, .cls, etc. files from (mainly) .dtx files, as
> >> controlled by commands in .ins files. The process is more like the
> >> compilation of some sort of binary from the actual program sources than
> >> unpacking of compressed data. The reason the LPPL uses this term is
> >> probably that there has traditionally been two kinds of LaTeX
> >> distributions: "packed" (not including any generated files) and "unpacked"
> >> (including generated files, as well as their sources).
> >
> >I would agree. How to solve this is tricky, though, since technically
> >these generated files are "the output of the program" in one sense.
> >Obviously, you don't want to limit people's ability to process LaTeX
> >documents into camera-ready output.
> >
> >You could, perhaps, define "results of building the Program" and "output
> >from using the Program", and limit them differently.
>
> The view taken in the LPPL is, although it may certainly need clarification
> in the license text, that the generated files are principally part of The
> Program, even though they need not actually be present in a copy of The
> Program for that to be complete. The idea that a program may have such
> virtual components could be seen as suspicious, but a compiled binary is in
> a similar sense virtually present in the sources. That the names of these
> virtual components need to be protected could however be a messy point.
>From the GPL:
The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
Maybe that would work for the LPPL, as well.
> >Actually, the modified file must still honor the original license unless
> >explicitly granted permission not to.
>
> Judging from what the GPL says, I would rather think it is the other way
> round. The GPL explicitly requires derivative works to be licensed under
> the GPL, whereas the LPPL does nothing of the sort, except for the minor
> restriction in clause 7.
Not necessarily.
The GPL's verbiage about derived works mostly relates to combining
external works with the licensed work in some way. In that regard, the
total combined work must be licensed under the GPL, even if components
of that work have more liberal licenses. However, the copyright
interests of the other work do not disappear, and I must respect the
license on it regardless of my obligations under the GPL.
By contrast, the LPPL grants me the right to modify files subject to
certain conditions. It makes no statements about what modification
terms I am able to relax in my modified version; it simply requires that
the modified file must not carry the same name as the original. Since
both the developer and the LaTeX Project carry copyright in the modified
file, both licenses must be upheld. So, while I am free to add
restrictions to the modified file (because of my copyright in my
changes), I am not able, unilaterally, to change the terms on the LaTeX
Project's code - except for the distribution conditions, where I am
granted express permission to.
The trick is figuring out how the LPPL applies to modified works. Do I
need to keep track of all filenames used in all revisions, or can I just
exempt the first filename? The license doesn't say, and is a bit
confusing on this front, since it covers "files" and not identifiable
works.
> >However, you will note that the clause applies to distribution
> >conditions only. No clause of the license covers what conditions
> >modified files may be modified under. Therefore, the only rights you
> >have regarding modification are rights under the LPPL, which require
> >another name change.
>
> You're mistaken. That paragraph is about whether you should use the LPPL
> _at_all_. Any conditions in addition to those in the LPPL may not concern
> distribution.
But what rights may I give third parties concerning modification? The
license doesn't say (except that it requires that I forbid third parties
from ever using the original file name).
It's clear that I can strip out all of the distribution requirements of
the LPPL short of the filename restriction. However, the only
modification license I have available to pass on to third parties is the
LPPL, and I am not given permission to drop any of the modification
requirements when I pass it on. So, when a third party wants to modify
my modified file, they too must conform to the modification
restrictions, which includes renaming the file.
> >Lack of perfection is not a valid excuse to shrug off criticism. We're
> >not asking for theoretical perfection; we're asking you to fix a finite,
> >explicit list of problems.
>
> It's strange to see this described as a problem. Branden Robinson seems to
> think that any restriction on how a modified file can be named is too much,
> whereas you now seem to call for additional restrictions.
I am not calling for additional restrictions; I am simply pointing out
the restrictions that exist. I share Branden's opinion that it would be
best to do away with the file naming thing entirely.
> True, but when different rights contradict each other then one has to find
> a balance between them. There is no restriction on people's right to mess
> up the layout of _their_ documents. The restriction is rather directed
> towards system administrators, and forbids them to take advantage of The
> Program if they want to mess up the layouts of (potentially) _all_
> documents typeset on that system. It is a minor freedom (because its
> absence does not restrict the output that can be produced) that the
> licensee gives up to gain the right to use The Program.
This paragraph has been disproven already by others, so I won't discuss
it beyond observing that such a restriction on sysadmins as stated fails
the DFSG.
> >Again, assuming they're allowed to fork (which, I will point out, is
> >still unproven).
>
> What would you need as a proof of this? A court verdict? The LPPL draft
> clearly states that "If you are not the Current Maintainer of The Program
> you _are_ [my emphasis] allowed to distribute a modified file of The
> Program if the following eight conditions are met:".
Yes, and several of these effectively prevent forking at first glance.
That may not have been the intent, but it certainly seems to be the
actual fact of the matter.
What we are looking for are clear, simple statements about what we are
allowed to do. The intent is to avoid going to court over something we
thought we could do but couldn't, or to avoid removing the software
entirely because of something that we must do but think we can't.
> >> >Thus, the presence of even a single non-free file will pollute the
> >> >entire Program's legal status, since we aren't allowed to remove it.
> >>
> >> But the tarball is not The Program.
> >
> >Again, this is unproven.
>
> Again, what would you accept as a proof? Anyhow, I agree that you could
> have such a pollution of the legal status. OTOH, I believe the practice for
> the LPPL is that it is OK to move the non-free files from one tarball and
> into another. The tarball with only free files can be placed in a free
> tree, whereas the tarball with only the non-free files can be placed in a
> /nonfree tree.
I don't doubt that this is considered acceptable by the Project. But
(as I've said before), you need to make this clear in the license.
> >Also, technically, hard links and symlinks aren't files (at least, not
> >under my definition of "file"; do you understand the importance of
> >definitions yet?). So:
> >
> > /usr/share/latex/article.sty -> /usr/share/latex/article-hacked.sty
> >
> >would be allowed under this interpretation of the license. Bada boom,
> >bada bing; I've just subverted the Project's stated goals within the
> >terms of the license. :-)
>
> As I understand the UNIX file system, there is no difference between a hard
> link and a file (as one would encounter it on simpler file systems); making
> a hard link is simply assigning another name to a file. Soft links are, I
> agree, trickier. Perhaps it should be made clear that it is not really the
> native file system names that are of interest, but the names seen from
> inside TeX.
Part of what has helped the progression of the debate has been the
realization that we are allowed to change TeX's view of the file, so
invoking the "article" class in a document could cause an entirely
different file from "article.cls" to be referenced. (As long as our
hacked LaTeX is not called LaTeX, of course.)
It would seem that this clarification would destroy that right.
> >Legal notices can be invariant; there's no problem there. (Though
> >questions of charset conversion and the like may be important; I don't
> >know. Are legal notices stored in TeX-style, or do you actually embed
> >UTF-8 or ISO-8859-1 or whatever in them?)
>
> I suppose they _are_ TeX-style, whenever we see a need to go beyond ASCII,
> but since the text is usually English that rarely happens. The reasons for
> this are mainly technical, though. The generated files have to be written
> by TeX, and normal TeXs only output visible ASCII characters and newlines,
> whereas other characters get converted to ^^-sequences. teTeX (and probably
> many other implementations) have command line switches for overriding the
> translation table that is responsible for this, but that's not standard. I
> think Omega can write UTF-8, UTF-16, or whatever, but that is at best
> something for the future.
The important thing is that the legal notices not lock the user into a
certain character encoding due to their invariance. It would be a shame
to force ISO-8859-1 on users long after everything else had switched to
Unicode, or to require that a particular platform be excluded because it
only works with Unicode UCS-2 instead of the UTF-8 in the .ins files.
This would work similarly to the exception on filenames where you allow
for filenames to change to accomodate limitations in the file system.
However, if you store i18n stuff in TeX form, and translate it at build
or run time, then there's no problem, I would imagine.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: