Arnt Gulbrandsen
About me • About this blog

Red Hat's Page about the Qt Free Software License

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 info@troll.no.

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

Marc Ewing
CTO, Red Hat Software

The Qt widget library, published by Troll Tech [1] 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 [2], 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 [3], while the Qt license is purpose-written by Troll Tech to allow use free of charge for developing free software [4]. In fact, this license poses restrictions on authors of Open Source software that are contrary to the Open Source Definition [5], and restrictions on authors of non-Open Source software that would not exist if Qt were licensed with the GNU LGPL [6].

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.

Finally, 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:

  1. The source code to your program must be distributed with the program (or be made readily available).
  2. 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
  3. The source code must be distributable under the terms of sections 1 and 2 of the GPL.
  4. 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 part 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 source code:

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 compiler, 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 absurd.

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 Definition, 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. [7]

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