Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 00:13:29 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g61MD9xC030174 for ; Tue, 2 Jul 2002 00:13:09 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g61LwoT8001379; Mon, 1 Jul 2002 23:58:50 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2214C.873DCA80" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id g61M03xn028153; Tue, 2 Jul 2002 00:00:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 2212 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 2 Jul 2002 00:00:16 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id g61LvBxD028101 for ; Mon, 1 Jul 2002 23:57:11 +0200 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g61LtST8000969 for ; Mon, 1 Jul 2002 23:55:28 +0200 (MET DST) Received: from [195.100.229.68] (du72-229.ppp.mh-anst.tninet.se [195.100.229.72]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id XAA26940 for ; Mon, 1 Jul 2002 23:54:37 +0200 (CEST) In-Reply-To: <15641.26508.495316.386198@istrati.mittelbach-online.de> References: <200206260556.g5Q5u4BJ027883@diziet.clawpaws.net> <3.0.6.32.20020621144417.007b3100@mail.uark.edu> <15639.26375.782098.164234@istrati.mittelbach-online.de> <3D17F428.20702@toshiba.co.jp> <15640.43741.596149.994860@istrati.mittelbach-online.de> <200206260556.g5Q5u4BJ027883@diziet.clawpaws.net> Return-Path: X-OriginalArrivalTime: 01 Jul 2002 22:13:29.0390 (UTC) FILETIME=[87794CE0:01C2214C] X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id g61LvBxD028102 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Content-class: urn:content-classes:message Subject: Re: Suggested changes to LPPL Date: Mon, 1 Jul 2002 22:49:57 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Suggested changes to LPPL Thread-Index: AcIhTIek2oexsVS1T52bGOorGsEBcA== From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4233 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2214C.873DCA80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 09.04 +0200 2002-06-26, Frank Mittelbach wrote: >However we never argued against restructuring into different trees or = to >provide the sources only in archived form. In fact i don't even think = that the >license would prohibit to distribute only a runtime version of The = Program (eg >the .sty files) togethwer with an information how to obtain the = complete >documented product (we don't recomment that but i would say it is = allowed) Doesn't the lines You may distribute a complete, unmodified copy of The Program. Distribution of only part of The Program is not allowed. in the LPPL explicitly prohibit making a "runtime files + URL for = sources" distribution? I don't think this can be a real problem for Debian = though, as they could still (as far as the LPPL is concerned) include the = sources only by putting them in an archive on a separate CD labelled "Extras = that hardly anybody installs, so why should you?" if they feel like it. I prefer Frank's proposal of 2002/06/30 to his original, but the wording = in If you are not the Current Maintainer of The Program you are only = allowed to distribute a modified file of The Program if, and only if, the following eight conditions are met: seems to contain an `only' too much. I also got a bit hung up on the = matter of what the Copyright Holder has to do with it all (he's not mentioned = much in the LPPL). It eventually occurred to me that the license is = technically an agreement between the Copyright Holder and the User, which the = Current Maintainer has no part in. Maybe that could be clarified (although I strongly suspect that there is no legal need to do that). Concerning the matter of stating intent, perhaps something like the following could be included in the preamble? The purpose of this License is to grant The User the right to freely obtain, use, and make derivative works based on The Program, whilst at the same time preserving the integrety of The Program. This means that derivative works created by modifying The Program (or any part thereof) must not give the appearance of being part of The Program. The right to modify The Program for the purpose of creating a new version of The Program lies solely with the Current Maintainer of The Program. I have no idea whether the wording might be too strong, but it seems to = me that it captures the intentions of the LPPL (as I understand them; the remarks we have seen so far has been rather vague). With such a = paragraph, one should probably also in the body of the license make clear what one = has to do to ensure that a modified part of The Program does not "give the appearance of being part of The Program". This seems to be what distribution conditions 3, 5, 6, and to some extent condition 7 in the = LPPL are about. The concerns about the old maintainer's last version disappearing when a new maintainer takes over can probably be eased by some simple = precausions at CTAN. What I'm primarily thinking is that when a new maintainer takes over a package, the previous version could be moved to the /obsolete subtree of CTAN. Then it would still be available to everyone while at = the same time in no way appear to be the current version. Finally, when the text for version 1.3 of the LPPL has been decided upon then it would be *very good* if you could make sure that it is approved = as an open source license by the Open Source Initiative. Getting such an approval makes it possible to e.g. use it in a project at SourceForge. Lars Hellstr=F6m ------_=_NextPart_001_01C2214C.873DCA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Suggested changes to LPPL

At 09.04 +0200 2002-06-26, Frank Mittelbach = wrote:
>However we never argued against restructuring = into different trees or to
>provide the sources only in archived form. In = fact i don't even think that the
>license would prohibit to distribute only a = runtime version of The Program (eg
>the .sty files) togethwer with an information how = to obtain the complete
>documented product (we don't recomment that but i = would say it is allowed)

Doesn't the lines

  You may distribute a complete, unmodified copy = of The Program.
  Distribution of only part of The Program is = not allowed.

in the LPPL explicitly prohibit making a "runtime = files + URL for sources"
distribution? I don't think this can be a real = problem for Debian though,
as they could still (as far as the LPPL is concerned) = include the sources
only by putting them in an archive on a separate CD = labelled "Extras that
hardly anybody installs, so why should you?" if = they feel like it.

I prefer Frank's proposal of 2002/06/30 to his = original, but the wording in

  If you are not the Current Maintainer of The = Program you are only allowed to
  distribute a modified file of The Program if, = and only if, the
  following eight conditions are met:

seems to contain an `only' too much. I also got a bit = hung up on the matter
of what the Copyright Holder has to do with it all = (he's not mentioned much
in the LPPL). It eventually occurred to me that the = license is technically
an agreement between the Copyright Holder and the = User, which the Current
Maintainer has no part in. Maybe that could be = clarified (although I
strongly suspect that there is no legal need to do = that).

Concerning the matter of stating intent, perhaps = something like the
following could be included in the preamble?

  The purpose of this License is to grant The = User the right to
  freely obtain, use, and make derivative works = based on The Program,
  whilst at the same time preserving the = integrety of The Program.
  This means that derivative works created by = modifying The Program
  (or any part thereof) must not give the = appearance of being part
  of The Program. The right to modify The = Program for the purpose of
  creating a new version of The Program lies = solely with the Current
  Maintainer of The Program.

I have no idea whether the wording might be too = strong, but it seems to me
that it captures the intentions of the LPPL (as I = understand them; the
remarks we have seen so far has been rather vague). = With such a paragraph,
one should probably also in the body of the license = make clear what one has
to do to ensure that a modified part of The Program = does not "give the
appearance of being part of The Program". This = seems to be what
distribution conditions 3, 5, 6, and to some extent = condition 7 in the LPPL
are about.

The concerns about the old maintainer's last version = disappearing when a
new maintainer takes over can probably be eased by = some simple precausions
at CTAN. What I'm primarily thinking is that when a = new maintainer takes
over a package, the previous version could be moved = to the /obsolete
subtree of CTAN. Then it would still be available to = everyone while at the
same time in no way appear to be the current = version.

Finally, when the text for version 1.3 of the LPPL has = been decided upon
then it would be *very good* if you could make sure = that it is approved as
an open source license by the Open Source Initiative. = Getting such an
approval makes it possible to e.g. use it in a = project at SourceForge.

Lars Hellstr=F6m

------_=_NextPart_001_01C2214C.873DCA80--