confused about Qt QPL/GPL license

(EDIT: changed the title. Thanks for the discussion, I am less confused now :) )

How many of you, when confronted with the Qt licensing option (during the 'configure' step of the compile) select the GPL as your Qt/X11 license? I had always done so, but I have come to understand that using KDE precludes this option.

If you use KDE, the QPL is your only non-commercial licensing option, because a GPL'd library cannot be linked with non-GPL code. KDE contains lots of this. Here's a partial list, just of the core apps and libs:

  • kdelibs (LGPL)
  • kwin (BSD)
  • kicker (BSD)
  • ksmserver (BSD)
  • klipper (Artistic)

There are many more besides these.

Anyway, just some food for thought. Since there's no *explicit* choice made between QPL and GPL, I guess anyone who mistakenly chose the GPL like I did can just retroactively change their mind and continue using Qt under the QPL. I have heard the opinion that the Qt licensing option can be interpeted as allowing the user to decide on a per-application basis which license they will use, but I can't really buy that. Besides, it doesn't matter since kdelibs is LGPL'd, and therefore can't be linked with GPL'd Qt/X11. (EDIT: actually, combining a GPL'd lib with a LGPL'd lib can be allowed, *if* the resulting app is GPL'd. So maybe there's hope for this "per-application" Qt licensing meme, though it still seems like a huge stretch to me)

BTW, why not eliminate the GPL option in qt-copy? It just adds confusion.

(EDIT: how am I supposed to insert paragraph breaks? it doesn't recognize the p tag, so I used two br's in a row)


I understand what you are saying about the dual licensing giving you both licenses at the same time. It's the world's only license with quantum-mechanical eigenstates. I just don't see why it's necessary. There's no problem linking a GPL'd app with a QPL'd library, it's just the other way around that has problems.

KStars: A desktop planetarium for KDE

By Jason Harris at Tue, 08/26/2003 - 21:12

Replying to my own comment...

Trolltech released Qt/X11 under a QPL/GPL dual license to appease the FSF, who claimed that the QPL was not a Free (i.e., GPL-compatible) license. If the two licenses are not compatible with each other, how can they be simultaneously applied to a piece of software? I think the only way that makes sense is if Qt is licensed under the QPL for non-GPL'd apps, and under the GPL for GPL'd apps. It seems to me that no single app can use both the QPL and GPL.

I invite further comments on this.

KStars: A desktop planetarium for KDE

By Jason Harris at Tue, 08/26/2003 - 22:58

Since Qt is entirely Trolltech's code, they can license it however they want. Remember, the GPL is based on copyright law. Copyright law does nothing to bind the hands of the creator, only people distributing the work. So TT can distribute Qt under the GPL and under any other license they want. Now, this has interesting implications. While GPL'ed apps can use Qt, GPL'ed Qt cannot use GPL'ed code. The GPL/QPL duality implies that TrollTech must be allowed to distribute Qt under the terms of either license. Since they own the code, they can do this for their code. However, if they don't own a particular piece of GPL'ed code, they can't distribute that code under the QPL.

It helps to think about licenses as not intrinsic to a code base, but specific to a particular distribution event. Say I'm writing a GPL'ed app. My app becomes a derived work according to copyright law. So in order to distribute my app, I need to make sure I have permission from Trolltech to distribute Qt. By downloading and using Qt in a GPL'ed app, TrollTech is implicitly giving me a license to use the code under the terms of the GPL. Now, say I want to write a QPL'ed app. By using Qt in my QPL'ed app, TT is implicitly giving me a license to use the code under the terms of the QPL. Its not so much that Qt is both GPL and QPL at the same time, but that it can be used under the terms of either license for a particular distribution event.

By KDE User at Wed, 08/27/2003 - 02:37

Well, first, this type of dual licensing isn't uncommon. Off the top of my head, Perl, Mozilla and Open Office all do the same thing.

Second, to continue the physical analogy (since it's kind of fun) -- you could say that it does exist in a superposition of the licenses. So long as you don't set up licensing requirements of the works that use Qt you don't have to observe which license it's under.

Basically -- if your work that uses Qt requires use of the GPL'ed Qt, but is incompatible with the QPL (i.e. using code from a GPL'ed app which doesn't contain an exception to allow use of the QPL) you're only observing in one locataion, which will cause the licensing to collapse into the state of being GPL'ed. Conversely if you're using something that requires the QPL but is GPL incompatible then you're only observing in a place that would cause it to collapse into a QPL'ed license. However, if you're using a license that is compatible with both -- say a X11 license -- no observation is required and Qt's licensing persists in it's dualality which means that derrivative works of both Qt and your app can use either licensing scheme. :-)

By Scott Wheeler at Sun, 08/31/2003 - 17:38

Your problem lies in the "because a GPL’d library cannot be linked with non-GPL code" statement. This is not correct. Non-GPL'ed code can link to GPL'ed code, as long as the license of the non-GPL'ed code is GPL-compatible. A comment RMS made on the GNOME mailing list confirms this:

"So if you want to write a non-copylefted application, release it under
the X11 license, and link it with a GPL-covered library, that is
allowed. The linked executable would be covered by the GPL, of
course, but the app source code would be covered by the X11 license
Note that all the licenses you mentioned (LGPL, BSD, Artistic) are GPL-compatible according to the FSF. This means that, while the final binaries get auto-GPL'ed, all the source code can remain under its original license.

By KDE User at Tue, 08/26/2003 - 22:51

Thank you for your comment. That's very interesting, I hadn't fully appreciated the difference between the source code's license and the executable's license. So, even if Qt was licensed solely under the GPL, the noatun souce code (for example) could be licensed under the BSD license, but the noatun executable would be GPL'd. Yes, that makes sense.

So, in the About box for a KDE app, the License Agreement tab refers to the code, not necessarily the executable. Hmm.

thanks again.

KStars: A desktop planetarium for KDE

By Jason Harris at Tue, 08/26/2003 - 23:06

Hi, I think you are missing a few things here.

First, and most important, the QPL is a Free Software license, but it is incompatible with the GPL. Using any KDE app that is GPL'ed on a QPL license violates the license *unless* you are the sole author (or all the other authors agree) to make an exception. This prevents reusing code from projects that are GPL'ed but not originally intended for KDE.

Secondly, I can write a BSD-licensed program and have it link to a GPL'ed library. However, for a practical matter it is as if the whole thing was licensed as GPL because you cannot take advantage of the BSD license's ability to make that code proprietary so long as it depends on a GPL'ed library. However, it doesn't actually make the code permanently GPL'ed. If I download your BSD licensed source code, and take out the dependency for the GPL'ed library, I am no longer restricted by the GPL.

So, there really is no reason not to link to a GPL'ed library unless you are planning to make a proprietary app. By making one's code BSD or LGPL licensed, you also do something else: you allow those who buy a full Qt/X11 license to make proprietary KDE applications. In otherwords, the BSD license is sort of like hooking up a 10/100 switch to a standard Ethernet card. You can't go at 100 mbps, but that capability is there should you switch to a 10/100 Ethernet card.


By KDE User at Wed, 08/27/2003 - 02:43