tlug: Widget kits and (X)Emacs (IM is not the only "jama" to using toolkits)

["Stephen J. Turnbull" <turnbull@example.com>]

Attached is an excerpt from an interview with RMS.  This is one of the 
myriad reasons why Emacsen don't come with a standard independently
developed widget kit, except Motif, which has a specific exemption
from the FSF for some reason (probably because it is the standard
system software on many OSF systems).

Not directly related to Japanese input methods, but ...


---- Begin included message ----

• To: XEmacs Beta Test <xemacs-beta@example.com>
• Subject: XEmacs + Qt
• From: Martin Buchholz <martin@example.com>
• Date: Sat, 13 Jun 1998 18:47:23 -0700 (PDT)
• Content-Type: text/plain; charset=us-ascii
• Reply-To: martin@example.com
• Sender: owner-xemacs-beta@example.com

>From an RMS interview:

http://some.net/transcripts/rms-19980613-gnu.log

<lilo> there's been a lot of recent discussion about the whole
<lilo> business with Qt and KDE....I had wanted to ask you, if you
<lilo> could, to talk about that whole business just because it
<lilo> encouraged someone to use GNU/Linux.

<rms> Qt is a library which appears to be technically useful, but is
<rms> not free software.  Like all the other non-free programs out
<rms> there, it's outside of the free software community.  KDE is a
<rms> free program which was developed so that it needs Qt in order to
<rms> run.  This has a paradoxical result: although KDE is free
<rms> software, it is useless as an addition to a free operating
<rms> system, because there is no way to run it on a free operating
<rms> system.  In order to run KDE, you need to add Qt, which means
<rms> that the operating system is no longer entirely free.

<rms> The KDE developers thought that they would "get the job done
<rms> faster" if they used Qt--but the real result is that the wrong
<rms> job got done.  It's like saying, "we can build this segment of
<rms> track faster if we don't make it connect with the other
<rms> segment". Maybe so, but if it doesn't connect, you don't have a
<rms> railroad that works.

<lilo> okay, for some of our participants who are maybe not clear on
<lilo> the problem with the Qt license....I don't want to take a lot
<lilo> of questions on this, but could you tell us what, in your
<lilo> opinion, "breaks" the Qt license as free software?

<rms> I would have to look at the Qt license again; it has been
<rms> several months since I looked, and I don't remember.

<lilo> okay, let's see....

<rms> I think it was either that it is limited to noncommercial
<rms> distrbution only or that distribution of modified versions is
<rms> not allowed, or both.

* lilo nods

<rms> Either kind of restriction makes a program non-free; I just
<rms> don't remember for certain which of these restrictions Qt has.

<rms> By the way, the Qt license says it gives permission to link Qt
<rms> with GPL-covered programs; however, if you actually do that, you
<rms> would violate the GPL.

<rms> If the authors of a GPL-covered program want to give permission
<rms> for linking it with Qt, they can do so.

<lilo> so regardless of the flaws you see in it, it just simply
<lilo> doesn't work connecting it to the GPL

<rms> It's clear that the authors of KDE mean to permit this, for
<rms> example, so it is permitted *for KDE*.  But if you wanted to
<rms> link Emacs with Qt you would have to ask permission from the
<rms> FSF, and I can tell you that the answer would be no.  The
<rms> purpose of releasing Emacs under the GPL is so that it can't be
<rms> mixed with non-free software.  Extended versions of Emacs must
<rms> be free software.

---- End included message ----