Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Jul 2002 21:10:54 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g61JAYxC029589 for ; Mon, 1 Jul 2002 21:10:35 +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 g61IVrT8008631; Mon, 1 Jul 2002 20:31:53 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22133.058D7300" 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 g615CgFD021959; Mon, 1 Jul 2002 20:33:17 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 3228 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 1 Jul 2002 20:33:17 +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 g61IXHxD027404 for ; Mon, 1 Jul 2002 20:33:17 +0200 Received: from moutng1.kundenserver.de (moutng1.kundenserver.de [212.227.126.171]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g61IVXT8008554 for ; Mon, 1 Jul 2002 20:31:33 +0200 (MET DST) Received: from [212.227.126.162] (helo=mrelayng1.schlund.de) by moutng1.kundenserver.de with esmtp (Exim 3.22 #2) id 17P5xW-0004Hc-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 01 Jul 2002 20:31:34 +0200 Received: from [80.129.3.9] (helo=istrati.mittelbach-online.de) by mrelayng1.schlund.de with asmtp (Exim 3.35 #1) id 17P5xV-00004s-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 01 Jul 2002 20:31:34 +0200 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g61IUH905005; Mon, 1 Jul 2002 20:30:17 +0200 In-Reply-To: <200207011544.g61FiC49026221@diziet.clawpaws.net> References: <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> <15641.26504.20435.649672@istrati.mittelbach-online.de> <200207011544.g61FiC49026221@diziet.clawpaws.net> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 01 Jul 2002 19:10:54.0899 (UTC) FILETIME=[0616A030:01C22133] 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: Mon, 1 Jul 2002 19:30:17 +0100 Message-ID: A<15648.40889.244234.33682@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Suggested changes to LPPL Thread-Index: AcIhMwZQ83MB+G6TS8q61z0GfhNRYw== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4230 This is a multi-part message in MIME format. ------_=_NextPart_001_01C22133.058D7300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Claire, I think you are very mistaken about the purpose and reasoning behind = LPPL. > I don't think that the license has to assume that anyone making > changes is up to no good and restrict people's ability to make > those changes or to make those changes available in some form. LPPL does not try to prevent people from making changes or from = benefitting from progress. It offers a clear route for supporting change at any time = (you only have to change the name). Its fundamental goal, however is to = preserve the main feature of LaTeX: its universal exchangability of documents. = Package and class files are, if you will, part of the language of latex and = therefore at a given point in time should "ideally" be identical at all sites. In this respect it is like a programming language: the programming = language may change from language version to language version (features may get = added or changed) but within one language release you can (again ideally) = expect that a source program written in that language will compile at any site = that uses this release of the language. Same with latex, except that the changes (and more often the additions) = to the language are larger in numbers than with something like FORTRAN. What = the license tries to ensure is that something is not called FORTRAN77 but FORTRAN2002 if its spec is changed. > At > the moment, the LPPL doesn't prevent an original author from > making significant changes to their package that break backwards > compatibility or even completely change its functionality. There is no reason for LPPL to prevent that, just as it doesn't intend = to prevent development or improvement. It is true that if a package changes significantly different releases of LaTeX may not compile documents in = the same way. But the most siginifcant part that LPPL tries to capture is = still valid: identical releases will give identical results and due to LPPL = there can only be one "current" release for a package with the name xxx. A completely different situation would arise if packages would be = distributed under,say, GPL. Then it would be perfectly permissible to locally = enhance files for one or the other reason (with good or without good reason is irrelevant here) and thus resulting in documents behaving differently on different sites even if both sites started from the same files --- and = in many cases without the author of a document having a chance (other than using = her own implementation on her own pc). [ Just assume that a maintainer of a university site would change the = number of lines in the article class a number of times because he or she is = reading different books on typography (with different suggestions) and she = gradually learns that the defaults in that class are really bad (which they are to = some extend but that history). --- this may sound like a strange scenario, = but it isn't really. At the end of LaTeX209 half the sites in Europe couldn't exchanges files between each other because all had their local = "corrections" without labeling them as such. ] Again: LPPL does not prevent such changes, corrections, enhancements! It = only channels them by requesting a change in name to ensure the above. It is true that we (the project team) keep the LaTeX kernel very closely garded with respect to backward and forward compatibility (meaning = adding new features in the kernel, which is too a sort of incompatibility as it = means that using this feature results in failure on older releases) --- this = is done to keep the core stable and help portability through different releases = of LaTeX. However, this does not follow from applying LPPL at all, and we = think that anything outside the core does not and should not necessarily = follow this principle (even if it makes life for organisations like the AMS slightly = more difficult). Now coming back to the earlier question: > Do we really need to have a time limit built into the license? > > If what we're concerned about here is someone ``hijacking'' a > particular package, then it might make more sense to define some > restrictions on uploading to CTAN and leaving the license such > that anyone can modify the package and make it available somewhere > else. all my attempts where not done to prevent hijacking but rather to give = an agreed way to take a package further when the original author is no = longer able/interested in developing/maintaining it. Otherwise a package under = LPPL has indeed the danger that one has to unnecessarily start from a new = name just to comply to the license. But in fact in most situations this isn't what the authors of packages = would like to have. they would like to have the package live on after they = stopped using latex or being able to maintain it. by defining a suitable process = for this case and allowing the authors to agree to this process beforehand = (by using the license) the situation improved (imho) without losing the = major goal for LPPL out of sight. frank ------_=_NextPart_001_01C22133.058D7300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Suggested changes to LPPL

Claire,

I think you are very mistaken about the purpose and = reasoning behind LPPL.

 > I don't think that the license has to = assume that anyone making
 > changes is up to no good and restrict = people's ability to make
 > those changes or to make those changes = available in some form.

LPPL does not try to prevent people from making = changes or from benefitting
from progress. It offers a clear route for supporting = change at any time (you
only have to change the name). Its fundamental goal, = however is to preserve
the main feature of LaTeX: its universal = exchangability of documents. Package
and class files are, if you will, part of the = language of latex and therefore
at a given point in time should "ideally" = be identical at all sites.

In this respect it is like a programming language: the = programming language
may change from language version to language version = (features may get added
or changed) but within one language release you can = (again ideally) expect
that a source program written in that language will = compile at any site that
uses this release of the language.

Same with latex, except that the changes (and more = often the additions) to the
language are larger in numbers than with something = like FORTRAN. What the
license tries to ensure is that something is not = called FORTRAN77 but
FORTRAN2002 if its spec is changed.

 > At
 > the moment, the LPPL doesn't prevent an = original author from
 > making significant changes to their = package that break backwards
 > compatibility or even completely change = its functionality.

There is no reason for LPPL to prevent that, just as = it doesn't intend to
prevent development or improvement. It is true that = if a package changes
significantly different releases of LaTeX may not = compile documents in the
same way. But the most siginifcant part that LPPL = tries to capture is still
valid: identical releases will give identical results = and due to LPPL there
can only be one "current" release for a = package with the name xxx.

A completely different situation would arise if = packages would be distributed
under,say, GPL. Then it would be perfectly = permissible to locally enhance
files for one or the other reason (with good or = without good reason is
irrelevant here) and thus resulting in documents = behaving differently on
different sites even if both sites started from the = same files --- and in many
cases without the author of a document having a = chance (other than using her
own implementation on her own pc).

[ Just assume that a maintainer of a university site = would change the number
of lines in the article class a number of times = because he or she is reading
different books on typography (with different = suggestions) and she gradually
learns that the defaults in that class are really bad = (which they are to some
extend but that history).  --- this may sound = like a strange scenario, but it
isn't really. At the end of LaTeX209 half the sites = in Europe couldn't
exchanges files between each other because all had = their local "corrections"
without labeling them as such. ]

Again: LPPL does not prevent such changes, = corrections, enhancements! It only
channels them by requesting a change in name to = ensure the above.

It is true that we (the project team) keep the LaTeX = kernel very closely
garded with respect to backward and forward = compatibility (meaning adding new
features in the kernel, which is too a sort of = incompatibility as it means
that using this feature results in failure on older = releases) --- this is done
to keep the core stable and help portability through = different releases of
LaTeX. However, this does not follow from applying = LPPL at all, and we think
that anything outside the core does not and should = not necessarily follow this
principle (even if it makes life for organisations = like the AMS slightly more
difficult).

Now coming back to the earlier question:

 > Do we really need to have a time limit = built into the license?
 >
 > If what we're concerned about here is = someone ``hijacking'' a
 > particular package, then it might make = more sense to define some
 > restrictions on uploading to CTAN and = leaving the license such
 > that anyone can modify the package and = make it available somewhere
 > else.

all my attempts where not done to prevent hijacking = but rather to give an
agreed way to take a package further when the = original author is no longer
able/interested in developing/maintaining it. = Otherwise a package under LPPL
has indeed the danger that one has to unnecessarily = start from a new name just
to comply to the license.

But in fact in most situations this isn't what the = authors of packages would
like to have. they would like to have the package = live on after they stopped
using latex or being able to maintain it. by defining = a suitable process for
this case and allowing the authors to agree to this = process beforehand (by
using the license) the situation improved (imho) = without losing the major goal
for LPPL out of sight.



frank

------_=_NextPart_001_01C22133.058D7300--