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:

Thu, 18 Jul 2002 17:54:50 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (298 lines)

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

>So:
>
> - 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 <[log in to unmask]> 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
distribution.

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

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