LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 16 Jul 2002 00:56:22 +0200
text/plain (414 lines)
At 11 Jul 2002 16:05:14 -0500, Jeff Licquia <[log in to unmask]> wrote:
>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.

What "complex legal trap" would that be? You would probably have to be
careful if you at all costs want to avoid forking, but if you fork then you
can do pretty much whatever you want (as long as it is clear that you have

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

You would probably find the current licence even less free. Richard
Stallman is however (by various LaTeX team members) reported to be content
with it as 'free'.

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

Not really. A file covered by the LPPL is an entity which, in a legal
notice, is claimed to be covered by the LPPL. See the section "How to Use
This License".

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

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

Provided foo-1.0.tar.gz was licensed under the LPPL and, as you suggest,
none of the material archived in it has any additional restrictions then
you would be correct, but the example is hardly relevant.

>They attempt to close this loophole below, with the "unpacking" clause.
>I don't think they're successful.

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

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

The "extensibility" of the license is to simplify matters for those (like,
I suspect, Debian) who are only interesting in distributing an unmodified
copy of The Program. When they see that it is licensed under the LPPL, they
(should) know that they can just make a tarball or whatever of all the
files in it and distribute that. Only those who are interested in modifying
files need to examine these files to see if there is any additional
restriction, and they would anyway have to examine the files when
determining how to modify them.

A Program that has additional conditions on modificaions may indeed be
non-free, but that would not compromise the freeness of other Programs
without these restrictions.

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

What would be the problem? With physical machinery, you as a rule will void
your warranty if you change it without the concent of the manufacturer. I
would say that you would involve yourself in fraudulent proceedings if you
then sell a modifed machine to someone else without clearly informing that
person that the manufacturer is no longer responsible for the machine.
Certainly, with computer programs there are no warranties, but bug reports
serve a similar purpose.

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

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.

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

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


The problem is that history has shown that if modified files exist which
occupy the name of the original then the result is a mess noone wants. The
license imposes conditions on modification to prevent this mess from
arising, by making it considerably more difficult to legally create files
that may be mistaken for files in The Program. It is not foolproof, but it
certainly serves its purpose.

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

Now you're trying to hack without forking. Stop trying---you have nothing
to gain from it!

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

Again: If you want to hack, then make a proper fork first.

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

The Current Maintainers are allowed to work on it as a team. Other people
are adviced to fork before they hack.

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

I seriously doubt anyone has LPPLed a tarball.

>It would be interesting to find out if copyright law supports their
>assertion that renaming a file constitutes modification.

Hmmm... You mean would the courts overrule the definition in the license of
what "modification" means when it is used in that same license? Sounds
silly to me; the license says it does not restrict activites other than
distribution and modification, but if it then defines that renaming is
modification then surely the internally consistent interpretation that
renaming is restricted should apply. Then again, you never knows for sure
with courts.

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

Again, it's normally not the tarball that is LPPLed, but the files it
contains. In addition, some files which may or may not be present in the
tarball (but which definitely can be generated from files in the tarball)
are covered by the LPPL.

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

I take it that this refers to your classification of files as free or
non-free, and a corresponding organisation in different directories.

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

But the tarball is not The Program. 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

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

.ins files are TeX input files that control how .sty, .cls, etc. files are
generated. They are pure ASCII, since any non-ASCII character would be
garbled by TeX when the generated files are written. It would not make
sense to XML format material in these files. (BTW, why should anyone use
XML in this context? We've got LaTeX! :-)

It has however occurred to me these last few days that the license is
probably trying to be too specific in that part. Since I have had nothing
to do with the creation of the license I will not try to defend that part
(we'll have to wait and see if Frank Mittelbach or anyone else of the LaTeX
team wants to defend that passage), but at least I think I can explain the
purpose of imposing a particular restriction on the modification of .ins

The purpose of .ins files are to control the generation of other files, and
it is common that the legal notice for a generated file can be found in the
.ins file which controls its generation. Hence it would not be sufficient
to merely require that .ins files that are modified are renamed, since
running that .ins file could regenerate a file of The Program in an
incorrect manner. An example:

The generation of the infamous `book.cls' is carried out by `classes.ins',
whereas most of the text in `book.cls' is taken from `classes.dtx'. The
only part of `book.cls' which is explicit in `classes.ins' is the legal
notice, which is inserted before the material from `classes.dtx'. Now if
.ins files had no additional restriction on modification then it would be
legal to change its name to `classes2.ins' provided all legal notices in it
are changed; this includes the one which is copied to `book.cls'. The
problem now is however that running this `classes2.ins' will create a
`book.cls' that is not the `book.cls' of The Program, even though it is
clearly a work derived from The Program. It could furthermore be the case
that the incorrect `book.cls' produces results which are different from
those of the original `book.cls'. This can indeed create a complex legal
trap, since it is not immediately clear whether the person running this
`classes2.ins' would be violating the LPPL or not. It is quite possible
that it would not violate the letter of the license, but it would violate
its spirit. Hence the need for additional restrictions.

It is however also the case that some modifications of .ins files may be
desirable. .dtx files may contain variant sections of code and it is
sometimes useful to generate a file with a different set of such variant
sections than the official .ins file does. The natural way of creating the
necessary command for this is to modify the .ins file, but the current (as
well as the draft under discussion for) LPPL prohibits this. It seems to me
that a better restriction would be to say something like

  In addition, all files generated by running a modified .ins
  file must meet the conditions in the license for modified files.

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.

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

Even if challenges are made just to be mean to someone else (or to obstruct
improvements in a program, perhaps to gain relative advantage for a
competing program), one still has the option to fork the program. I doubt
any other scheme could really be useful. What if for example the Copyright
Holder has died in an accident but told a friend the day before that he had
decided to change the maintenance status of the program to
author-maintained, and that the friend therefore challenges all takeover
notices? In this case, accepting the challenge certainly makes less harm
than rejecting it.

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

Those time limitations which you requested are already in place. Challenges
must be made within two months, then the Current Maintainer is changed. As
a special case, the previous Current Maintainer has another six months to
return and make a challenge. That's it.

Lars Hellström