Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 10:09:55 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g6389DxH005114 for ; Wed, 3 Jul 2002 10:09:14 +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 g637wBT8005182; Wed, 3 Jul 2002 09:58:11 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22269.03C5CB80" 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 g633Ba2R004192; Wed, 3 Jul 2002 09:59:48 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 2553 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 3 Jul 2002 09:59:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id g637xmxD005254 for ; Wed, 3 Jul 2002 09:59:48 +0200 Received: from spmler3.mail.eds.com (spmler3.mail.eds.com [194.128.225.186]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g637w8WK006164 for ; Wed, 3 Jul 2002 09:58:08 +0200 (MET DST) Received: from spmlir1.mail.eds.com (spmlir1-2.mail.eds.com [205.191.69.199]) by spmler3.mail.eds.com (8.11.6/8.11.3) with ESMTP id g637w3I10816 for ; Wed, 3 Jul 2002 07:58:03 GMT Received: from nnse.eds.com (localhost [127.0.0.1]) by spmlir1.mail.eds.com (8.11.6/8.11.6) with ESMTP id g637w2U30507 for ; Wed, 3 Jul 2002 07:58:03 GMT Received: from gbspm001.exemhub.exch.eds.com ([207.37.51.199]) by nnse.eds.com (8.11.6/8.11.6) with ESMTP id g637w0q13494 for ; Wed, 3 Jul 2002 08:58:01 +0100 (BST) Received: by GBSPM001 with Internet Mail Service (5.5.2653.19) id <3CKH09FW>; Wed, 3 Jul 2002 08:57:55 +0100 Return-Path: X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 03 Jul 2002 08:09:55.0366 (UTC) FILETIME=[03FDA460:01C22269] x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id g637xmxD005255 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Content-class: urn:content-classes:message Subject: AW: Suggested changes to LPPL Date: Wed, 3 Jul 2002 08:57:57 +0100 Message-ID: A<630BE70C8320D6118D240002A589ABB201CB7BB5@DERUM201> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: Suggested changes to LPPL Thread-Index: AcIiaQQ9MPy733rUSiWRFu29TXEYMQ== From: "Mittelbach, Frank" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4244 This is a multi-part message in MIME format. ------_=_NextPart_001_01C22269.03C5CB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable let me clarify that statement a bit. i fully agree that larger projects would benefit from something like sourceforge (the kernel would, for example, and so would something like fontinst, koma and a small number = of others). but i was only trying to point out that this is not the case = with the majority of the lppl related software. frank -----Urspr=FCngliche Nachricht----- Von: Lars Hellstr=F6m [mailto:Lars.Hellstrom@MATH.UMU.SE] Gesendet: Mittwoch, 3. Juli 2002 00:50 An: LATEX-L@listserv.uni-heidelberg.de Betreff: Re: Suggested changes to LPPL >as an aside: which life is made unnecessarily complicated? I'm not = aware of a >single software project under LPPL which would really gain anything = from >living on something like Sourceforge. I'm not saying that it wouldn't = be good >if LPPL is approved, on the contrary, but i don't see Sourceforge and = the like >as a real practical argument. I beg to disagree; any software project large enough would certainly benefit from living on _something_ like SourceForge. I agree most = projects governed by the LPPL only have one developer and these would probably = not benefit from it, but as soon as the project becomes larger than what one developer can effectively maintain you do get a problem. Experience has shown that a centralised server somewhere that holds _the_ current = version of the project and which all developers can access over the internet removes much of this problem. Presumably latex-project.org provides something of the sort for the LaTeX project, but setting up a completely new site seems to me as a bit of overkill for reasonably sized projects. = It ought to be more effective to use one of the generic services that are currently available. CTAN, for one thing, does not suffice as a development server. As its = name indicates, it's an archive. Putting things on it requires communicating with and the manual intervention of the archive administrators, which = means you hardly ever upload anything you plan to continue working on = tomorrow, and that takes away much of the usefulness of the central development server. Maybe CTAN can be complemented by a "development hotel" such as SourceForge, but at least to me that sounds like more work than getting = the LPPL approved. In case you want a concrete example of a project then I've got that as well: fontinst. I have on occation considered suggesting setting up a fontinst project at SF, but the fact that the LPPL isn't approved has stopped from pursuing that possibility. (IMHO it is a major problem for fontinst that there isn't such a central server, because it really has become too large for any of the persons involved to maintain on one's = own. The only components I've ever effectively maintained is the DTXs from = which fontinst.sty is generated. The latin alphabet MTXs and ETXs would = probably be far better maintained by Walter Schmidt, since he is anyway their top user due to PSNFSS. The cyrillic alphabet MTXs and ETXs should be part = of the fontinst distribution, but the author of those is Vladimir Volovich, which means he is the logical maintainer. And so on. But I digress.) In view of the recent discussion on why the LPPL is different from the GPL = one could of course draw the conclusion that fontinst should not (unlike = most LaTeX packages) be LPPLed, but I would prefer that it stayed under the LPPL, if possible. Lars Hellstr=F6m ------_=_NextPart_001_01C22269.03C5CB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Suggested changes to LPPL

let me clarify that statement a bit. i fully agree = that larger projects
would benefit from something like sourceforge (the = kernel would, for
example, and so would something like fontinst, koma = and a small number of
others). but i was only trying to point out that this = is not the case with
the majority of the lppl related software.

frank

-----Urspr=FCngliche Nachricht-----
Von: Lars Hellstr=F6m [mailto:Lars.Hellstrom@MATH.UMU= .SE]
Gesendet: Mittwoch, 3. Juli 2002 00:50
An: LATEX-L@listserv.uni-heidelberg.de
Betreff: Re: Suggested changes to LPPL

>as an aside: which life is made unnecessarily = complicated? I'm not aware of
a
>single software project under LPPL which would = really gain anything from
>living on something like Sourceforge. I'm not = saying that it wouldn't be
good
>if LPPL is approved, on the contrary, but i don't = see Sourceforge and the
like
>as a real practical argument.

I beg to disagree; any software project large enough = would certainly
benefit from living on _something_ like SourceForge. = I agree most projects
governed by the LPPL only have one developer and = these would probably not
benefit from it, but as soon as the project becomes = larger than what one
developer can effectively maintain you do get a = problem. Experience has
shown that a centralised server somewhere that holds = _the_ current version
of the project and which all developers can access = over the internet
removes much of this problem. Presumably = latex-project.org provides
something of the sort for the LaTeX project, but = setting up a completely
new site seems to me as a bit of overkill for = reasonably sized projects. It
ought to be more effective to use one of the generic = services that are
currently available.

CTAN, for one thing, does not suffice as a development = server. As its name
indicates, it's an archive. Putting things on it = requires communicating
with and the manual intervention of the archive = administrators, which means
you hardly ever upload anything you plan to continue = working on tomorrow,
and that takes away much of the usefulness of the = central development
server. Maybe CTAN can be complemented by a = "development hotel" such as
SourceForge, but at least to me that sounds like more = work than getting the
LPPL approved.

In case you want a concrete example of a project then = I've got that as
well: fontinst. I have on occation considered = suggesting setting up a
fontinst project at SF, but the fact that the LPPL = isn't approved has
stopped from pursuing that possibility. (IMHO it is a = major problem for
fontinst that there isn't such a central server, = because it really has
become too large for any of the persons involved to = maintain on one's own.
The only components I've ever effectively maintained = is the DTXs from which
fontinst.sty is generated. The latin alphabet MTXs = and ETXs would probably
be far better maintained by Walter Schmidt, since he = is anyway their top
user due to PSNFSS. The cyrillic alphabet MTXs and = ETXs should be part of
the fontinst distribution, but the author of those is = Vladimir Volovich,
which means he is the logical maintainer. And so on. = But I digress.) In
view of the recent discussion on why the LPPL is = different from the GPL one
could of course draw the conclusion that fontinst = should not (unlike most
LaTeX packages) be LPPLed, but I would prefer that it = stayed under the
LPPL, if possible.

Lars Hellstr=F6m

------_=_NextPart_001_01C22269.03C5CB80--