Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Return-path: <[log in to unmask]>
Envelope-to: [log in to unmask]
Delivery-date: Tue, 16 Jul 2002 22:45:22 +0200
Received: from pop.kundenserver.de [212.227.126.165]
by localhost with POP3 (fetchmail-5.6.5)
for frank@localhost (single-drop); Tue, 16 Jul 2002 22:50:15 +0200 (CEST)
Received: from [134.100.9.61] (helo=rzdspc1.informatik.uni-hamburg.de)
by mxng06.kundenserver.de with esmtp (Exim 3.22 #2)
id 17UZCC-0003fU-00
for [log in to unmask]; Tue, 16 Jul 2002 22:45:20 +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 g6GKjH4Y012868
for <[log in to unmask]>; Tue, 16 Jul 2002 22:45:17 +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 g6GKjHBn010177
for <[log in to unmask]>; Tue, 16 Jul 2002 22:45:17 +0200 (CEST)
Received: from grue.ucsd.edu ([log in to unmask] [132.239.66.103])
by rzdspc1.informatik.uni-hamburg.de (8.12.5/8.12.5) with ESMTP id g6GKjD4Y012859
for <[log in to unmask]>; Tue, 16 Jul 2002 22:45:14 +0200 (CEST)
Received: from localhost ([127.0.0.1] ident=boo)
by grue.ucsd.edu with esmtp (Exim 3.35 #1 (Debian))
id 17UZBI-00008S-00; Tue, 16 Jul 2002 13:44:24 -0700
Message-Id: <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
References: <[log in to unmask]>
<[log in to unmask]>
<[log in to unmask]>
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
From: Walter Landry <[log in to unmask]>
To: [log in to unmask], [log in to unmask]
Subject: Re: Motivations; proposed alternative license
Date: Tue, 16 Jul 2002 13:44:23 -0700 (PDT)
Frank Mittelbach <[log in to unmask]> wrote:
> So far I have seen the comments by Jeff (who goes in a lot of detail
> through the license, for which i would like to thank him, and to
> which i intend to get back) but other than that, all I heard so far
> and repeatedly heard is "we don't like that you use clause 4 and
> therefore it is a license acceptable by us" (though in more
> elaborate words).
Well, there were my comments that preventing the modification or
removal of .ins files goes beyond what clause 4 allows. I even gave
an example where it might be completely appropriate to do such a
thing. The message should be in the debian-legal archive.
In that message I also said that that was the only thing that
definitely makes it non-free. Now I think that the renaming
requirement also goes beyond what is allowed in clause 4.
Specifically, clause 4 says that, as a special case, you can allow
changes only as patches to the original program. It doesn't say
anything about what kind of restrictions you can put on those patches,
and Debian traditionally has not allowed any additional restrictions.
Telling people that a patch must have a certain form (i.e. must rename
any file that it modifies) is an additional restriction that Debian
can not live with. Because of both practical and ideological reasons.
In a sense, I feel your pain. You want everyone's installation of
Latex to be the same to facilitate interoperability. However, free
software means that you give up some measure of control over your
creation. RMS lost a lot of control when egcs became the official
gcc, and I'm sure the Emacs-XEmacs split didn't make him happy either.
But he still is willing to give other people control.
Here is a hypothetical. Let's say that someone wants to add support
for Klingon into Latex. So they hack something together which, by
necessity, changes a few standard files, and it works for them without
breaking anything else. You reject the patch because it isn't really
a good i18n solution, it only works for Klingon. You also think that
Klingon is a silly thing to add support for, so you'll probably never
add it in. However, for the people interested in writing Klingon
(e.g. Hollywood screen writers and trek fan fiction writers), this is
a good solution. In this case, you are preventing people from having
seamless support for Klingon.
Regards,
Walter Landry
[log in to unmask]