Articles / Response to Troll Tech on Q…

Response to Troll Tech on Qt, KDE, and the QPL

This editorial by James Ramsey "attempts to counter Troll Tech's apparent misconceptions about the QPL/GPL controversy, and attempts to walk through the GPL to explain why it conflicts with the QPL." QPL 2.0 is coming. In my opinion, this is a great development that will hopefully end this whole messy controversy with the QPL and the GPL. Why, then, am I even bothering to write this?

There are two reasons. First, I've being following the QPL/GPL controversy for a while, trying to sort out what exactly is going on. It has taken me some time to sift through all the discussion and the flames, and one thing I've noticed is that there hasn't been a point-by-point explanation of why the QPL and GPL supposedly conflict. Second, I think Troll Tech only halfway understands why the QPL and GPL supposedly conflict, and if it doesn't fully understand the reasons for the conflict, it may only turn the QPL from one possibly GPL-incompatible license to another. The editorial that Eirik Eng from Troll Tech posted, in my opinion, seemed to indicate a very partial understanding on Troll Tech's part. While I agree with its conclusions that the "patch clause" and clause 6c of the QPL should be nixed, I found that it did a poor job of rebutting the arguments claiming that the QPL and GPL conflict. It seemed to me that Eirik Eng, at least, was rebutting some of the noise surrounding the QPL/GPL controversy, rather than dealing with the crux of the controversy itself. Therefore, I'm going to go out on a limb and try to detail the argument of why the QPL and GPL conflict, based on what I've observed from the various discussions, flamewars, etc.

Troll Tech's Objections

Here are the objections Eirik Eng came up with to rebut the claims that the QPL and GPL conflict:

"It all comes down to how the terms 'Program' and 'Derivative Work' under copyright law are to be interpreted in the GPL.

For the 'Program' case, it has been claimed that when a program uses the Qt API, Qt becomes a part of that program. We, and lawyers we have consulted, cannot see how this can be the case. And if it is, which version of Qt? Windows, X11, or Qt/Embedded? All? Does this also apply to other things? Does the X server become a part of a program that uses X? Does the Qt/Embedded server become a part of a program that uses Qt/Embedded?

When we first released Qt there was already de-facto acceptance in the community that one could make GPLed programs using Motif, even before Lesstiff [sic] came along. Motif was a proprietary and non-free library with a much stricter license than Qt.

Now, for the 'Derivative work' case, it has been claimed that a program using Qt is a derivative work of Qt, or vice versa. Since it is programs that use Qt that use the GPL, only the latter case is relevant in license discussions. The GPL only talks about programs that are derivative works of the GPLed program, not the other way around. Some people have seriously claimed that Qt is a derivative work of KDE. Quite frankly, we found such a notion to be ridiculous, Qt existed long before KDE came along."

I will thoroughly agree that the "Derivative work" case is ridiculous. It also does not correspond to anything seriously argued by Debian. The argument to the "Program" case is actually somewhat closer to what Debian seems to be arguing. However, the problem is not with the meaning of "Program" in the GPL, but rather appears to be with the meanings of the terms "source code" and "module" in the GPL.

What follows is my attempt to sort what I've read on the mailing lists of Debian and kde-licensing into some semblance of a coherent point-by-point explanation of Debian's objection to linking QPLed and GPLed software.

The Argument for the GPL and QPL Conflicting

I'll start with the first part of Section 3 of the GPL:

--begin quote--

  1. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
    1. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
    2. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
    3. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

--end quote--

Note that, in subsections 3a and 3b, the source code must be distributed under Sections 1 and 2 of the GPL. Even in subsection 3c, the source code would have had to have been distributed under Sections 1 and 2 of the GPL, since the recipient of the code would have obtained it from someone who distributed it under subsection 3b, which requires the source code to be distributed under Sections 1 and 2.

Section 1 of the GPL is fairly innocuous. In short, what it says is that one may copy and distribute the source code verbatim so long as all the copyright notices and notices referring to the GPL are left intact. The clincher is in Section 2, which states

--begin quote--

  1. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
    1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
    2. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
    3. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

--end quote--

The significant part is subsection 2b. In order to be able to modify the source code, one must be able to license the source code as a whole under the terms of the GPL. This means that the various parts of the source code must have licenses that either 1) allow relicensing under the GPL or 2) have no restrictions above and beyond what the GPL requires, so that the conjunction of the terms of the GPL and the terms of the licenses of the various parts of the GPL is the GPL itself. (Think of the term "conjunction" in a mathematical sense. The conjunction of the sets {1, 2, 3} and {1, 2, 3, 4, 5, 6} is {1, 2, 3, 4, 5, 6}.)

So why would this effect the QPL? If a QPLed work is considered to be part of the "source code" to the work, then for subsection 2b to be satisfied, the QPL would have to 1) allow relicensing under the GPL or 2) have no restrictions above and beyond what the GPL requires. Now the big question is, would the source code to a QPLed library, such as Qt, linked to a GPLed work, be considered to be part of the source code of the GPLed work? This is the crux of the controversy.

Here is the part of the GPL that defines what the "source code" to a work is.

--begin quote--

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete 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. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

--end quote--

Is a QPLed library a "module" of whatever binary links to it? I could argue that a library is an off-the-shelf piece of software to be used as a component of other software, and when it is used as such, it becomes a part of that other software, or a module of that software. I'll leave it at that for now. If the QPLed library is considered a module of the software, then unless said QPLed library is normally distributed with the operating system that the executable is supposed to run on, the source code for the library has to be distributable under Sections 1 and 2 of the GPL.

Does the "special exception" apply? The special exception states that "the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." First off, is Qt "normally distributed with the operating system that the executable supposed to run on"? Many Linux distributions distribute Qt as part of the distribution. However, the main reason they do is so that KDE can run, and the exception for components applies "unless that component itself accompanies the executable" (emphasis mine). Well, Qt accompanies the GPLed KDE executable on the CD of many a Linux distribution, so the special exception doesn't apply.

Does the QPL allow software licensed under it to be relicensed under the GPL? No. Does the QPL have restrictions above what the GPL imposes? Yes. There are two that have been the most discussed. First, there's the so-called "patch clause," which requires that modifications must be made in a form that is separate from the Software, such as patches. Second, there is clause 6c, which says that "If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one." (Note that "the Software" refers to Qt, or whatever is the QPLed software "the items" depend on.) Since there are restrictions that the QPL has that are above and beyond what the GPL requires, the source code as a whole cannot be licensed as a whole under the GPL, and so section 2b of the GPL cannot be satisfied. Thus, if a QPLed library is linked to by a GPLed work, and the QPLed library is considered to be a "module" of the GPLed work, then the GPL and QPL come into conflict.

The Core Issue of the Argument: "What is a module?"

The "source code" for an executable work includes all modules that the executable work contains. "Module" can mean a lot of things, and it is not defined in the GPL itself. How do we figure out what "module" is supposed to mean?

The GPL is the brainchild of GNU, so it may be helpful to see how the GNU folks interpret their own terms. The pages of the GNU Web site offer some clues: Their page on what do to in case of violations to the GPL mentions that when checking the facts regarding a possible GPL violation, one should find the answer to the question "Is the available source code complete, or is it designed to for linking in other non-free modules?" The licenses page also refers to linking modules together. It appears from the reference to linking that "module" is almost another word for "library", with the main difference being that "module" is perhaps a bit more general. Further, in the page where RMS argues against using the LGPL for new GNU libraries, he says, "If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs." Here the terms "module" and the term "library" are used almost as synonyms. Clearly, the people behind GNU, the authors of the GPL, consider libraries to be "modules."

It would be wise, though, in the next version of the GPL, to more carefully define "module" rather than rely on the intent of the GPL's authors.

Response to Troll Tech and Its Objections

Troll Tech is partly right when they say that "it has been claimed that when a program uses the Qt API, Qt becomes a part of that program." The issue is whether the Qt library is considered a module of a Qt-based executable work. Where Troll Tech misses the point is in the phrase "when a program uses the Qt API." The issue hinges on what is going on with the binary, the executable work, and whether the libraries the executable work links to are considered "modules", not per se whether the program is written using the Qt API (although a program must use the Qt API to link to Qt). The answer to the question of "which version of Qt? Windows, X11, or Qt/Embedded? All?" is quite simply "Whatever Qt binary the executable work actually links to." As for the question "Does this also apply to other things? Does the X server become a part of a program that uses X?", the answer may very well be "No, but libX11 does become a module of the program." The intention of GNU seems to be to try to prevent GPLed software from depending on anything less free than the GPL.

Eirik Eng also mentioned "de-facto acceptance in the community that one could make GPLed programs using Motif, even before Lesstiff [sic] came along". However, Motif, at least on proprietary Unix, certainly falls under the special exception that "the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." Motif is most certainly standard equipment on proprietary Unix; its whole reason for existence is to be the standard GUI on Unix. Further, Motif is not distributed along with any GPLed software based on Motif. Binary distributions of Motif-based GPLed software for Linux, though, may be problematical, since Motif is not normally distributed with most Linux-based distributions, and it would be considered a "module" of said GPLed software. In any case, "de facto acceptance" of a practice does not prove that practice is correct, only that it is commonplace.

That said, Troll Tech is on the right track so far with its plans for QPL 2.0. Removing the "patch clause" and clause 6c of the QPL is a good start. However, if Troll Tech does not know why they are doing what they are doing, it may either not go far enough or may introduce new problems with their next version of the QPL.


J. J. Ramsey <jjramsey_6x9eq42@yahoo.com> is a contract program student at Pacific Christian College taking courses toward a Mechanical Engineering major at California State University Fullerton. As is almost needless to say, he is not a lawyer.


T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

Recent comments

24 Jul 2000 17:54 Avatar blackadr

GPL vs. QPL vs. xPL
Can't we all just get along? :)

20 Jul 2000 21:39 Avatar jeffcovey

Note from Richard Stallman
Mr. Stallman asked me to post this comment for him:


"I appreciated your clear article explaining why the QPL and the GPL do
conflict. I would like to correct one small point in the article,
with the effect of making the argument stronger. You pose this
question:


First off, is Qt "normally distributed
with the operating system that the executable supposed to run on"?

But that is not quite the right question, because the words of the GPL
are slightly different:


...normally distributed (in either source or binary form) with
the major components (compiler, kernel, and so on) of the
operating system...

Some distributions of the GNU/Linux operating system do include Qt,
but that is not what these words are concerned with. They are
concerned with whether Qt is normally distributed with one of the
system's major components.


Qt is not normally distributed with the compiler, GCC, or with the
kernel, Linux, or with the window system, XFree86, or with any other
major component of the GNU/Linux system. So Qt does not qualify for
this exception.


I hope that Troll Tech will make the QPL compatible with the GPL, and
removing the patch requirement is a big step in that direction, but it
is not entirely enough. We've had some discussions about this, on and
off, and I hope that eventually the QPL can become compatible with the
GPL, but we can't be sure what the future will bring."

19 Jul 2000 19:03 Avatar teropulkki

Linking is non-issue
It does not matter how the different pieces of code were separated from each other -- Only how large groups of code they're distributed in.

To enable communication between software modules, there's 3 entities involved. 2 entities being the receiver and sender of the communication and there's 3rd entity being the mechanism that enables communication.

Similarly with licenses, you can divide software modules to 3 pieces:
A) Code that is under GPL
B) Code that is not under GPL and does not allow to be converted to GPL
C) Code that enables communication between GPL and non-GPL.

If you distribute all 3 pieces in one package, there is good chance you're
distributing GPL and non-GPL code &quot;as whole&quot;.

GPL's nicest feature is that it forces users to make explicit choice to
mix GPL'd and non-GPL'd code! Users will be forced to download C separately! (even if A and B were distributed togeather) This is why combination of qt and kde might not be compatible with GPL preventing kde's distribution! Users do not need to make explicit choice to download qt - there are many places where you can get the whole kde - qt included... (Unfortunately A and C are combined in kde -&gt; the only ways to distribute kde/qt is by AC|B or ABC... And when distributing ABC, one must be much more careful with reading license terms of GPL and B...) Thus it is risky to include them to same media!

You can always distribute code A and code B in same package -- but only if you do NOT distribute code C!

16 Jul 2000 19:17 Avatar jjramsey

Re: &quot;What is a module?&quot;
&quot;Well, it is completely obvious to me that a dynamically-linked library is not &quot;contained&quot; in the executable work.&quot;

You are presuming that &quot;contains&quot; necessarily means a spatial proximity, that the bits of the modules of the executable work have to be physically near each other.

&quot;In any event, if in fact the library did have to be licensed under the GPL, one could not link against libc, for example.&quot;

You forget the &quot;special exception.&quot; On just about any Unix-like system, libc &quot;is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system&quot; so the special exeception applies, whether libc is LGPL'd or proprietary.

&quot;The fact that non-lawyers are doing the debating leads to one of the most common mis-interpretations of legal language, repeated by Jeff: he states that &quot;to be licensed as a whole at no charge to all third parties under the terms of [the GPL]&quot; means &quot;under terms no more restrictive&quot; than the GPL. This interpretation is totally implausible.&quot;

One, &quot;to be licensed as a whole at no charge to all third parties under the terms of [the GPL]&quot; means that the *individual pieces* can be licensed under terms no more restrictive that the GPL. When the terms of the licenses of the individual pieces get conjuncted with the GPL itself, the result is effectively the GPL itself. This hardly seems &quot;totally implausible.&quot;

16 Jul 2000 18:06 Avatar jjramsey

Re: Perspective
&quot;What is unstated in the GPL itself, but which is the stated goal by GPL advocates is the Zeroeth rule: to provide freedom for developers. &quot;

I'm not so sure that's true. The GPL was meant to be anti-proprietary at nearly all costs. It is intended to make it almost impossible to encumber free software with anything proprietary. Remember who brought the GPL into being in the first place--Richard Stallman. This guy is not exactly known for compromise, and he considers proprietary software to be evil. I'm sure that if you were to ask him, freedom for developers would *not* include the freedom to link to an arbitrary library, dynamically or otherwise, since that would open up a loophole in the GPL that could be used to infringe upon the users' &quot;rights&quot; to copy, modify, and redistribute the software.

For example, say a vendor modifies a GPL'd application so that a sufficiently significant portion of its functionality now comes from libraries that the vendor wrote *from scratch*, and that the vendor makes these libraries proprietary, so that the application, though technically GPL'd, is effectively encumbered by the proprietary license of the vendor's libraries. This is the sort of loophole that would occur if linking to arbitrary libraries were allowed.

The GPL is, in a sense, a paranoid license that tries to block all possible ways of encumbering free software with proprietary restrictions, even at the cost of frustrating developers.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.