On 30 Apr 2002, Stephen J. Turnbull wrote:
Simon> The only relevance of RMS opinion here seems to be
that
Simon> such code would not end up in Emacs.
The FSF is the copyright holder on enough XEmacs code to block[1] any
change that it thinks violates the GPL. I'm sure they would, too.
QT is GPL so I don't see how it can violate GPL. Just because non-GPL
implementations of the same API exist shouldn't cause problems. Again,
if I write non-GPL versions of libjpeg, should Emacs stop using free
libjpeg?
Here is rms's opinion (reposted in full with his permission):
------------------------------------------------------------------------
[sjt]
Under what conditions would the FSF permit XEmacs to
distribute a version "intended" for linking only to the
GPL-compatible versions of Qt?
[rms]
We would not give permission for that.
I don't understand how he can forbid linking GPL code with GPL code.
[sjt]
It has been suggested that a configure test that causes
./configure to issue a fatal "unsupported" error on any
platform where Qt has no version distributed under a
GPL-compatible license is sufficient. And of course no
"gratuitous" support (eg, in Makefiles, documentation, or
platform-specific files) for "unintended" platforms would be
admitted.
[rms]
That is a very good approach. I thank whoever made the
suggestion.
It would be good to add comments next to these tests, saying that
they are intended to warn people before they violate the GPL. The
comments could say that removing the tests would not per se
violate the GPL but linking with non-free Qt versions would
violate it.
And here he seems to be OK with linking GPL code to GPL code. I suspect
there was misunderstandings and/or typos involved here.
I agree completely that noone shouldn't spend time getting Qt to work
under Windows. The license issues is problem enough, but there doesn't
seem to be any technical merits either. I mean, doesn't Windows users
like the Windows behaviour better than Qt?
N.B. None of the above is a promise, just a suggestion for how you
can get started and eventually merge to trunk if things go well.
Unless it turns out to be easy, I'm not doing it all. My main interest is
the KDE KPart stuff, so if it is possible to do that without the Qt widget
stuff (which I actually suspect), that's where I'll put my energy.