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:

Frank Mittelbach <[log in to unmask]>

Reply-To:

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

Date:

Tue, 16 Jul 2002 00:36:53 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (177 lines)

Jeff Licquia writes:

 > First of all, this license is nasty.

possibly (not not in spirit only in wording in our opinion)

 > The restrictions on modification
 > are complex; the license itself predicts failure to understand its
 > terms.

well, I hope that could be mended if that is really the case, though I'm not
quite sure that this way of discussion can really help. for the moment I'm
following it nevertheless (ie point after point), probably not being able to
come to the later posts tonight

 > Some of its terms are dependent on external factors that cannot
 > be determined objectively by examining the Program alone.

that should not be the case. we'll see. if so there is indeed something wrong
not sure i have seen you make that explicit

==========================================


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

before this goes totally in the wrong direction, let me clarify here something
up front: the idea of the "maintainers" is something in LPPL 1.3-draft
only. It wasn't there before and it came up during dicussion within the LaTeX
community. I tried to incorporate the wishes expressed there in a very first
draft and it certainly is something that needs further thought.


==========================================


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

ahh, well, but LaTeX core and most of of all the external additions are under
LPPL 1.2 which is like 1.3-draft - maintainer - (something which I really
thought was non-free (by mistake) and for which Richard Stallman gave the idea
to fix it in a free manner)


==========================================

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

that is indeed a big problem, and giving a large proportion of the later part
of the mail shows that what was meant by "file" is not what you (probably
correctly) applied to it as its meaning.

it was for example never intended to be applied to packaging or distribution
methods, eg nobody in the LaTeX world would apply it to anything other those
files that directly influence the results of formatting documents, eg .sty and
.cls files but not something like foo-1.0.tgz

==========================================

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

can you explain why not? that unpacking is actually the crux of the matter in
some sense as in most cases latex related software is distributed in a sort or
archived literate programming form, eg you have foo.dtx and foo.ins, the
latter will generate foo.sty which is important to be identical of different
sites to provide reliability. so what the license ask is when changing
foo.sty give it a new name, even though the .sty is "generated" rather than
already provided, from foo.dtx.

on the other hand, nobody would ask for foo-1.0.tgz to be the only form of
distributing foo

==========================================

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

some history, clarification, and a proposal:

 - that paragraph (and some related ones) were added to LPPL for exactly two
   reasons

   -   to allow certain files to be modifiable with less fuss (no name change)

   -   to prevent .ins files from changes as they were used to add LPPL
       to generated files, eg foo.ins turned foo.dtx into foo.sty by stripping
       comments off and adding a header that added "this file is distributed
       under LPPL ..." to it.

       (on top of GPL there is

 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

       which is the same idea, ie .ins files contain LPPL license pointers)


 - now the second part was a problem for the simple reason that

   a) the way it was written it could have been used to distribute a whole
      program under LPPL without allowing to change anything (not intended by
      us and never done to my knowledge ,but ...)

   b) it would have been better to explicitly say that the generated files are
      part of the program and thus get rid of the issue completely.

 - this is what I tried and that is essentially 1.3-draft (if you forget the
   maintainer part for the moment that came later.

 - what i missed is that with that change (assuming your remark above being
   mistaken) one can (and should) also change the related paragraphs. eg the
   one under the knife right now should only speak about allowing less
   restrictions or perhaps one could through it out completely.

==========================================

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

sorry you lost me. what makes what non-free????  6?


sorry give up for tonight more at some point later

good night
frank

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