[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LaTeX Public Project License, Version 1.3 (DRAFT)

At 06.07 +0200 2002-07-17, Jeff Licquia wrote:
>You made some good points.

Thank you.

>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)

> - 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, a tarball is a file by the normal definition of "file".
> - 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.

>If you don't agree, then point out the sections of the license that
>explicitly disagree with this assessment.
>On Mon, 2002-07-15 at 17:56, Lars Hellström wrote:
>> At 11 Jul 2002 16:05:14 -0500, Jeff Licquia <licquia@debian.org> wrote:
>> >Consider Program "foo", distributed as "foo-1.0.tar.gz" under the LPPL.
>> 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.

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. 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.

>> "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.

>> I'd say the clause _requires_ you to list them, since the license for the
>> modified file would not otherwise fulfill the conditions. The person
>> modifying an already modified file is not bound by the license of the
>> original file, but only by that of the modified file, and thus it would be
>> the one who offers an incorrect license for a modified file that is in
>> violation of the license of the original file.
>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.

>This paragraph appears to grant that permission:
>> If for any part of your program you want or need to use *distribution*
>> conditions that differ from those in this license, then do not refer to
>> this license anywhere in your program but instead distribute your
>> program under a different license.  You may use the text of this license
>> as a model for your own license, but your license should not refer to
>> the LPPL or otherwise give the impression that your program is
>> distributed under the LPPL.
>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

>> >Further, the prospect of combining two files into one presents itself.
>> >Such a file would have to avoid any file name used for any previous
>> >version of either of the two files.
>> >
>> >Determining derivation could also be a problem.  If two separate
>> >branches of development use the same filename, who wins?
>> That matter is not regulated in the LPPL, and there is probably no way of
>> doing that either. Noone has claimed that it would make the world perfect.
>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.

To require uniqueness of name throughout a tree of development is something
very tricky to implement and requires a regulatory body of some sort. Who
would be prepared to function as such? Observe that persons do in general
only make agreements with their neighbours in this tree. The tree may
certainly have a unique root, but the person at the root is on the other
hand normally not expected to even know who his neighbours in the tree are!

>Indeed, it would seem that if it's impossible for a license to avoid
>ambiguity, that could be seen as a fundamental flaw in a license.  Of
>course, some licenses are intended to be ambiguous, so that the
>copyright holder has latitude in prosecuting users at a whim.  For free
>licenses, though, ambiguity is considered bad.

What you describe is not an ambiguity in what rights or responsibilities
anyone has under the license, and hence it is not open to any of the
problems you describe in that paragraph.

>However, you're also limiting people's ability to improve the software
>when you limit their ability to muck it up.  Freedom is about not having
>to ask people's permission to think differently, or even to be wrong.

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.

>> The Current Maintainers are allowed to work on it as a team. Other people
>> are adviced to fork before they hack.
>No elitism here, surely.

Depends on your point of view. In old Swedish politics (the middle ages to
roughly the 1860s), a common pattern was that the king went in alliance
with the peasantry, against the Nobility, who wanted to control the state
themselves. Kings that did this were usually not that popular amongst the
Nobility and "elitism" might well have been used as a summary of the
criticism against the Governments of these kings. Of course this digression
needs not have any relevance for the present discussion, but it shows that
"elitism" is often something rather subjective. :-)

>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:".

>> >If any files within the Program did happen to contain additional
>> >restrictions that made the file non-free, then the file would have to be
>> >removed from the tarball before it could be uploaded to main.
>> I take it that this refers to your classification of files as free or
>> non-free, and a corresponding organisation in different directories.
>No.  It refers to our classification of *packges* as free or non-free.
>Furthermore, non-free packages are not part of Debian proper; they do
>not receive the same support and QA, generally speaking.

I was close enough, then.

>We do not distribute individual files from "projects"; we distribute
>them in aggregate form, usually in the same form we receive them from
>upstream software authors.
>> >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.

>> Nor is it required that the files of
>> The Program are given any particular organisation into a specific directory
>> structure or even that all of The Program resides on the same physical
>> medium.
>The implication of this assertion is that I can remove any file I wish,
>even though I can't change them without the whole renaming business.
>That seems to contradict the Project's goal that LaTeX work in a
>predictable manner on all systems that have it.  If you can't predict
>that the "article" object will be available when you need it, then
>that's a pretty serious deficiency.

It is a very noticable error when such an object is missing; I believe
Frank has covered why this is not a severe problem in his posts.

>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.

>> Hence `classes2.ins' would not be allowed to generate an incorrect
>> `book.cls', but it would be allowed to generate any `book2.cls'. Whether
>> `classes2.ins' could also be allowed to generate a `book.cls' with the
>> original legal notice is a trickier matter. I don't see that it would
>> compromise the integrity of The Program, and it could be useful to supply a
>> different argument to \usedir, but there could also be problems with it.
>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.

Lars Hellstr\"{o}m

To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: