Thinking on the issue of licensing and KDE, an old hymn came to mind. “As it was in the beginning, is now, And ever shall be…” Yes, the issue of licensing has been a perennial problem for the Free/Open Source desktop and I would suggest its biggest licensing issue remains: the GPL.
As an author of several small GPL licensed bits of code and a long time appreciator of what the GPL has accomplished, this is a strange thing for me to say. I would like to say it is the right license for just about any job. Yet, the cloud of ideology is a dangerous one at certain times, and one of the most dangerous forms in the computer world is getting too attached to one's favorite license. Even the FSF has the LGPL, which it advises is a decent choice for libraries and other code that do not have a distinct advantage over non-Free alternatives. After all, if people can get a non-Free alternative and do whatever they wish with the code they build on top of it, who is going to pick the GPL licensed library?
The issue of alternatives with more lenient development licensing is KDE's greatest hurdle in the present time and one worth considering as the aging, three year old KDE 3 series will soon be eclipsed by KDE 4, which will likely show up in 2006. Look at the major enterprise vendors offering X Window-based desktops: Red Hat, Sun and Novell. None of them, that is right, zero out of three, use KDE for their enterprise desktop GUI. Red Hat has always been a proponent of GNOME, back from the days of the old Qt 1.x licensing controversy, when the argument was that KDE was violating the GPL by linking GPL'ed software with the non-Free Qt. Sun also came on the GNOME boat early, but only recently made GNOME the primary desktop for Solaris, so it is not beyond the imagination that Sun could have gone to KDE (Sun, after all, is not known for its steadfastness to much of anything). That leaves Novell. Novell bought GNOME proponent Ximian, yes, but they also acquired long time KDE supporter SUSE. While it is true that SUSE has remained KDE-oriented, notice that Novell's self-branded Linux Desktop, the enterprise oriented version to SUSE's repositioned SOHO product, uses Ximian XD2 GNOME.
Where did KDE go wrong? Qt. Now, do not get me wrong. I do not know of a single person who will argue that Qt is anything other than an excellent development platform. It is powerful, cross-platform and easy to work with (or so I am told by real developers, and not writers who like to pretend they are developers, such as yours truly). The problem with Qt is not the technology, but the license. Trolltech needs to insure a revenue stream, so when it finally compromised and agreed to make Qt a Free Software library, it released it under the unlikable QPL and then, later, the GPL. The GPL is excellent for application level development, or perhaps even specialized libraries, but it is a very bad choice at the basic GUI library level for anyone other than Trolltech, most especially KDE.
Here's why: let us say I get an itch to write a non-Free software program. Plenty of people do, and most desktop users — even GNU/Linux ones — use one or more of these non-Free tools. I can write my program on Windows for free; I do not need to acquire one iota of development licensing from Microsoft to draw off of the common controls of Windows. If Redmond, Washington was swallowed up into the earth tomorrow, I could go on adding new developers to my project without worrying about paying for the permission to do so. I can write my program for Mac OS X for free; not only will Apple not require me to acquire a development license, they even throw in one of the best development environments ever created for free with every copy of Mac OS X. If Windows and Mac OS X are not my cup of tea, I can also go the GNOME route and write proprietary software to my heart's content for free. KDE finds itself uncomfortably alone as the only major interface contender for a desktop computer for which there is a cost-of-entry to develop commercial software, and a fairly hefty one at that, for a small-time developer: $1,800-$3,000 per developer to get started, and $550-$1,000 for upgrades after the first year.
If one has five developers at a small company, you are looking at up to $15,000 just to get licensed before any development work gets started. That might be a small amount in the long run, but many small shops may find the lure of no cost of entry very attractive.
Moreover, there are no guarantees that it will always be so affordable. KDE is beholden to Trolltech and must totally trust that the company will keep the environment for GNU/Linux developers friendly and accessible. I know plenty of fine folks at Trolltech, and have no reason to suspect they will ever do otherwise, but this is a lot less certain than the case is with GTK+, which is and always will be available for commercial development for free, thanks to its more liberal LGPL license. This aspect of control is the reason why enterprise focused desktops are not using KDE. It is not the existing applications — at one point KDE had a much better application library than GNOME — and it is not the underlying technology; let me repeat: it is the license. There have been debates over the years as to whether Trolltech's direction was always in the best interest of KDE, but so long as KDE is dependent on Trolltech to provide commercial licensing, it is really a useless debate: KDE must tag along.
One of the primary protections in Free Software is missing with Qt: forking. KDE can fork Qt under the GPL, but the forked GPL version would never be able to be used for commercial code. If KDE forked Qt 3 tomorrow, because of a disagreement, what would happen five years down the road when Trolltech no longer offers Qt 3 commercial licenses? Yeah, you guessed it; KDE would hit a dead end in the realm beyond FOSS development.
For these dual reasons of control and cost-of-entry, the KDE Project should consider abandoning Qt for the eventual release of KDE 4. Instead of locking itself into Qt for another major release cycle of two to four years, this is the time to make KDE a project entirely sovereign to itself. Its developers ought to look at the work Apple did in making a Qt wrapper for KHTML when building Safari, and then do the same, either wrapping KDE around another library, such as GTK+, or perhaps simply building a better, Qt compatible, library in the same vein as the old Harmony project that sought to do just that in the KDE 1.x era.
Undoubtedly, this would take a lot of work. It would take time away from more “pragmatic,” “critical” projects for the end users. But today's backburner issue could be tomorrow's speed bump to success. Apple, for example, placed its infrastructure in the background while concentrating on the end user applications and paid dearly for it; had it not been for some amazing maneuvering by Steve Jobs and amazing technology from NeXT, Apple may very well have gone down with Mac OS Classic. While Qt is not an aging technology like Classic was, the point is that the underlying system must have a clear, smooth roadmap for the long-term future. A better example might be IBM's experience in building desktop oriented systems: if giving a lot of power over one's product to a seemingly harmless little corporation seems like a good idea, ask Big Blue about a little company named Microsoft. Ever heard of them?
A smooth roadmap ought to include licensing and other non-technical concerns along with the technology. Unless KDE can get Trolltech to release Qt/X11 under the LGPL, or at least get a guarantee that Qt/Commercial licenses will never go above a certain price and never have any more restrictions in usage than the present EULA has, the roadmap will always have a certain air of uncertainty to long-term enterprise decision makers.
The future infrastructure of a system cannot be created overnight, but in this time of transitions within the desktop market, now is the right time to begin. With the right planning and dedication, perhaps in a few years KDE can move beyond Qt once and for all. To do otherwise will keep the enterprise developers looking at other options and insure that the licensing debate is a debate “without end.”