Re: LaTeX Public Project License, Version 1.3 (DRAFT)
[Please follow up to both lists.]
On Thu, 2002-07-04 at 16:08, C.M. Connelly wrote:
>
> Frank Mittelbach asks that reviews be done of the draft of version
> 1.3 of the LaTeX Public Project License rather than of the current
> version (1.2).
>
> That draft is included below.
First of all, this license is nasty. The restrictions on modification
are complex; the license itself predicts failure to understand its
terms. Some of its terms are dependent on external factors that cannot
be determined objectively by examining the Program alone. In some
cases, the Program may even deceive licensees as to their rights to
modify the Program.
For these reasons alone, I would strongly recommend that this license
not be used.
Additionally, it's pretty clear that the intent of this license is to
create a cabal of "approved" maintainers, and to place "unapproved"
maintainers in a complex legal trap that's easy to trip. Such elitism
is completely against the spirit of the DFSG and the motivations of the
Debian Project, and offends the sensibilities of the whole community.
If LaTeX adopts this license, then I would recommend moving LaTeX to
non-free immediately and forking it if possible to preserve the
(ostensibly free) current status it enjoys.
> Individual files of The Program...
Note that no definition of the word "file" is provided. I believe this
could be construed as a loophole of some kind, and is definitely a flaw
in the license.
Consider Program "foo", distributed as "foo-1.0.tar.gz" under the LPPL.
"foo-1.0.tar.gz" is a file by any reasonable definition, and can be
reasonably construed to not contain additional restrictions beyond the
LPPL. If Debian changes the file name to, say, "foo_1.0.orig.tar.gz",
doesn't it then follow that Debian can change any part of that file at
will?
They attempt to close this loophole below, with the "unpacking" clause.
I don't think they're successful.
> ...may bear supplementary
> and/or superseding conditions on modification of themselves and on the
> distribution of modified versions of themselves, but *no* file of The
> Program may bear supplementary or superseding conditions on the
> distribution of an unmodified copy of the file. A distributor wishing
> to distribute a complete, unmodified copy of The Program therefore
> needs to check the conditions only in this license and nowhere else.
Assuming the LPPL is found to be DFSG-free by itself, it cannot
guarantee that a Program is DFSG-free without reading about each file's
additional restrictions. (Yes, this can be true anyway, but no other
free license I know of explicitly supports this practice, and some
attempt to prevent it.)
> Activities other than distribution and/or modification (including
> maintenance) of The Program are not covered by this license; they are
> outside its scope. In particular, the act of running The Program is
> not restricted.
An important clause, probably taken from the GPL. Its importance will
be clear later.
> You may distribute a complete, unmodified copy of The Program.
> Distribution of only part of The Program is not allowed.
This clause is also important for reasons that will be clear later.
> 3. You must not distribute the modified file with the filename of the
> original file.
>
> 4. In the modified file, you must acknowledge the authorship and
> name of the original file, and the name (if any) of the program
> which contains it.
>
> 5. You must change any identification string in the file to indicate
> clearly that the modified file is not part of The Program.
>
> 6. You must change any addresses in the modified file for the
> reporting of errors in the file or in The Program generally to
> ensure that reports for files no longer maintained by the original
> maintainers will be directed to the maintainers of the modified
> files.
These mandatory modifications may make it non-free. 3, 4, and 5 are
probably OK, but I'm not sure about 6.
> 7. You must distribute the modified file under a license that forbids
> distribution both of the modified file and of any files derived
> from the modified file with the filename of the original file.
This is odious. As people take and modify files, those files will begin
to accumulate "forbidden names" over time. Unless those names are
explicitly listed, the risk will increase over time that someone will
inadvertently reuse a filename and run afoul of this clause.
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?
IMHO, the whole business about filenames should be stripped. One is
already not allowed to distribute modified versions of the Program, and
one is already forced to notify in the file itself when the file is
modified. File names are not endorsements, and should never be
interpreted as such.
> 8. You must do either (A) or (B):
>
> (A) distribute a copy of The Program (that is, a complete,
> unmodified copy of The Program) together with the modified
> file; if your distribution of the modified file is made by
> offering access to copy the modified file from a designated
> place, then offering equivalent access to copy The Program
> from the same place meets this condition, even though third
> parties are not compelled to copy The Program along with the
> modified file;
>
> (B) provide to those who receive the modified file information
> that is sufficient for them to obtain a copy of The Program;
> for example, you may provide a Uniform Resource Locator (URL)
> for a site that you expect will provide them with a copy of
> The Program free of charge (either the version from which
> your modification is derived, or perhaps a later version).
We must, therefore, distribute patches only. This isn't ideal, but it's
not fatal either.
> Note that in the above, `distribution' of a file means making the
> file available to others by any means. This includes, for instance,
> installing the file on any machine in such a way that the file is
> accessible by users other than yourself.
In other words, you are not allowed to hack on LaTeX in a directory that
is world readable, or on a system where more than one person has the
root password, or on any system without access control on files, or in a
directory that is backed up regularly, etc. You are also effectively
forbidden from working on LaTeX as a team; it could be done, but many of
the tools that make teams work (revision control, autobuilders, etc.)
would be very difficult, if not impossible, to set up.
Given RMS's distaste for access controls, could this be construed as
"discrimination against persons or groups"?
> Changing the name of a file (other than as necessitated by the file
> conventions of the target file systems) is considered to be a
> modification of the file.
Since Debian renames the original tarball in its source format, mere
distribution of the Debian source package constitutes a modification
(with the resulting invokation of clauses 1-8). The packager would be
forced, I think, to use DBS to avoid that.
It would be interesting to find out if copyright law supports their
assertion that renaming a file constitutes modification.
> If The Program is distributed in a packed form with a number of files
> to be generated by some unpacking method from the distributed files,
> then these derived files are logically (even if not physically
> present) part of The Program and are covered by this license
> independently of the method of their generation.
This is where the license tries to avoid the loophole described above.
However, remember that:
> Activities other than distribution and/or modification (including
> maintenance) of The Program are not covered by this license; they are
> outside its scope. In particular, the act of running The Program is
> not restricted.
So, if I am allowed to modify and distribute the tarball (as a "file"
under the LPPL), then the user is allowed to unpack the tarball and use
its contents. The user may not have permission to distribute or modify
the files contained in the tarball outside of the tarball itself.
(Although there is no revokation clause, so who knows?)
> An individual file of The Program may bear additional conditions that
> supplement and/or supersede the conditions in this license if, and only
> if, such additional conditions exclusively concern modification of the
> file or distribution of a modified version of the file. The conditions
> on individual files of The Program therefore may differ only with
> respect to the kind and extent of modification of those files that
> is allowed, and with respect to the distribution of modified versions
> of those files.
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. However:
> You may distribute a complete, unmodified copy of The Program.
> Distribution of only part of The Program is not allowed.
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.
> If a file of The Program is intended to be used with LaTeX (that is,
> if it is a LaTeX software file), then the following additional
> conditions, which supplement and/or supersede the conditions
> above, apply to the file according to its filename extension:
>
> - You may not modify any file with filename extension `.ins' since
> these are installation files containing the legal notices that are
> placed in the files they generate.
If those files contain anything besides 100% pure ASCII legal notices
(for example, if they are XML formatted), then this is definitely
non-free, as they force a file format and/or character encoding upon you
regardless of their status as a legal notice.
> The Program has the status `author-maintained' if the Copyright Holder
> explicitly states that The Program can only be maintained by the
> Copyright Holder.
>
> The Program has the status `maintained' if the Current Maintainer has
> made provisions to receive bug reports for The Program (for example,
> by supplying a valid email address). It is not required for the
> Current Maintainer to acknowledge or act upon bug reports.
>
> The Program changes from status `maintained' to `unmaintained' if the
> Current Maintainer of the program cannot be reached through the
> provided means of communication for a period of six months and there
> are no signs of active maintenance otherwise.
However, a change in this status does not automatically cause changes to
the advertised status of the Program within the Program itself. Thus,
it is impossible to say with certainty whether the licensee has any
additional rights due to a Program's advertised status.
> 3b. Otherwise if the Current Maintainer was unreachable and if after
> two months your intention was neither challenged by the Current
> Maintainer nor by other people, you may arrange for a change of
> The Program to reflect you as the (new) Current Maintainer.
Other people may "challenge" a takeover notice. This makes it possible
for a group of people to force an unmaintained program to stay
unmaintained by simply "challenging" any takeover notices. This may
even be possible after the fact if the challenger asserts that the
takeover notice was not posted prominently enough.
The obvious problem is that we need a definition of "challenge", perhaps
in the form of a challenge protocol. There should also be a statute of
limitations concerning challenges; a new Current Maintainer should be
unchallengable after a certain time. (OTOH, that might make it easier
for someone to hijack a program.)
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: