A possible solution to the Qt/KDE license dilemma
Posted 16 Jun 2000 at 10:34 UTC by TordJ 
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.
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.
"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.
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.
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.
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.
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 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 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.
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.
>> 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?
...or they had better NOT be. The GPL allows for distribution, etc.-
just not with the GPLed code.
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank