A possible solution to the Qt/KDE license dilemma

Posted 16 Jun 2000 at 10:34 UTC by TordJ Share This

There has once again been quite a stir in the community about the Qt/KDE license incompatibility after Dr.G√ľnter Bechly's unsuccessful attempt to solve the problem by offering the KDE team a donation of $3000 if they came up with a solution.

The attempt was clearly doomed to failure since too many people already have contributed, either directly or indirectly through code reuse, to the KDE code base to make it possible to get all peoples written acceptance to change the license. Besides, that would both be a moving target, since new code all the time gets linked to Qt in the shape of KDE applications, and largely impractical for future development.

However, when reading through the aftermath of it all in a Slashdot discussion I came up with an idea that both might work and be a quite convenient solution...

LOOKING AT QT FROM ANOTHER PERSPECTIVE

Most people thinks about Qt as a drawing/GUI toolkit, a library to which you link your programs to get access to a number of functions and procedures which makes it easier and faster for you to develop your application. Indeed, this is also the way TrollTech markets Qt.

However, if you take a closer look at TrollTech's "Overview of Qt" text on www.trolltech.com, you come across two quite interesting sentences:

"To achieve full portability of Qt-based programs, Qt also includes a set of classes which protect the programmer from OS-dependent details in file handling, time/date handling etc."

and further down, in another context:

"Most of these classes are GUI specific; however, Qt also provides template-based collections, serialization, file and a general I/O device, directory management, date/time classes, regular expression parsing and more."

Now, unfortunately I'm not a Qt programmer myself, so I have no experience from using Qt, but from these two quotes it seems to me that Qt is much more than just a graphics toolkit. It sounds like it's almost a complete OS on its own. An ultra-portable "virtual OS" with its own API, running on a host OS, which it is fully capable of hiding completely for most programs.

Maybe we should just classify Qt as an OS on it's own instead? It has lots of the characteristics. You program for the Qt OS and it runs "emulated" on UNIX/X11, Windows or the Linux framebuffer. The code can be ported seamlessly between these environments since it is neither UNIX or Windows code, it's Qt code. This might be to stretch the definition of an OS a bit too far, but on the other hand, Qt is clearly more than your average graphics toolkit, making it somehow ending up in between being a "Virtual OS" and a graphics toolkit.

If we decided to re-classify Qt as an OS, what would then happen? All the licensing problems would immediately be solved. You are allowed to port GPL programs to any non-free OS like Windows, BeOS, MacOS etc, so why wouldn't you be allowed to port other peoples GPL programs to a FREE Virtual OS like Qt?

This could easily be clarified in a future revision of the GPL by adding a statement along the lines of "In regards to the GPL, we classify Qt, a product of TrollTech AS in Norway, as a 'Virtual Operating System' which should be treated throughout this license as any other Operating System". Please note that this would be a clarification of the GPL, not a change, since Qt currently isn't mentioned in the GPL at all and therefore has not been classified as either a toolkit or OS. This would most likely (IANAL) even affect previous versions of the GPL and all work licensed under it, since it (once again) isn't a change but a clarification of something which earlier was unspecified, unless the copyright holder of that work disagrees.

This might seem like bending the words and concepts to reach the goal, and that might be the case. But remember, we are NOT bending the INTENTION under which all this code was placed under the GPL, because I have still not heard any free software author object against his code being included in KDE programs. All developers seems to agree that the QPL is an acceptable open source license and allow their code to be linked against Qt. It's just the licenses, or should we say "todays interpretation of the licenses" which makes it impossible. You could even go so far as to say that we clarify the wording to meet the intention.

You should also note that this change of classification wouldn't necessarily erode the GPL as a license. It would still be illegal to include GPL:ed code into QPL:ed programs and the other way around. GPL:ed code would not end up in proprietary products and it would still not be allowed for other non GPL/LGPL/BSD libraries to be linked against GPL code.

One side-effect we would get though is that it would suddenly be allowed to compile GPL code against the Professional Edition of Qt and that way port KDE programs to Windows. This would both be good and bad, good because free software would reach more people, bad because Windows users wouldn't be able to recompile the programs unless they purchase the Qt Professional Edition, crippling their ability to take part in the free software movement and cause much frustration.

PERSONAL REFLECTIONS AND CLOSING COMMENTS

Let me just make this 100% clear: this is just an idea which I've tossed into the air. I'm not 100% sure that I want this solution myself, but since I got the idea I've been thinking about it and decided to publish it for public discussion. Ask me again in a year or two and I might just say "Nah, that was a stupid idea, I wish I never had said it" or I might say that it was a very good idea.

What bothers me about this solution is that it is a compromise. We would all like Qt to be available under the GPL (not LGPL, TrollTech needs to get money from developers of proprietary software), but they have decided not to and if we re-classify Qt as a Virtual OS, we will have compromised.

This compromise won't hurt us and probably not the next either, but if we start to compromise like this, where do we draw the line? The free software movement has in many ways benefited from the GPL being very strict and uncompromising and since we are a lot of individual developers, scattered around the world, we need to stand united, pointing at the GPL screaming "This is our law! It's uncompromisable, if you break it we'll fry you!". Making some kind of special arrangement for Qt will make other software companies try to get the same kind of special treatment. There is also a risk it might give the impression that we are weak, making more companies deliberately break the GPL.

However, I do believe that this solution might be much better than todays "pretend there's no problem" attitude. By going on like this we keep eroding the GPL, giving the signal that it isn't important if you comply with it completely as long as nobody gets too upset since both the KDE developers and all distributions from Caldera to Red Hat are breaking it deliberately anyway. Wouldn't it then be better to bite the bullet, make one clear exception in the GPL and once again be able to say "This is our law! We all follow it, and so must you if you want to play with us!"?

We have to face the facts, KDE is here to stay, KDE requires Qt and it might be better to deal with this issue now than let the current license fiasco go on for all the foreseeable future. This is just one more possible solution, brought to the table by someone who isn't really involved, but cares about the outcome.


Messing about with words, posted 16 Jun 2000 at 10:53 UTC by listen » (Journeyer)

Defining QT as an operating system makes no technical sense - it is only useful if you want to hide this particular violation of the GPL. This would be far worse than the current situation, leading to an attitude of "You can violate the GPL as long as you get lots of people to use your stuff".

We have to face the facts. KDE is illegal to distribute in binary form. Thats it. No amount of messing with words will change that.

The fact that the majority of Linux distributors have chosen to ignore this in the belief that no one will sue them is irrelevant. The situation can only be solved in one way - the authors of KDE changing their licence, or Troll Tech chnaging to the GPL. If the authors of KDE can not contact the copyright holders, then they will have to rewrite the code. Tough. Thats what you get for violating the GPL, or any other licence.

Good point, but I don't agree completely... Of , posted 16 Jun 2000 at 12:06 UTC by TordJ » (Master)

"We have to face the facts. KDE is illegal to distribute in binary form. Thats it. No amount of messing with words will change that."

Be careful how you use the word "illegal". It is against the wording of the GPL, but that doesn't automatically makes it illegal. If the copyright holder accepts the way you use it, it's still legal. The only real problem we have here is that it's impossible to get the written permission of all the contributors, since at least 95% of the contributors seems to agree to KDE's use of their code and the rest of the code can be replaced without too much work if the authors just could step forward and tell them what code they don't allow to be in there.

"The fact that the majority of Linux distributors have chosen to ignore this in the belief that no one will sue them is irrelevant. The situation can only be solved in one way - the authors of KDE changing their licence, or Troll Tech chnaging to the GPL. If the authors of KDE can not contact the copyright holders, then they will have to rewrite the code. Tough. Thats what you get for violating the GPL, or any other licence."

I agree that the best sollution would be TrollTech changing to the GPL, no question about that, but there are more sollutions, which might not be desirable, but would work.

Remember the following clause that is placed in most GPL programs?:

"you can redistribute this program and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version."

This means that the license can be changed by FSF to allow linking to Qt even without the authors permission. Of course, a change like that would have to be done very carefully and should only be done if a very clear majority of free software developers (at least 90%) are in favour of such a change.

Besides, the KDE authors changing the license wouldn't really help either even if it was possible. New KDE programs pops up all the time, written by people from all over the world who doesn't know or care about the special permission needed to link against Qt, gladly borrowing code from other projects.

"Defining QT as an operating system makes no technical sense - it is only useful if you want to hide this particular violation of the GPL. This would be far worse than the current situation, leading to an attitude of "You can violate the GPL as long as you get lots of people to use your stuff". "

I do agree that a solution like this can lead to a bad attitude and that's the main reason I have my doubts about it. But I don't agree with your wording. I think that the current situation gives exactly the attitude you expressed, while a change in the GPL would lead to a somewhat better situation.

Hmm..., posted 16 Jun 2000 at 13:47 UTC by hp » (Master)

This could easily be clarified in a future revision of the GPL by adding a statement along the lines of "In regards to the GPL, we classify Qt, a product of TrollTech AS in Norway, as a 'Virtual Operating System' which should be treated throughout this license as any other Operating System".

Clearly you haven't had much experience with RMS. ;-)

eh? , posted 16 Jun 2000 at 14:40 UTC by listen » (Journeyer)

Distribution of KDE in binary form is a breach of copyright. You are not dsitributing it under the terms of the GPL. You have been granted no other license. That is, whoopdedoo, illegal!

And as to the fact that no one has chosen to sue: No one who has had their copyright violated has chosen to.

I hope that no one has plans to make a KEmacs. There are some people who will force this issue, and file suit.

The FSF is not going to mess with the GPL to make KDE or you happy. Sorry. KDE is ignoring the issue, most of the linux distros are ignoring it too, so the FSF should back down, and modify the GPL? Wuh?

changing gpl ..., posted 16 Jun 2000 at 14:54 UTC by jamesh » (Master)

First of all, do you see any special exceptions for particular products in the GPL? What makes you think the FSF is likely to start adding them now? What happens when the next company with a nice librarary that is almost free enough to be GPL but not quite comes along? These sort of changes add complexity to the licence without much benefit. As the GPL has not been tested in court, if problems are found in it, what is perceived as its intent could be quite important. Adding things like this don't really help. Would you feel comfortable licencing your own code under a licence that got weaker with each version in order to keep a subset of developers happy?

It seems like it would be far easier for people developing GPL'd Qt/KDE apps to include a one line exception making it legal to distribute binaries of their work. You state that because of the large body of KDE code, for which not all authors can be contacted, is licenced under the GPL that we should change the GPL. I don't believe this is the whole truth. If it were, the KDE developers would make sure all new code they produced had the exception in their licence (this licence problem was brought up a long time ago -- there must be a lot of new code written since then). They don't seem to do this, which makes me feel that they don't want to fix the problem.

To me, having a KDE developer ignore my licence is almost as bad as a proprietary software developer ignoring my licence (note that I would consider giving an exception if asked and I had the authority to do so).

A non-solution, posted 16 Jun 2000 at 14:54 UTC by yakk » (Master)

As you know, GNU Emacs is also an Operating System (some would argue its a way of life, but lets stick to the facts). Its a GPLed operating system, just like Linux, and like Linux, its not illegal to run proprietary code on top of it. As such I'm going to begin distributing a version of GNU Emacs linked against my proprietary IDE. I'm sure RMS won't mind, after all, all I'm doing is classifying GNU Emacs as an OS for the purposes of licensing.

What is an OS is a slippery question..., posted 16 Jun 2000 at 17:25 UTC by rbrady » (Journeyer)

And one that would, in the event of a suit, be determined by the court. You can't unilaterally define something to be an operating system and expect to get away with it - the intent of the author of the licence counts for more than you are crediting it with.

moving target?, posted 16 Jun 2000 at 20:09 UTC by hands » (Master)

How about this idea to remove the moving target problem.

1) KDE declare that from now on, all new apps need to be covered by licenses other than pure GPL (i.e. use GPL+Qt_exception instead, or Artistic or whatever) for them to be accepted into the KDE CVS.

2) KDE also declare that in order to upload patches to the CVS, you must agree that if they're patches to a GPLed program, that you must place your patch under a dual license: The GPL, and the GPL+Qt_exception

If this were done, all future KDE code would be problem free, so we would have a fixed target to whittle down to a point where it might be practicable to seek permissions for license changes, and perhaps do a little re-writing.

Over time, the problem code would gradually be patched, replaced, and superseded out of existence, so it might come to pass that by the time we see KDE3, or maybe KDE4 that the pure GPL code would have been eliminated entirely.

This would all be achieved with no effort, and no requirement for KDE to declare their use of the GPL as flawed (something they seem unwilling, as a group at least, to do).

I don't think this would be a significant burden to them, and it would at least show that they were willing to stop the problem getting any worse, which should generate a little more goodwill from all sides.

Cheers, Phil.

Re: moving target?, posted 17 Jun 2000 at 07:55 UTC by jamesh » (Master)

Note that there is no reason to dual licence code under both GPL and GPL+Qt exception. The exception does not place additional restrictions on the code, so is compatible with plane GPL'd code. So there is no problem using GPL+Qt exception code in a GPL program.

Virtual OS and Precedents, posted 17 Jun 2000 at 12:10 UTC by scottyo » (Apprentice)

Let's see Define MSIE as a virtual OS and Office 2000 as a virtual OS. These products should be placed in Microsoft's Operatings System Division instead of its Applications Division. "Gee Judge, these are Operating Systems."

(Disclaimer: I'm not offering any opinion on the pending Microsoft breakup.)
Microsoft, Internet Explorer, Office 2000 are registered trademarks of Microsoft Corporation.

Relevant editorial on Freshmeat, posted 17 Jun 2000 at 21:51 UTC by raph » (Master)

For those who haven't yet read the editorial by Jeff Covey at Freshmeat, it will probably be very enlightening. The KDE license problem has been an issue for a long time, and it looks like the main reason that it hasn't been resolved yet is that there just isn't anybody in power who has the will to do it.

Joseph Carter wrote that, posted 18 Jun 2000 at 02:45 UTC by schoen » (Master)

Joseph Carter of Debian actually wrote that piece, and Jeff Covey posted it. Joseph has been very actively involved in this issue, and certainly knows just what he's talking about.

The real solution, posted 18 Jun 2000 at 10:05 UTC by Uraeus » (Master)

The real soluttion here would be for the KDE developers to finish the Harmony project and that way have a LGPL'ed library. They are not interested in this, many of the are actually opposed to it in some misplaced loyalty to Troll Tech.

For people not working as part of KDE team there is only two solutions here; a) someone with their GPL'ed code having been assimilated into a KDE project suing. That would probably get the KDE developers moving on this issue.

Or the alternative currently being activly pursued, making GNOME so good that KDE becomes unintersting and something most distro's don't bother bundling.

GPLed code can not be bundled with proprietary libraries., posted 19 Jun 2000 at 21:42 UTC by walken » (Master)

The GPL license allows you to compile some GPLed code and link it with proprietary OS libraries - for example, you can compile emacs for solaris and link it with their proprietary libc.

You are not allowed, however, distribute the GPLed program along with these proprietary libraries. This means that sun are not allowed to include GNU emacs in solaris, and Linux distributions are not allowed to include KDE, wether they consider QT as OS code or not.

How would this be different from Linux modules?, posted 20 Jun 2000 at 15:12 UTC by argent » (Master)

>> This could easily be clarified in a future revision of the GPL by >> adding a statement along the lines of "In regards to the >> GPL, we classify Qt, a product of TrollTech AS in Norway, as >> a 'Virtual Operating System' which should be treated >> throughout this license as any other Operating System".

> Clearly you haven't had much experience with RMS. ;-)

Correct me if I'm wrong, but didn't Linus use a similar schtick to let people distribute binary-only modules (drivers and the like) for Linux? Why wasn't there an outcry over that?

Because they aren't distributed with a distro..., posted 21 Jun 2000 at 22:30 UTC by Svartalf » (Journeyer)

...or they had better NOT be. The GPL allows for distribution, etc.- just not with the GPLed code.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page