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]