Mime-Version: 1.0
Content-Type: text/plain
Return-path: <[log in to unmask]>
Envelope-to: [log in to unmask]
Delivery-date: Mon, 15 Jul 2002 23:32:31 +0200
Received: from pop.kundenserver.de [212.227.126.129]
        by localhost with POP3 (fetchmail-5.6.5)
        for frank@localhost (single-drop); Mon, 15 Jul 2002 23:35:11 +0200 (CEST)
Received: from [134.100.9.61] (helo=rzdspc1.informatik.uni-hamburg.de)
        by mxng09.kundenserver.de with esmtp (Exim 3.22 #2)
        id 17UDSI-0004tf-00
        for [log in to unmask]; Mon, 15 Jul 2002 23:32:30 +0200
Received: from sun.dante.de ([log in to unmask] [134.100.9.52])
        by rzdspc1.informatik.uni-hamburg.de (8.12.5/8.12.5) with ESMTP id g6FLWP4Y019567
        for <[log in to unmask]>; Mon, 15 Jul 2002 23:32:25 +0200 (CEST)
Received: from rzdspc1.informatik.uni-hamburg.de ([log in to unmask] [134.100.9.61])
        by sun.dante.de (8.12.5/8.12.5) with ESMTP id g6FLWPBn006015
        for <[log in to unmask]>; Mon, 15 Jul 2002 23:32:25 +0200 (CEST)
Received: from jeffindy.licquia.org ([log in to unmask] [216.37.46.185])
        by rzdspc1.informatik.uni-hamburg.de (8.12.5/8.12.5) with ESMTP id g6FLWL4Y019545
        for <[log in to unmask]>; Mon, 15 Jul 2002 23:32:22 +0200 (CEST)
Received: from sentinel.licquia.org (unknown [192.168.53.1])
        by jeffindy.licquia.org (Postfix) with ESMTP
        id 1D7DAFC3D; Mon, 15 Jul 2002 16:32:15 -0500 (EST)
Received: from laptop2.internal.licquia.org (unknown [192.168.52.2])
        by sentinel.licquia.org (Postfix) with ESMTP
        id 326A34500B; Mon, 15 Jul 2002 16:32:14 -0500 (EST)
Received: by laptop2.internal.licquia.org (Postfix, from userid 1000)
        id 246542A7C6; Mon, 15 Jul 2002 16:32:11 -0500 (EST)
In-Reply-To: <[log in to unmask]>
References:
        <[log in to unmask]><1026622486.19717.707.camel
        @server1> <[log in to unmask]>
        <[log in to unmask]>
X-Mailer: Ximian Evolution 1.0.3
Message-Id: <[log in to unmask]>
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
From: Jeff Licquia <[log in to unmask]>
To: Frank Mittelbach <[log in to unmask]>
Cc: [log in to unmask]
Subject: Re: Motivations; proposed alternative license (was Re: LaTeX
        PublicProject License, Version 1.3 (DRAFT))
Date: 15 Jul 2002 16:32:10 -0500

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?)