OFF-TOPIC: Qt history refresher course?
david at usermode.org
Tue Feb 12 09:21:51 UTC 2002
On Monday 11 February 2002 11:01 pm, Rick Moen wrote:
> Now, being a professional cynic (i.e., a sysadmin) with a dark sense of
> humour, I expect you'd have us believe that Red Hat Software's change of
> policy on this point resulted from a sudden stamp of approval from its
> legal department, rather than resulting from competitive pressure.
As soon as Trolltech announced their change of licensing Redhat announced
that it would have KDE in the next version. However, the next version of KDE
was not ready by the time of the next Redhat. I attribute it a simple goof.
> I remember hearing these things. Appealing to the "special exception"
> clause of GPL v. 2 clause 3 seemed like really reaching, in my view (for
> whatever that's worth). The plain facts seem to not support this. I
> regard that matter as self-evident.
The special exception clause was frequently cited by the other side, so it
was examined, and found that the clause was if not vague, at least very
confusing. Certainly we all felt that at least Corel LinuxOS, which used Qt
as a part of its installation procedure, was entitled to classify Qt as
something normally distributed with a major component of the operating system.
Some even argued that the final clause "unless that component itself
accompanies the executable" applied to Qt since it accompanied KDE on distro
> I must confess I never saw the logic of this one. If the forcing
> provision of licences like GPL and MPL have any meaning whatsoever,
> it would certainly apply to derivative works like the "K" variants of
> prior upstream works by third parties.
We did recognize two genuine problems, the notice of which seemed to be swept
away in the furor over the general issue. Two KDE apps were identified that
had actually been derived from pre-existing GPLd code: kfloppy and
kghostscript. Both the authors in question (Linus Torvalds and Aladdin) were
contacted with no response. Leaving them out of the next release was
> > Second, that "lasting distrust" was unfortunate, but still nothing we
> > could have done anything about.
> This is transparently incorrect: The KDE team could have attempted to
> secure explicit Qt-linkage permission from all upstream authors. For
> reasons of their own, they did not. I certainly will not debate
> intentions, but I will point out the fact of what did and did not occur.
Okay, let's take the whole situation and turn it on its head as an analogy.
Suppose people from KDE announced sometime in the future that Gnome was
illegal because it uses Mono, which itself is an implementation of
Microsoft's .NET. The Gnome crew examines Gnome and Mono and concludes that
the accusation is erroneous. Mono has implemented an API and is not dependent
upon any proprietary libraries. The arguments persist. Miguel patiently
explains that Mono is under the LGPL so even if the accusations were true it
doesn't apply. The protesters point to Gnome, which is GPL not LGPL, and the
whole cycle starts over again. Slashdot gets into the act and Gnome
developers are publicly slandered.
To the Gnome developers, the whole situation is patently ridiculous. But
ridiculous or not, a major distribution has refused to ship Gnome, and C/NET
is running articles proclaiming the death of Linux. So what do they do? Do
they ignore the problem? Ignore the messengers of the problem? Go through the
intense hassle of changing the licenses?
But fear not! Gnome is let off the hook. Microsoft decided to release .NET
under the GPL (see, I told you this was fantasy) and Kirk McKusick grants
forgiveness for any BSD code used in Mono.
A fictional story to be true, but maybe you can understand a little better
the situation KDE found itself in, and why KDE developers aren't stubborn
pgp public key on website
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss