Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Tue, 2 Jul 2002 20:24:02 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g62INJxH002634 for ; Tue, 2 Jul 2002 20:23:20 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g62IB6WK012640; Tue, 2 Jul 2002 20:11:06 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C221F5.A3E20D00" 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 g625W1Gx029395; Tue, 2 Jul 2002 20:12:46 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 3374 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 2 Jul 2002 20:12:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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 g62ICjxD002261 for ; Tue, 2 Jul 2002 20:12:45 +0200 Received: from moutng0.schlund.de (moutng0.kundenserver.de [212.227.126.170]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g62IB4T8029487 for ; Tue, 2 Jul 2002 20:11:04 +0200 (MET DST) Received: from [212.227.126.160] (helo=mrelayng0.kundenserver.de) by moutng0.schlund.de with esmtp (Exim 3.22 #2) id 17PRlI-0006rm-00 for LATEX-L@listserv.uni-heidelberg.de; Tue, 02 Jul 2002 19:48:24 +0200 Received: from [80.129.3.20] (helo=istrati.mittelbach-online.de) by mrelayng0.kundenserver.de with asmtp (Exim 3.35 #1) id 17PRlI-0002EX-00 for LATEX-L@listserv.uni-heidelberg.de; Tue, 02 Jul 2002 19:48:24 +0200 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g62Hkt031177; Tue, 2 Jul 2002 19:46:55 +0200 In-Reply-To: <200207020903.10740@KOMA> References: <3.0.6.32.20020621144417.007b3100@mail.uark.edu> <200207012144.16831@KOMA> <15648.50391.890690.544946@istrati.mittelbach-online.de> <200207020903.10740@KOMA> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 02 Jul 2002 18:24:02.0185 (UTC) FILETIME=[A3FE4790:01C221F5] X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f 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: Tue, 2 Jul 2002 18:46:55 +0100 Message-ID: A<15649.59151.317445.567416@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Suggested changes to LPPL Thread-Index: AcIh9aQjV92kGLKZRKKEWTPHAanu4g== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4239 This is a multi-part message in MIME format. ------_=_NextPart_001_01C221F5.A3E20D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Markus Kohm writes: > > just look at the many packages around on ctan with copyright = notices of > > some sort (prior to lppl) that are "authorless" by now. > > Don't think about packages prior to lppl because the problem will = stay there > even after changing lppl. i was giving that as an example for a situation that you may not want to = make worse. I was not indicating that one can do anything about such files = (other than chasing down their authors and talk to them) > Current lppl already gives a chance to friendly overtake an = unsupported > package: rename it. of course. but do you want to every time rename a package just because = people vanish? of course you can do that as a last resort, but it is rather counterproductive unless the original author really does wish this. And = i think the general feeling (and that is why Donald brought this up) is = that in most cases the original authors would be quite happy to see their = packages maintained after they stop, while at the same time they see a need to = put it under LPPL (instead of GPL) to insure integrety. frank ------_=_NextPart_001_01C221F5.A3E20D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Suggested changes to LPPL

Markus Kohm writes:
 > > just look at the many packages around = on ctan with copyright notices of
 > > some sort (prior to lppl) that are = "authorless" by now.
 >
 > Don't think about packages prior to lppl = because the problem will stay there
 > even after changing lppl.

i was giving that as an example for a situation that = you may not want to make
worse. I was not indicating that one can do anything = about such files (other
than chasing down their authors and talk to = them)

 > Current lppl already gives a chance to = friendly overtake an unsupported
 > package: rename it.

of course. but do you want to every time rename a = package just because people
vanish? of course you can do that as a last resort, = but it is rather
counterproductive unless the original author really = does wish this. And i
think the general feeling (and that is why Donald = brought this up) is that in
most cases the original authors would be quite happy = to see their packages
maintained after they stop, while at the same time = they see a need to put it
under LPPL (instead of GPL) to insure = integrety.

frank

------_=_NextPart_001_01C221F5.A3E20D00--