Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 09:32:51 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g637WAxH005007 for ; Wed, 3 Jul 2002 09:32:11 +0200 MIME-Version: 1.0 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 g637K9WK024859; Wed, 3 Jul 2002 09:20:09 +0200 (MET DST) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22263.D62A5380" 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 g633Ba1R004192; Wed, 3 Jul 2002 09:20:40 +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 2500 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 3 Jul 2002 09:20:39 +0200 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 g637KdxD005019 for ; Wed, 3 Jul 2002 09:20:39 +0200 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g637IxWK024573 for ; Wed, 3 Jul 2002 09:18:59 +0200 (MET DST) Received: from [195.100.229.64] (du64-229.ppp.mh-anst.tninet.se [195.100.229.64]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id JAA20200 for ; Wed, 3 Jul 2002 09:18:08 +0200 (CEST) In-Reply-To: <630BE70C8320D6118D240002A589ABB201CB7BB2@DERUM201> Return-Path: X-OriginalArrivalTime: 03 Jul 2002 07:32:51.0942 (UTC) FILETIME=[D6BA1060:01C22263] X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id g637KdxD005020 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 23:49:44 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Suggested changes to LPPL Thread-Index: AcIiY9bd5B2rqPTRRVWEeOjqr1bJGw== 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: 4243 This is a multi-part message in MIME format. ------_=_NextPart_001_01C22263.D62A5380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 16.52 +0200 2002-07-02, Mittelbach, Frank wrote: >Lars wrote: > >>Concerning the matter of stating intent, perhaps something like the >>following could be included in the preamble? > >possibly. some suggested addiotions/changes below > >> 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. > > ... integrety of The Program under its original name. > >> 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. > >perhaps the above sentence is actually not necessary It all depends on how univocal we consider the term `integrety' to be. I fear that it would not by itself be clear enough outside this = discussion, and I suspect the phrase "under its original name" would be of little = help in clarifying it. Furthermore, isn't the name by default part the definition (as found in copyright statements, specifying what the = license applies to) of The Program? In that case, "under its original name" is = at best superfluous. Maybe the paragraph in question should also contain the following = sentences to carify the situation: Derivative works which exhibit any degree of functional equivalence (or lack thereof) to The Program may be created, but such a derivative must be given a name that is distinct from that of The Program. These restrictions exist to protect other users from errors caused by automated processes confusing a derivative work with The Program = proper. At 19.32 +0200 2002-07-02, Frank Mittelbach wrote: >I'm happy if somebody takes up the torch and gets (a variant of) LPPL = approved >by any such body. We tried in 2000 and the results where so frustrating = and >(in my personal opinion) unprofessional that I'm not willing to get = personally >involved into it again, at least not initially. Are there any archives of that discussion? >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_01C22263.D62A5380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Suggested changes to LPPL

At 16.52 +0200 2002-07-02, Mittelbach, Frank = wrote:
>Lars wrote:
>
>>Concerning the matter of stating intent, = perhaps something like the
>>following could be included in the = preamble?
>
>possibly. some suggested addiotions/changes = below
>
>>  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.
>
>  ... integrety of The Program under its = original name.
>
>>  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.
>
>perhaps the above sentence is actually not = necessary

It all depends on how univocal we consider the term = `integrety' to be. I
fear that it would not by itself be clear enough = outside this discussion,
and I suspect the phrase "under its original = name" would be of little help
in clarifying it. Furthermore, isn't the name by = default part the
definition (as found in copyright statements, = specifying what the license
applies to) of The Program? In that case, "under = its original name" is at
best superfluous.

Maybe the paragraph in question should also contain = the following sentences
to carify the situation:

  Derivative works which exhibit any degree of = functional equivalence
  (or lack thereof) to The Program may be = created, but such a derivative
  must be given a name that is distinct from = that of The Program. These
  restrictions exist to protect other users from = errors caused by
  automated processes confusing a derivative = work with The Program proper.

At 19.32 +0200 2002-07-02, Frank Mittelbach = wrote:
>I'm happy if somebody takes up the torch and gets = (a variant of) LPPL approved
>by any such body. We tried in 2000 and the = results where so frustrating and
>(in my personal opinion) unprofessional that I'm = not willing to get personally
>involved into it again, at least not = initially.

Are there any archives of that discussion?

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