Always stating the QPL (in)compatibility in GPLed code?

For refernce the QPL can be found at http://www.trolltech.com/products/download/freelicense/license.html.

I just read over the QPL. It is awfully strange. It allows you to distributed modified binaries conditioned on you guaranteeing free access to the source code of the software along with any modifications. However, it does not grant you the authority/power to distribute the original source code, only your personal modifications. Is this where all the confusion stems from?

Jason

Before Troll Tech rectified (largely, that is) the issue with the free version of Qt, there was a major concern about a non-free licensed library being part of what could be a core functionality to any Open Sourced library- not to mention that it was technically a violation of the GPL license to distribute anything but the KDE sources (This same issue we're talking about right now has been lurking since the beginnings of KDE and you'd get fiercely and mercilessly flamed into submission on mail or news lists if you brought up the issue- I know, I've been on the recieving end of some of it back before the 1.0 release of KDE.). I've been led to believe from several people on both the KDE and GNOME side of the fence that this issue was one of the things that caused the GNOME project to come into existance, along with some design decisions in KDE that the GNOME people didn't agree with (I side with the GNOME team on that regard, but KDE's still awesome.). So, what's the situation now? Troll Tech, made the license more free, making it palatable to the Open Source community, but didn't go far enough, making a license that is incompatible with the GPL and LGPL- which then prohibits the distribution of many of the KDE binaries, per the GPL. Seems to me that we're largely in the same boat as before, with only a slightly more palatable license on Qt.

Either the KDE team needs to migrate things to Harmony, GTK--, or Fltk, the KDE team needs to change all all of their licensing to be something other than GPL/LGPL for all packages, or Troll Tech needs to revise, yet again, their license to be compatible with the GPL/LGPL. Only the copyright holders may release binaries given the current situation- anyone else (incl. the KDE team themselves, in at least some of the cases within KDE...) can be construed as a copyright violation.

Finally... A post on this issue that's clearly made by someone who has at least a basic understanding of the issue. Thank you for restoring my faith in humanity ;)

Stuart.

PS My own personal opinion is that someone should come up with a license that provides GPL-style protection against use in non-free software, but that always behaved like the LGPL for software that was free (even if it was GPL-incompatible). I have some ideas on how such a license could be written - in fact, I had a copy drafted until I lost it to a hard-drive crash. I plan on re-writing it, and when I do, I'll post or link to it from my diary. I'd be interested in feedback on this idea. This wouldn't help KDE unless they re-licensed their software under my license, but it would provide a choice for people who want the protection of the GPL without the incompatibilities.

So, the way to decide the discussion about whether the QPL and the GPL are incompatible is to just say it many times in many places?

You are giving the people who believe the QPL and the GPL are not incompatible, the chance of... not licensing under the GPL (because GPL+exception != GPL) dammit, if I write software that requires Qt, of course it's meant to be used with Qt. If you are not sure, ask me, I'll clarify!. But I will not put it in the license, because the license I use IS THE GPL.

If you believe the software author's interpretation is the important one, then that interpretation (say, mine) in itself is enough, without changing the license.

If you believe that interpretation is not important, tacking at the end of the license a non-binding reminder like "BTW: you can't do that" is just pointless.

Either way, you achieve nothing, except giving the developer a chance to not release under the GPL, which he already has. Pointless again.

ralsina: If you believe that the GPL and QPL are compatible, then by all means place a note at the end of your license (not an exception) which says something like "Note: In the opinion of the copyright holder, this license is not incompatible with the Q Public License under which Qt is released. You may, of course, distribute this software linked with Qt."

This would be adequate for Debian to include your software, because a firm statement from the copyright holder overrules the license (even for those who believe the two are incompatible by default). Yes, it's kind of silly that you have to say it when you wrote software requiring Qt in the first place. But Debian have said that this would be adequate; isn't it worth making a statement like that (which obviously expresses how you feel anyway) just to end this stupid flamewar once and for all?

As to why it needs to be stated explicitly - my understanding (which could be way off) is that Debian feel that they need something that they could point to if they or any of their distributors ever ended up in legal hot water over this. A statement from the copyright holder would at least provide some sort of legal assurance that nobody is going to be sued. I can sympathize with that viewpoint.

Perhaps that would be the real solution for KDE itself - nobody from KDE needs to back down - they can continue to sincerely claim that there was never any problem with their choice of license, and that they're just adding this comment to satisfy the ridiculous claims of Debian folks. And the Debian people wouldn't need to back down either - they can continue to believe that there was a problem, and that the adding of this statement solved it. All that, just by KDE just putting a line in their licenses stating what they believe to be obvious anyway!

There are, of course, still issues with other people whose code has been used in KDE, who may have not believed that the two licenses are compatible (the KDE postscript viewer is the canonical example). But perhaps those people could head off the problem in advance by adding either an exception, or a statement that they don't believe there's a problem, pro-actively to their licenses.

Will it ever happen? I don't know. It seems to be nothing but stubbornness keeping the issue alive - it's SO easy to solve.

Not for a second. Debian has in the past removed KDE software from their distro that is not under the GPL, and is thus not in a license conflict.

I am talking about kdelibs, of course. And before a Debian guy comes up and asks: AFAIK, yes, kdelibs for a pre-alpha version of KDE2, that linked to the QPLd Qt 2.0, and that was undisputedly under the LGPL, was uploaded by a registered Debian developer to debian.org. It was deleted.

Why should I (or anyone else) believe this noticewill make any difference whatsoever regarding Debian? It's just a sad state of affairs.

If Debian wants that comment in any software I write, it's simple to get. Email me, and ask me:

"Do you interpret the license to your software as allowing linking to Qt? "

They will get an answer that says "yes", and they can save it in the .deb for all I care.

Roberto, I know you are cool with the linkage (we've had discussions over similar things in the past...)- but what about some of the authors of things that the KDE team derived from other GPL/LGPLed projects (such as Kghostview)?

As for Debian checking with everyone; that's the KDE team's job, not theirs- don't pan them for not including the packages if they've got issues with the way you're doing things. If you've got ambiguities in your licensing, they choose to omit things; which is what I see going on here. The issue is as I said it was; there's a more than merely percieved incompatibility with the licenses involved and nobody that could fix this mess is really doing anything substantive about it.

Its obvious (though perhaps legally ambiguous) that KDE developers who write code under the GPL and link it to Qt intend to allow distribution of their software. What isn't clear is when GPLed code by a third party is integrated into a KDE program. Qt's license is incompatible with the GPL - and a lot of people who license their code under the GPL have an issue with Qt's license. Apart from the legal issues its really really rude to link their code to Qt. If people did that with my code I would be really insulted - at least as insulted as if my code was ripped of by some proprietary software people - we're meant to be a community!

Please, if you're a KDE or Qt developer refrain from KDEifying GPLed programs or integrating GPLed code in your software.

Because of section 3, which reads.

  3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library.  To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License.  (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.)  Do not make any other change in
these notices....

If the LGPLed library is linked against a QPL library, I can't do that, as GPL is incompatible with QPL. Therefore, the licence is void.

About whether clearing up the licensing is my job or Debian's or whoever's.

I don't care. I *do not* believe my license is ambiguous. Why should I fix something I don't believe is broken? If Debian believes its broken, they can EASILY check if it is broken by asking the licensor (say, in some cases, me). If that is not their job, what is?

About KDE and foreign GPL code.

The only application in KDE2 that has foreign GPL code is, AFAIK, kghostview. And I am not positive about whether permission was granted for it or not. Again, that is easy to fix: 2 emails.

In KDE1, the only other foreign GPL code was in kvt.

Even if Debian, for instance, doesn't feel they must bother sending three emails, they still have a better solution than removing 50 applications: remove 2.

About incompatibility between LGPL and QPL.

Your post shows ignorance of basic licensing issues.

People doesn't violate licenses: ACTIONS violate licenses.

Changing the license of a piece of code to GPL is not an action that violates any of the involved licenses.

It is possible that after you switch to GPL, you end with code that you can no longer distribute because THAT ACTION would violate the license. The solution is, of course, not switch to GPL if you ever intend to redistribute the code, or not redistribute after you switch. Both courses of action are perfectly legal, IMHO, IANAL.

Maybe someone assumed wrongly that it was under LGPL. Mistakes do happen.

ralsina wrote:

So, the way to decide the discussion about whether the QPL and the GPL are incompatible is to just say it many times in many places?

My proposal was not about deciding if the QPL and GPL are compatible or not. This was a proposal for how to spread the information about the fact that they are incompatible if you intend to distribute a compiled program that includes code covered by the GPL and QPL.

Read section 2.b. of the GPL: it states that any work (e.g. the compiled program) that contains code covered by the GPL must be licensed as a whole under the GPL. This is the "viral" part of the GPL. This implies that if some parts of the code are covered by another license than the GPL, then their license must be compatible with the GPL in order to allow the re-licensing. If you also read section 7. of the GPL, you will see that you are not allowed to distribute your work if some obligations (e.g. other license) prevent you from fulfilling all the conditions of the GPL. The QPL imposes some restrictions that are not allowed under the GPL (distribution of patches), so with the QPL is incompatible with the GPL.

There is no problem as long as you are distributing your GPLed program as source code, as long as it does not include any code covered by the QPL. But if you compile your program, link it with the QPLed Qt library and distribute the binaries, then you are violating the GPL because the whole package includes code covered by the QPL and GPL and the GPL forces you to distribute this work under its own conditions, which cannot be done because of the QPL restrictions.

After having read many discussions about this (KDE archives, Debian pages, RMS explanations, Freshmeat editorial, ...), I think that the fact that the two licenses are incompatible does not need to be proven anymore. Even a large part of the KDE developers admit this, but at the same time they say (and they are right) that most of the code written for KDE was written with the implicit assumption that the GPL was extended to include the compatibility with the QPL.

So the problem that I was trying to solve here was not to explain why the licenses are incompatible (this has been discussed many times in many places), but to encourage the authors of GPLed software to include a clear statement about whether or not their code can be used in a program that has to be linked with Qt. Many people are not aware of the incompatibility that exists between the QPL and GPL, so stating this explicitely in many places (by adding an exception that allows linking with Qt or by explaining the problem) would help and may encourage developers to think twice about the licensing issues. Actually, I am always surprised about the number of developers who are surprised when they discover that the GPL is more restrictive than they thought, because this "viral clause" is not easy to satisfy. Some of them switch to another license such as the BSD license or the Mozilla licence after discovering the problems of the GPL. Well, so be it. But it is better to be aware of these problems before it is too late.

If the Qt exception is added to many programs (or a statement explaining why the code cannot be linked with Qt, for those who choose to be strictly GPL), then the information will spread and nobody will silently ignore the problem. The current status quo is a very bad situation.

rbrady - Sorry, even though I disagree with ralsina about most aspects of this, I have to agree with him that you are wrong about the LGPL. By your logic, the LGPL would not allow linking with proprietary code either (which is exactly the point of the LGPL). Think about it - the GPL is incompatible with that too.

To explain why this is so, you have to realize exactly what the incompatibility with the GPL means. It does not mean that distributing the KDE source is illegal (even though the KDE source "requires" Qt to be useful). What it means is that distributing something that is a "derived work" of both the KDE source and Qt (eg, a binary of KDE compiled against Qt) is illegal.

How does this apply to the LGPL? Well, the LGPL states that you can re-license the code under the GPL. It doesn't say that you have to be able to get something useful if you do so. Perhaps you wanted to take some code from kdelibs that didn't link with Qt, and use it in a GPLd program. Or you wanted to port kdelibs to use gtk and release the result under the GPL (which would be a strange choice of license, but it's allowed). That's what the LGPL allows. It doesn't require that changing the license to the GPL would result in something immediately useful, just that you can do it.

Specifically, you can relicense the kdelibs source under the GPL with no problem. The only problem is if you try to compile and distribute it after doing so without removing Qt.

It would be a fact, if you could show a court decision saying it's a fact.

I could even be convinced if you could show me a real lawyer who dares put his name behind that opinion on the incompatibility.

Right now, what we have is blatant assertion by amateurs. I have argued that a zillion times before with what seems like hundreds of them, and the arguments are usually of very low quality (say ,"dude, the GPL forbids putting extra restrictions on code linked to GPL code", when the GPL says nothing like that).

I refuse to start that argument here again. I will only say, one more time, that your opinion is not a fact, just like mine is not.

ralsina: Have you read Debian's stance on KDE, which is the closest thing I know of to an "official" position statement by the Debian project? Admittedly, it's probably not written by a lawyer, but it does reference the specific clauses in the GPL and QPL that appear to conflict. If you believe the two licenses do not conflict, perhaps you could post a brief explanation of why you believe this argument is flawed.

I'm genuinely interested, because you're the first person I've actually encountered who believes this, and I'd really like to know what the basis is for your belief.

I do agree that until a court or a lawyer states an opinion, nothing can be taken to be unarguable fact. However, I've seen a number of detailed arguments based on the text of the two licenses that seem to indicate that they are incompatible; I've never seen an argument the other way that even references the text of either license. This is the primary reason that I believe the licenses are in conflict - I have been unable to find a flaw in the logic of the people who claim they are incompatible, and nobody who believes otherwise has even tried to point out any flaws. You're welcome to be the first.

Debian's stance is so flawed, it calls for the removal of kdelibs because of a conflict between the GPL and the QPL.

That is only the most flagrant sign of that "document" being at least, poorly researched.

Then again, it is a document written by amateurs who hold a strong ideological position. They are as far from being impartial as I am.

For other specific explanations of why I believe their arguments don't hold water, I redirect you to deja.com and to the kde-licensing mailing list. I have no interest on discussing the legalese again.

ralsina: I believe the press release linked discusses the Qt1 (the Qt Free Edition license) and KDE license conflict; hence, it does not necessarily apply to this situation.

I think Joseph Carter's article speaks to the current situation, at least for code (and bits thereof) that KDE appropriated from other sources. The bottom line is you either buy his argument or you don't.

I generally agree with the point that stuff written by the KDE folks (and not borrowed from other sources) probably is implicitly OK (mainly because if the authors tried to sue a distributor, it would be pointed out that they themselves linked the code against Qt). Whether or not that leaves a usable system, I can't say.

lordsutch: the situation (alleged license incompatibility) is just the same after the license change, according to any Debian guy I've read.

The situations are similar, but not the same. We now have an unencumbered Qt that can be used with new code and with BSD code. That, in and of itself, is a big win.

Saying nothing has changed is like saying WW1 and WW2 were the same because both featured England and France fighting Germany.

FWIW, it seems easy enough to get around the conflict; you get KDE separately from Qt. Since Qt is a standard component of Debian 2.2, KDE is legal to use on Debian 2.2 if you don't get it from Debian. The tricky part is making it legal for Debian to distribute it too.

I am increasingly tired of people writing software that requires either Gnome or KDE. Gnome and KDE are big packages, they take up a lot of space and they take up a lot of my time keeping current with whatever version of Qt or Gtk I need for $APPLICATION_OF_THE_MONTH.

Just what are the big advantages you get from KDE and Gnome that makes these heavy Microsoft-like library farms worthwhile?

A new editorial regarding the QPL-GPL issue has been posted on Freshmeat:
http://freshmeat.net/news/2000/07/15/963719999.html

I think that it summarizes the problems more clearly than most of the other articles and discussions (including here, on Slashdot and on Usenet). The comments are interesting too, although some of them are missing their target because their authors did not fully understand where the problems are. Here are a few things to keep in mind while reading the editorial and the comments:

• There are no problems if you distribute a GPL'd program using Qt, as long as you only distribute the source code. But the GPL and QPL are incompatible if you distribute a compiled executable, because it would be a derivative work (the program uses the macros and types defined in the Qt header files) and the GPL does not allow the distribution of derivative works unless all parts of the work can be released under the GPL, with some exceptions that are debated in the editorial.
• The GPL cannot force you to change the license of other pieces of code and it cannot force you to use the code in some specific way, but it can (and does) prevent you from re-destributing the GPL'd code if you do not meet some conditions. One of these conditions is that all parts of a derivative work must be distributed under the GPL (see section 2b, the so-called "viral clause").
• If you are the author of a piece of code, you are free to distribute it under any license and to change the license (for new versions) at any time. However, this is only possible if you are the only copyright holder. If you have used any code that was contributed by someone else, then all contributors must agree on the new license. This is a problem because some KDE applications (not many, fortunately) have borrowed some code from other applications and it is not easy to get the agreement on the "Qt exception" from all authors and contributors.
• Some people say that we need a new version of the GPL without the viral clause, because the current version is too restrictive and the new one would solve the KDE problems. But they fail to understand that some authors of GPL'd code do want this restriction, and chose to release their code under the GPL precisely because of it (this does not necessarily apply to all authors of GPL'd code, but those who are in that category cannot be ignored).

Note: the LGPL is compatible with Qt and the QPL. The LGPL is less restrictive than the GPL and allows linking with non-free software. The title of one of my previous comments was incorrect (I checked the article before posting, but I forgot to fix the title). Sorry for the confustion.