Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Jul 2002 23:57:05 +0200 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id g6FLudWi017829 for ; Mon, 15 Jul 2002 23:56:40 +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 g6FLoeWK016131; Mon, 15 Jul 2002 23:50:40 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C22C4A.8E83CE80" 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 g6F5l6Gs024602; Mon, 15 Jul 2002 23:51:46 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 5899 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 15 Jul 2002 23:51:46 +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 g6FLpkrU031101 for ; Mon, 15 Jul 2002 23:51:46 +0200 Received: from moutng0.schlund.de (moutng0.kundenserver.de [212.227.126.170]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id g6FLodWK016123 for ; Mon, 15 Jul 2002 23:50:39 +0200 (MET DST) Received: from [212.227.126.160] (helo=mrelayng0.kundenserver.de) by moutng0.schlund.de with esmtp (Exim 3.22 #2) id 17UDjr-0007gB-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 15 Jul 2002 23:50:39 +0200 Received: from [80.129.0.26] (helo=istrati.mittelbach-online.de) by mrelayng0.kundenserver.de with asmtp (Exim 3.35 #1) id 17UDjq-0006QI-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 15 Jul 2002 23:50:38 +0200 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id g6FLoZq05684; Mon, 15 Jul 2002 23:50:35 +0200 Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 15 Jul 2002 21:57:05.0446 (UTC) FILETIME=[8EC7DC60:01C22C4A] 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: forwarded message from Jeff Licquia Date: Mon, 15 Jul 2002 22:50:34 +0100 Message-ID: A<15667.17322.923787.604569@istrati.mittelbach-online.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: forwarded message from Jeff Licquia Thread-Index: AcIsSo7l+AV18hUWRgWmpFbfIbScuA== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4295 This is a multi-part message in MIME format. ------_=_NextPart_001_01C22C4A.8E83CE80 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C22C4A.8E83CE80" ------_=_NextPart_002_01C22C4A.8E83CE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: forwarded message ------_=_NextPart_002_01C22C4A.8E83CE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------_=_NextPart_002_01C22C4A.8E83CE80-- ------_=_NextPart_001_01C22C4A.8E83CE80 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: by nummer-3.proteosys id <01C22C47.7F4F5180@nummer-3.proteosys>; Mon, 15 Jul 2002 22:35:11 +0100 In-Reply-To: <15667.9629.854453.790551@istrati.mittelbach-online.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C22C47.7F4F5180" References: <200207042108.g64L8649017884@diziet.clawpaws.net><1026622486.19717.707.camel @server1> <20020714195323.GA18502@molehole.dyndns.org> <15667.9629.854453.790551@istrati.mittelbach-online.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 Return-Path: X-Mailer: Ximian Evolution 1.0.3 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Envelope-to: smtp@mittelbach-online.de delivery-date: Mon, 15 Jul 2002 23:32:31 +0200 Content-class: urn:content-classes:message Subject: Re: Motivations; proposed alternative license (was Re: LaTeX PublicProject License, Version 1.3 (DRAFT)) Date: Mon, 15 Jul 2002 22:32:10 +0100 Message-ID: <1026768730.1631.97.camel@laptop2.internal.licquia.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Jeff Licquia" To: "Frank Mittelbach" Cc: This is a multi-part message in MIME format. ------_=_NextPart_003_01C22C47.7F4F5180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm glad to see you here, Frank. Please forward my responses as you deem appropriate to latex-l. On Mon, 2002-07-15 at 14:42, Frank Mittelbach wrote: > It is _not_ the wish of the LaTeX project to "control" the layout = produced by > LaTeX nor is it the with the have an "identical layout" for all LaTeX = users. > > Instead it is the wish to give preserve for LaTeX users one of the = most > fundamental features of TeX and LaTeX: the reliability that a document > produces identical results at different sites thus allowing LaTeX to = be used > as an exchange media in collaborations, when preparing camera ready = copy, etc. > > This is very different from wanting to control the layout produced by = LaTeX as > a whole or to freeze it in any sense. On the contrary, we are very = interested > in the LaTeX community to improve the system and have it improved by = new > people using it. But we wish to keep the fundamental feature intact as > well. For this reason the requirement to change the name of a package = or class > file if modified is essential. With that as a requisite changes = extensions, > whatever are very welcome by everybody and if you look at the amount = of > development going on the in community (the majority done under LPPL) = you can > see that people are neither hampered nor dissatisfied by the license = goals. There is definitely nothing wrong with wanting to standardize, or to ensure that your users can enjoy the benefits of predictable results. However, taken to an extreme, this is the motivation behind lots of proprietary licenses. One would assume that your overtures towards groups like Debian imply that you have other goals as well, so we need to balance those goals. It's arguable that, if someone wants "articles" to use a different font, or to put titles at the end of sections instead of before, or something like that, then the person should rename the "article" type rather than edit "article" in place. It only makes sense that other users, who don't need what this person needs in "articles", is going to be pretty pissed off when their articles have the title at the end. But what happens if "article" itself is broken? Supposed that LaTeX releases with a bug that causes Debian boxes (and just Debian boxes) to be unable to process "article" documents. Can a non-blessed person go in and fix problems with LaTeX, or do they have to go begging to you guys before they are allowed to process articles correctly? I don't mean to slam your release process or your QA; for all I know, they're great. But I don't have any guarantee of that. You're human, after all. And even if you aren't, you're very likely to change the membership of the core maintenance group. In short, can you guarantee that you will never, never ever screw up? I don't think you can. That's why we consider the right to modify the base parts of the system to be so important to us. If we wanted to be beholden to some organization for fixes to our problems, we'd do a lot better relying on Microsoft; after all, they have a lot more resources than you. > granted LPPL is imperfect, certainly if you look at it from a purely = legal > standpoint; however for the LATeX community it was in the past mainly = a > framework to express some basic needs to keep the system stable and = reliable > to the extend needed while at the same time allowing arbitrary = extensions and > changes --- the fact that the license is now used for most of latex = related > work should speak for itself. Actually, recent events with license compatibility have led to the standard dictum: if you rely on some major component, follow that component's license. That's why most elisp is GPLed, most Perl modules are dual GPL/Artistic, and most Zope components are ZPL. In the case of the old Artistic license (and perhaps the new; I haven't reviewed it recently), no amount of usage statistics could cover its warts. > so I very much open to simplify the license and/or make if legally = more > bulletproof (if people really feel that is necessary) or what else is > necessary to make it acceptable in other communities that think they = produce > maintain or know what "free" software is. You've probably seen my proposed license. There are some problems with it, to be sure, but tell me: does it come close to meeting your needs? What drawbacks does it have, in your opinion? (Sam's already pointed one out, and I'm sure other Debian folks will have their own issues.) > open with the exception of one point: > > - LaTeX needs clause 4 of debian guidelines, in fact that is central = for us > (and here I don't just speak of the team) but for very very many = LaTeX > users who also have some rights which is given to them through = something > like LPPL Perhaps. I'm not convinced. I think too many people are enamoured of the idea that it's better to beat users about the head with the law, rather than ask them to do what's obviously the Right Thing and expect them to act in good faith. For example, in my "article" bug example above, I would expect that most sysadmins installing LaTeX would say "to hell with the license, I have work to do" and fix the bug in the default "article" code, without renaming "article" and taking on the headache of translating "article" to "article-fixed" or whatever name they use in all their documents. Could you honestly blame them? OTOH, there are loads of examples of people in the Free Software world playing nice with each other in regards to changes made to systems. Backwards-compatibility and reliability are important, and most people would rather have a system that works consistently than not. Most incompatible patches to existing systems either result in a fork with a different name (Emacs -> XEmacs, for example), or in someone rewriting the patch in a way that makes it compatible with the original. But clause 4 is in the DFSG, and it's not fair to criticize you for using it. You will note that I made some effort in my proposed license snippet to accomodate you in this respect. > and please try not to insult a whole community of people some of which = have > already worked 15-20 years producing freely available and changable = software > by calling what they do "unfree" or worse just because you don't like = the fact > that we try to balance the right of programmers (getting free = software) with > the right of the users of getting stable and reliable software. LPPL's = model > is not right for everything, on the contrary, and many of us use GPL = or other > licenses in other circumstances. I wasn't aware that users had a "right" to stability and reliability. Certainly, the current state of the software world disproves that notion. You point out that you're trying to hit a balance here. I'm glad to hear it; my first impressions were that the "balance" (such as it was) seemed a bit tilted away from the goals of projects like Debian. But it's not illegitimate to express this concern. Indeed, as bastions of freedom from time immemorial, I would think that you would value such concerns. It seems that this is the case, which is good. > If you think that the goals behind LPPL (not talking about the way it = is > expressed) are bad in general then I would like to pointout to you = that you > have to include TeX itself (ie base behind everything written by Don = Knuth) > which in my opinion was one of the very first "free software projects" = ever as > it invokes clause 4 for exactly the same reason as LPPL. Don Knuth is great. That doesn't mean that he's infallible, or even that ideas he originally expressed haven't matured beyond him. (BTW, I believe the BSD stuff predates TeX, though I could be wrong, and there are plenty of other examples of the "free philosophy" that predate even BSD; general policies regarding IBM mainframe software in the 70s, for instance.) If there is one thing among your (possibly unstated) goals and views that seems to grate on me more than anything else, it's this: You're a moron, and can't be trusted to not screw up our beautiful software. So, hands off! Now, I realize that you don't say this in so many words. But all of the restrictions on filenames and the business about Current Maintainers make very little sense otherwise. Certainly those clauses in the license don't give people a sense of cooperation and trust. It might be instructive to see if that's really the feeling among people associated with LaTeX. If not, then perhaps you could be a little less paranoid about changes to LaTeX that are well-documented. Filename changes aren't necessarily the only way to let people know that things have changed; indeed, filenames are often the most trouble-prone ways to document changes in a system. (Plus, to get back to the point that grates on me, *you* are allowed to make any such changes that you want without worrying about filenames. You don't even have to document your changes according to the license. Why? What makes you so special?) ------_=_NextPart_003_01C22C47.7F4F5180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Motivations; proposed alternative license (was Re: LaTeX = PublicProject License, Version 1.3 (DRAFT))

I'm glad to see you here, Frank.  Please forward = my responses as you
deem appropriate to latex-l.

On Mon, 2002-07-15 at 14:42, Frank Mittelbach = wrote:
> It is _not_ the wish of the LaTeX project to = "control" the layout produced by
> LaTeX nor is it the with the have an = "identical layout" for all LaTeX users.
>
> Instead it is the wish to give preserve for = LaTeX users one of the most
> fundamental features of TeX and LaTeX: the = reliability that a document
> produces identical results at different sites = thus allowing LaTeX to be used
> as an exchange media in collaborations, when = preparing camera ready copy, etc.
>
> This is very different from wanting to control = the layout produced by LaTeX as
> a whole or to freeze it in any sense. On the = contrary, we are very interested
> in the LaTeX community to improve the system and = have it improved by new
> people using it. But we wish to keep the = fundamental feature intact as
> well. For this reason the requirement to change = the name of a package or class
> file if modified is essential. With that as a = requisite changes extensions,
> whatever are very welcome by everybody and if = you look at the amount of
> development going on the in community (the = majority done under LPPL) you can
> see that people are neither hampered nor = dissatisfied by the license goals.

There is definitely nothing wrong with wanting to = standardize, or to
ensure that your users can enjoy the benefits of = predictable results.
However, taken to an extreme, this is the motivation = behind lots of
proprietary licenses.  One would assume that = your overtures towards
groups like Debian imply that you have other goals as = well, so we need
to balance those goals.

It's arguable that, if someone wants = "articles" to use a different font,
or to put titles at the end of sections instead of = before, or something
like that, then the person should rename the = "article" type rather than
edit "article" in place.  It only = makes sense that other users, who
don't need what this person needs in = "articles", is going to be pretty
pissed off when their articles have the title at the = end.

But what happens if "article" itself is = broken?  Supposed that LaTeX
releases with a bug that causes Debian boxes (and = just Debian boxes) to
be unable to process "article" = documents.  Can a non-blessed person go
in and fix problems with LaTeX, or do they have to go = begging to you
guys before they are allowed to process articles = correctly?

I don't mean to slam your release process or your QA; = for all I know,
they're great.  But I don't have any guarantee = of that.  You're human,
after all.  And even if you aren't, you're very = likely to change the
membership of the core maintenance group.

In short, can you guarantee that you will never, never = ever screw up?  I
don't think you can.  That's why we consider the = right to modify the
base parts of the system to be so important to = us.  If we wanted to be
beholden to some organization for fixes to our = problems, we'd do a lot
better relying on Microsoft; after all, they have a = lot more resources
than you.

> granted LPPL is imperfect, certainly if you look = at it from a purely legal
> standpoint; however for the LATeX community it = was in the past mainly a
> framework to express some basic needs to keep = the system stable and reliable
> to the extend needed while at the same time = allowing arbitrary extensions and
> changes --- the fact that the license is now = used for most of latex related
> work should speak for itself.

Actually, recent events with license compatibility = have led to the
standard dictum: if you rely on some major component, = follow that
component's license.  That's why most elisp is = GPLed, most Perl modules
are dual GPL/Artistic, and most Zope components are = ZPL.

In the case of the old Artistic license (and perhaps = the new; I haven't
reviewed it recently), no amount of usage statistics = could cover its
warts.

> so I very much open to simplify the license = and/or make if legally more
> bulletproof (if people really feel that is = necessary) or what else is
> necessary to make it acceptable in other = communities that think they produce
> maintain or know what "free" software = is.

You've probably seen my proposed license.  There = are some problems with
it, to be sure, but tell me: does it come close to = meeting your needs?
What drawbacks does it have, in your opinion?  = (Sam's already pointed
one out, and I'm sure other Debian folks will have = their own issues.)

> open with the exception of one point:
>
>  - LaTeX needs clause 4 of debian = guidelines, in fact that is central for us
>    (and here I don't just speak = of the team) but for very very many LaTeX
>    users who also have some = rights which is given to them through something
>    like LPPL

Perhaps.  I'm not convinced.  I think too = many people are enamoured of
the idea that it's better to beat users about the = head with the law,
rather than ask them to do what's obviously the Right = Thing and expect
them to act in good faith.

For example, in my "article" bug example = above, I would expect that most
sysadmins installing LaTeX would say "to hell = with the license, I have
work to do" and fix the bug in the default = "article" code, without
renaming "article" and taking on the = headache of translating "article"
to "article-fixed" or whatever name they = use in all their documents.
Could you honestly blame them?

OTOH, there are loads of examples of people in the = Free Software world
playing nice with each other in regards to changes = made to systems.
Backwards-compatibility and reliability are = important, and most people
would rather have a system that works consistently = than not.  Most
incompatible patches to existing systems either = result in a fork with a
different name (Emacs -> XEmacs, for example), or = in someone rewriting
the patch in a way that makes it compatible with the = original.

But clause 4 is in the DFSG, and it's not fair to = criticize you for
using it.  You will note that I made some effort = in my proposed license
snippet to accomodate you in this respect.

> and please try not to insult a whole community of = people some of which have
> already worked 15-20 years producing freely = available and changable software
> by calling what they do "unfree" or = worse just because you don't like the fact
> that we try to balance the right of programmers = (getting free software) with
> the right of the users of getting stable and = reliable software. LPPL's model
> is not right for everything, on the contrary, = and many of us use GPL or other
> licenses in other circumstances.

I wasn't aware that users had a "right" to = stability and reliability.
Certainly, the current state of the software world = disproves that
notion.

You point out that you're trying to hit a balance = here.  I'm glad to
hear it; my first impressions were that the = "balance" (such as it was)
seemed a bit tilted away from the goals of projects = like Debian.  But
it's not illegitimate to express this concern.

Indeed, as bastions of freedom from time immemorial, I = would think that
you would value such concerns.  It seems that = this is the case, which is
good.

> If you think that the goals behind LPPL (not = talking about the way it is
> expressed) are bad in general then I would like = to pointout to you that you
> have to include TeX itself (ie base behind = everything written by Don Knuth)
> which in my opinion was one of the very first = "free software projects" ever as
> it invokes clause 4 for exactly the same reason = as LPPL.

Don Knuth is great.  That doesn't mean that he's = infallible, or even
that ideas he originally expressed haven't matured = beyond him.  (BTW, I
believe the BSD stuff predates TeX, though I could be = wrong, and there
are plenty of other examples of the "free = philosophy" that predate even
BSD; general policies regarding IBM mainframe = software in the 70s, for
instance.)

If there is one thing among your (possibly unstated) = goals and views
that seems to grate on me more than anything else, = it's this:

  You're a moron, and can't be trusted to not = screw up our beautiful
  software.  So, hands off!

Now, I realize that you don't say this in so many = words.  But all of the
restrictions on filenames and the business about = Current Maintainers
make very little sense otherwise.  Certainly = those clauses in the
license don't give people a sense of cooperation and = trust.

It might be instructive to see if that's really the = feeling among people
associated with LaTeX.  If not, then perhaps you = could be a little less
paranoid about changes to LaTeX that are = well-documented.  Filename
changes aren't necessarily the only way to let people = know that things
have changed; indeed, filenames are often the most = trouble-prone ways to
document changes in a system.

(Plus, to get back to the point that grates on me, = *you* are allowed to
make any such changes that you want without worrying = about filenames.
You don't even have to document your changes = according to the license.
Why?  What makes you so special?)

------_=_NextPart_003_01C22C47.7F4F5180-- ------_=_NextPart_001_01C22C4A.8E83CE80--