OFF-TOPIC: Qt history refresher course?

[David Johnson]

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 
CDs.

> 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 
seriously considered.

> > 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 
obstinate fools.

-- 
David Johnson
___________________
http://www.usermode.org
pgp public key on website
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3