Red Hat Software has recently published (and later revised) a web page about its reasons for not including Qt on its CDs. I've read the page, and am shocked at the number of fudges and inaccuracies. I'll quote and comment the bulk of it here.
(Note: While importing old postings into my current blog, I noticed that Redhat removed the page a few months after I wrote this. I don't know when, exactly, but in April 1999 it was gone.)
Note that this is me, Arnt Gulbrandsen, and nobody else speaking. You may assume that some of the other trolls agree with some of it, but if you want Troll Tech's official opinion, write to email@example.com.
The paragraphs quoted from the August 18 version of Red Hat's page are indented like this.
My comments to each quoted paragraph is like this.
6 August 1998
CTO, Red Hat Software
The Qt widget library, published by Troll Tech  has been the topic of much current debate in the Open Source(R) community. This paper sets forth Red Hat Software's position with regard to Qt, and to illustrate the rationale behind our decisions.
The Qt widget library has been used in many software projects,
including the K Desktop Environment , an effort to produce a
free high quality graphical desktop environment for UNIX-like
operating systems. Although it is the existence of KDE that has
initiated the current discussions, it is important to emphasize that
it is the license of Qt, not KDE, that the discussion is about. The
KDE license is the GNU GPL , while the Qt license is
purpose-written by Troll Tech to allow use
free of charge for
developing free software . In fact, this license poses
restrictions on authors of Open Source software that are contrary to
the Open Source Definition , and restrictions on authors of
non-Open Source software that would not exist if Qt were licensed with
the GNU LGPL .
Several points here.
Qt is not a widget library, it's a GUI toolkit. The differences are considerable, though one needs to understand a bit of the field to understand them. (As a quick example: A lot of the really clever code in Qt is outside the widgets, in classes such as QPrinter, QPainter and QColor.)
Red Hat incorrectly states that
the KDE is the GNU GPL. In
fact, the KDE uses the LGPL for its most important code.
In the second paragraph, Red Hat asserts that the Qt license (presumably the Qt Free Software License) imposes restrictions on third-party programs that are contrary to the Open Source Definition, but does not elaborate or give any details.
if Qt were licensed with the GNU LGPL is hardly a valid
comparison. To my knowledge, no one has ever written an LGPL'd or
GPL'd library from scratch with intention to recoup the development
costs from the library. Comparing Qt with something noone has ever
done is dubious, to say the least.
Before continuing it is important to acknowledge that it is of course Troll Tech's right to distribute Qt under any license terms they see fit. Troll Tech's Qt license is simply problematic for Open Source software developers and distributors.
And, one must mention, for Red Hat Software (whose CD packaging rather emphasizes the presence of non-open source components).
The Qt license prohibits modifications to Qt. Specifically, it states
You may use the Qt Free Edition to create application programs
provided that ... Your software does not require modifications to Qt
Free Edition. This clause is contrary to the Open Source
definition's clause allowing modifications and derived works. As a
practical matter, this means you are not allowed to fix bugs in Qt,
even if they are so serious as to cause security problems. You are
not allowed to make improvements to Qt. These improvements and bug
fixes by the community are an important step in the Open Source
development cycle, and are the driving force behind the quality and
feature set of the Linux operating system.
Quite so. Qt itself is not open source as defined by opensource.org, and not free software as defined by the FSF.
We make it available for developers of free software on X11. No more. (Note that the Open Source Definition does not require open source programs to be based on only open source libraries, kernels and so on.)
Since the Red Hat page mentions posssible security problems, I'll step on my soapbox about that too. I believe that any security problem in a program that uses Qt should never be fixed by changing Qt, for the simple reason that any security-critical program whose security-critical region contains several hundred thousand lines of third-party code is designed in a fundamentally insecure way. The correct fix for such problems is to move the security-critical code into a small program or server of its own and use IPC to communicate between the security-critical code (as small as possible) and the rest of the application (much larger). Of course, all access checks must be done in the small program.
In contrast to the LGPL, the Qt license requires you to pay
substantial license fees if you develop and sell commercial
applications that dynamically link against Qt. Specifically, if you
link your software with Qt, your software must be distributed under
the GPL or LGPL, or it must allow free modification and distribution
of the source. This effectively says
your software must be Open
Source even though ours is not, and curiously means that if you
distributed your software under the Qt license you would not be able
to link with Qt!
No, it does not. It's another fudge. Neither of our licenses mention
Open Source or require that Qt-using programs be open source, and
Red Hat is arguing against a strawman.
As for the
your software must be Open Source even though ours is not
dig: If we could afford to make Qt open source, maybe we would and
maybe not. We don't care much about slogans and political movements.
But anyway, we can't. We're happy to let people who will write free
software for X use Qt for free, but I at least will not work for free
myself. I want to pay my rent, buy my books, and not worry about
whether I can pay next month's rent.
(Btw, the Qt licensing is actually flexible enough that it's possible to write programs using Qt that are open source, and ones that aren't.)
There is a final important issue concerning developing GPLed code that uses Qt. The GPL certainly satisfies all the requirements of the Qt license. However, the terms and conditions of the GPL, section 3, state that:
- The source code to your program must be distributed with the program (or be made readily available).
- The source code means
all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable
- The source code must be distributable under the terms of sections 1 and 2 of the GPL.
- The only exception is that source code does not need to be distributed for
anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system.
Since Qt is not part of any operating system, to ship a GPLed application using Qt, you must also ship or make available the source to Qt under the terms of the GPL. Since this is not possible under the term of the Qt license, the logical result is that you may not use Qt in any GPLed applications.
First, yet another fudge.
Qt is not part of any operating system,
Red Hat quite correctly says. However, the GPL does not say
of, it says
distributed along with, and Qt is ditributed
along with several operating systems.
More importantly, Red Hat says that you must ship the source for Qt if
you ship a GPL'd application that uses Qt, since the GPL requires that
the source code to your program must be distributed with the program
(or be made readily available). However, the GPL goes on to define
All the source code for all modules it contains,
If this is the requirement Red Hat bases its statement on, Red Hat is saying that Qt is part of any program that uses Qt. If x contains y, y is part of x.
I believe that Qt is not part of any application, and can't remember ever seeing any application developer claim that Qt is part of his/her application, so I think most people agree with me.
plus any associated interface definition files,
This could conceivably be meant to include Qt's header files. I don't think so, and will argue against it by reductio ad absurdum.
The GPL differentiates between source code and interface definition
files, and grants an exception for source code that for
kernel and so on but none for interface defintion files. If
associated interface header files is interpreted to include Qt's
header files, it includes all third-party/system header files, and in
that case this requirement would mean that all header files used by
a GPL'd program must be distributable under the GPL which seems
Thus, I think that
associated interface definition files must refer
to header files for the program itself.
plus the scripts used to control compilation and installation
of the executable.
I can't see that this has anything to do with Qt at all.
Does Red Hat really think that Qt is part of the KDE, and part of the hundreds of other programs that use Qt? Or is Red Hat's conclusion based on just another fudge?
While this analysis is the subject of some debate, it may in fact be illegal to distribute Qt-based code under the GPL at all.
Some debate, indeed.
These are the fundamental problems with the Qt license when writing
Open Source software. But there is another problem that exacerbates
the situation, and is in some sense the real problem. To the Open
Source developer who is not fully educated in the details and
rationale behind the Open Source Definition, the Qt license may seem
free enough, and they may unknowingly write software that depends on
a non-free component.
I'd put it a little differently. I'd say,
to the developer who takes
Red Hat's unsubstantiated assertions at face value.
That isn't to say that Qt is free enough: You must judge that for yourself. We're simply giving away what we can afford to, and if that gift can help you do what you want to, good! If not... we do our best, and who can do more?
This, in fact, happened with KDE and continues to occur. KDE is very nice software, and it is gaining popularity as a desktop. Should Qt become widely adopted by Linux users as part of the Linux operating system standard, it would be a serious setback to the benefits that true Open Source software provides.
I believe that our very open development model, with full source disclosure and good developer access (write to qt-bugs and a developer will answer, not a low-paid support droid) provides essentially the same benefits.
It also provides the benefit of giving the X11-based free software
developers access to the latest and greatest version of a
professionally maintained and professionally documented toolkit. In
my opinion, that outweighs minor
drawbacks like having to send bug
fixes to the maintainers instead of releasing your own branched
version at once.
According to Bruce Perens, principal author of the Open Source
it's not important that everything on your favorite Linux
distribution be Open Source, but any standard part of Linux must be
Open Source. If it isn't, we are discarding the main strength of Linux...
the freedom for anyone to change it, redistribute it, and use it
as they like. That freedom is the sole reason for all of the
innovation in Linux and all of its success. 
When we first released Qt, it wasn't standard. But it was good, and we've been improving ever since. With such quality comes wide usage, and now people are talking about Qt being standard.
I suppose non-open source software is okay by Red Hat and Bruce Perens as long as it isn't good enough to gain wide usage.
After fully considering all the issues, including the questionable legality of linking GPLed software with Qt, and the restrictions its license places on our users, we have decided that we will not include Qt as part of our standard Open Source based Linux operating system as long as it is distributed under its current non-Open Source license. To ship Qt would be a breach of our responsibility to our users, who trust us to ship only Open Source software in our core Linux operating system product and who could unknowingly become subject to Qt licensing fees in the process of developing Linux software. It would also show a lack of commitment to the Open Source community and principles that have proven themselves over and over and are a large part of our success. Without Free software, Open Source, and the development community, there would be no Linux.
After fully fudging...