LISTSERV mailing list manager LISTSERV 16.0

Help for LATEX-L Archives


LATEX-L Archives

LATEX-L Archives


LATEX-L@LISTSERV.UNI-HEIDELBERG.DE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

LATEX-L Home

LATEX-L Home

LATEX-L  July 2002

LATEX-L July 2002

Subject:

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

From:

Lars Hellström <[log in to unmask]>

Reply-To:

Mailing list for the LaTeX3 project <[log in to unmask]>

Date:

Tue, 16 Jul 2002 00:56:22 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (413 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
forked).

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

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.

Endorsements???

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.

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

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

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

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

September 2019
July 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
February 2018
January 2018
December 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
July 2016
April 2016
March 2016
February 2016
January 2016
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
September 2012
August 2012
July 2012
June 2012
May 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
September 2007
August 2007
June 2007
May 2007
March 2007
December 2006
November 2006
October 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
November 2005
October 2005
September 2005
August 2005
May 2005
April 2005
March 2005
November 2004
October 2004
August 2004
July 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
October 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
October 2002
September 2002
August 2002
July 2002
June 2002
March 2002
December 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996

ATOM RSS1 RSS2



LISTSERV.UNI-HEIDELBERG.DE

Universität Heidelberg | Impressum | Datenschutzerklärung

CataList Email List Search Powered by the LISTSERV Email List Manager