Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Jul 2002 12:28:16 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g69ARfWi028601 for ; Tue, 9 Jul 2002 12:27:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22733.56086000" 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 g69AGFWK026995; Tue, 9 Jul 2002 12:16:16 +0200 (MET DST) 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 g68M047d023635; Tue, 9 Jul 2002 12:16:05 +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 4108 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 9 Jul 2002 12:16:05 +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 g69AG5xD027413 for ; Tue, 9 Jul 2002 12:16:05 +0200 Received: from smtp.wanadoo.es (smtp5.wanadoo.es [62.37.236.139] (may be forged)) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g69AEfWK026473 for ; Tue, 9 Jul 2002 12:14:41 +0200 (MET DST) Received: from [62.37.82.89] (62-37-82-89.dialup.uni2.es [62.37.82.89]) by smtp.wanadoo.es (8.11.6/8.11.6) with ESMTP id g69ADjs10512 for ; Tue, 9 Jul 2002 06:13:45 -0400 In-Reply-To: <20020708123501.B23884@lucien.kn-bremen.de> Return-Path: X-OriginalArrivalTime: 09 Jul 2002 10:28:16.0349 (UTC) FILETIME=[563DA0D0:01C22733] User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Content-class: urn:content-classes:message Subject: Re: LPPL under review at savannah.gnu.org Date: Tue, 9 Jul 2002 11:15:23 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LPPL under review at savannah.gnu.org Thread-Index: AcInM1Z3SSC0h511SfS4Ttrr9kQPXg== From: "Javier Bezos" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4262 This is a multi-part message in MIME format. ------_=_NextPart_001_01C22733.56086000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm reading the discussion and I must confess that I'm finding it quite frustrating (except the amusing message by Tim). I don't understand the schizophrenic obsesion about the name, which is irrelevant in most of cases, but that in LaTeX can be important; as a poster said > So, in any > case, if we what, we can do what we want in the GPL way with a > LPPL file. We are at an impasse. Some comments (I don't know anything about law, sorry if I say some stupidity): > Those compatibilities reasons evoqued by the latex project seems > to me nonsense: no one can forbid me to write a book.cls, from > scratch, that would be incompatible with the standard book.cls. That makes sense, but afaik the LPPL doesn't say that. However, I think a clear distinction should be made between the LPPL and the CTAN policy. CTAN won't accept a class/package whose name clashes with the name of an existing class/package, except if the author cannot be reached, etc. The main problem is that the CTAN maintainers will have an extra work, except if the steps are automated in the following way: when uploading a supported package you must provide clearly an e-mail address where you can be reached, if after three months the CTAN Team doesnt get an answer, the old version wil be moved to an obsolete tree (and in turn removed after a year) and you will become the current maintainer (with some kind of standard form). Note that these steps have nothing to do with the LPPL, and a CTAN Policy document could be released as well, with cross references as notes in both documents. IMO, this restriction will encourage new names for classes/packages since the main (almost the sole) way to distribute them is CTAN. > The LaTeX Project Public License. [...] > > This license contains complex and annoying restrictions on how to = publish a > modified version, including one requirement that falls just barely on = the good > side of the line of what is acceptable: that any modified file must = have a new > name. > > The reason this requirement is acceptable for LaTeX is that LaTeX has = a > facility to allow you to map file names, to specify ``use file bar = when file > foo is requested''. With this facility, the requirement is merely = annoying; > without the facility, the same requirement would be a serious = obstacle, and we > would have to conclude it makes the program non-free. I must confess I don't understand why that makes a program non-free. But I agree that in some cases a variant of book could be useful -- a prepress house could have a book which loads, say, hyperref because the target document is always pdf, and why not to allow its distibution if, as stated in the GPL, this files is clearly identified as a modified file. (Maybe by requiring a \ModifiedPackage macro, in the same line as the proposal by Hans. However, I don't know if that's compatible with GPL.) This class, of course, won't be accepted in CTAN. > The LPPL says that some files, in certain versions of LaTeX, may have > additional restrictions, which could render them non-free. For this = reason, it > may take some careful checking to produce a version of LaTeX that is = free > software. I think, again, that makes sense. If LPPL can be extended freely, it's more a "draft of license" than an actual license. > The LPPL makes the controversial claim that simply having files on a = machine > where a few other people could log in and access them in itself = constitutes > distribution. We believe courts would not uphold this claim, but it is = not > good for people to start making the claim. Again, that makes sense to me. > Please do not use this license for any other project And that demonstrates my point about the obsesion against LPPL. > Instead a specification was issued > (http://www.opengroup.org/onlinepubs/007908799/) to encourage the I was unable to find this specification. Javier ------_=_NextPart_001_01C22733.56086000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LPPL under review at savannah.gnu.org

I'm reading the discussion and I must confess = that
I'm finding it quite frustrating (except the amusing = message
by Tim). I don't understand the schizophrenic = obsesion
about the name, which is irrelevant in most of cases, = but
that in LaTeX can be important; as a poster = said

> So, in any
> case, if we what, we can do what we want in the = GPL way with a
> LPPL file.

We are at an impasse.

Some comments (I don't know anything about law,
sorry if I say some stupidity):

> Those compatibilities reasons evoqued by the = latex project seems
> to me nonsense: no one can forbid me to write a = book.cls, from
> scratch, that would be incompatible with the = standard book.cls.

That makes sense, but afaik the LPPL doesn't say that. = However,
I think a clear distinction should be made between = the LPPL
and the CTAN policy. CTAN won't accept a = class/package whose
name clashes with the name of an existing = class/package, except
if the author cannot be reached, etc. The main = problem is that
the CTAN maintainers will have an extra work, except = if the
steps are automated in the following way: when = uploading a
supported package you must provide clearly an e-mail = address
where you can be reached, if after three months the = CTAN Team
doesnt get an answer, the old version wil be moved to = an obsolete
tree (and in turn removed after a year) and you will = become the
current maintainer (with some kind of standard form). = Note that
these steps have nothing to do with the LPPL, and a = CTAN Policy
document could be released as well, with cross = references as
notes in both documents. IMO, this restriction will = encourage
new names for classes/packages since the main (almost = the sole)
way to distribute them is CTAN.

> The LaTeX Project Public License. [...]
>
> This license contains complex and annoying = restrictions on how to publish a
> modified version, including one requirement that = falls just barely on the good
> side of the line of what is acceptable: that any = modified file must have a new
> name.
>
> The reason this requirement is acceptable for = LaTeX is that LaTeX has a
> facility to allow you to map file names, to = specify ``use file bar when file
> foo is requested''. With this facility, the = requirement is merely annoying;
> without the facility, the same requirement would = be a serious obstacle, and we
> would have to conclude it makes the program = non-free.

I must confess I don't understand why that makes a = program non-free.
But I agree that in some cases a variant of book = could be useful
-- a prepress house could have a book which loads, = say, hyperref
because the target document is always pdf, and why = not to allow
its distibution if, as stated in the GPL, this files = is
clearly identified as a modified file. (Maybe by = requiring
a \ModifiedPackage macro, in the same line as the = proposal by
Hans. However, I don't know if that's compatible with = GPL.)
This class, of course, won't be accepted in = CTAN.

> The LPPL says that some files, in certain = versions of LaTeX, may have
> additional restrictions, which could render them = non-free. For this reason, it
> may take some careful checking to produce a = version of LaTeX that is free
> software.

I think, again, that makes sense. If LPPL can be = extended freely,
it's more a "draft of license" than an = actual license.

> The LPPL makes the controversial claim that = simply having files on a machine
> where a few other people could log in and access = them in itself constitutes
> distribution. We believe courts would not uphold = this claim, but it is not
> good for people to start making the = claim.

Again, that makes sense to me.

> Please do not use this license for any other = project

And that demonstrates my point about the obsesion = against LPPL.

> Instead a specification was issued
> (http://www.opengr= oup.org/onlinepubs/007908799/) to encourage the

I was unable to find this specification.

Javier

------_=_NextPart_001_01C22733.56086000--