Qt, the GPL, Business and Freedom (OfB) [LWN.net]

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 17:05 UTC (Mon) by thomask (guest, #17985) [Link] (2 responses)

If the GPL has "insured (sic) the freedom of users", I wonder what the premiums are like?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 17:59 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link] (1 responses)

Eternal vigilance.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 21:02 UTC (Mon) by iabervon (subscriber, #722) [Link]

I'm more curious about the reimbursement... I'm not sure how I'd use the accumulated vigilance of other users to cope with the loss of my freedom. Maybe it would allow me to stay awake until I'd fixed the problem.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 17:12 UTC (Mon) by ajross (guest, #4563) [Link] (29 responses)

Is anyone else amused at the irony here? The same community that for years argued that there was no need for 100% free software on the desktop and that (pre-GPL) Qt was "free enough" is now wrapping itself in the GPL flag and decrying the notion that "just anyone" should be allowed to develop commercial software for KDE.

I mean, KDE is great software and all, but it's really time that people admitted that the relationship with Trolltech truly is a problem. The trolls' goals are not always going to be the same as the KDE team, and this is going to cause friction (c.f. the code duplication between the KDE widgets and Qt, the late integration of Xft support because Trolltech needed to control the API to handle their framebuffer/embedded work, the current problem that non-GPL KDE development requires a commercial license of Qt, the upcoming friction involved in the inevitable move to Cairo rendering etc...).

The Gnome folks don't have their problems, because they (mostly) develop in lockstep with both the Gtk and (often) X.org codebases. KDE gets stuck eating whatever pops out of Trolltech, even if it doesn't quite fit in with the direction the rest of the OSS world is moving in (e.g. the font issues above, or the new "Qt paint engine" in Qt 4 which seems to largely duplicate Cairo work).

KDE is more than large enough these days to support its own toolkit development. Maybe it's time to reconsider the Qt clone projects that pop up from time to time?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 18:18 UTC (Mon) by halla (subscriber, #14185) [Link] (28 responses)

Is anyone else amused at irony here? For years, the argument against KDE
was that Qt wasn't free enough; now the only argument left for Gnome is
that GTK stimulates the development of non-free applications.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 19:03 UTC (Mon) by ajross (guest, #4563) [Link] (27 responses)

That's just a fanboy response. There never really was an "argument against KDE" like you posit. The folks who truly cared stopped arguing and started their own desktop project with the license that they preferred. You only ever heard the flamewars on USENET and web forums. Similarly, talking about "the only (only?) argument left for Gnome" is equally dumb. Both desktops are going to be here for the forseeable future; there is too much good stuff written for each of them (if you're only using one subset, you're missing out) to make abandonment an option anymore.

My point, though, was that Qt licensing has consistently been a problem (albeit, usually, a minor one) for KDE. In the early days, it prevented the desktop from being distributed as free software. Since the advent of the QPL/GPL version, it prevents using the free KDE to develop commercial software. Both of these are limitations that, I suspect, most KDE users and developers would prefer not to have.

Add to that the technical difficulties (again, usually minor) caused by Trolltech's divergent goals for Qt (remember that the bulk of Trolltech's revenue, as I understand it, is from their Qt/Embedded product and their Win32 tookit -- the core purpose of the Qt library is really not to be the tookit for the KDE project) and I start to wonder if maybe the best long-term goal for KDE might be to move away from Qt. They certainly have the development bandwidth.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 19:53 UTC (Mon) by aleXXX (subscriber, #2742) [Link] (15 responses)

Hi,

you are right in that the Qt license has always been an "issue" for KDE.
and the KDE developers are aware of this.
I'm working on KDE because Qt rocks. So as long as the Qt license is
acceptable to me I'll stay with Qt.
The single reason to create Gnome was the Qt license at this time, so
there was the argument that Qt was not free enough.

In one point you are wrong: the Qt license doesn't prevent commercial
development for the KDE desktop. The licensing costs for Qt are not
exactly cheap, but if you are serious, they are less than one month
salary of a developer. If your business plan can't afford this, you have
a problem.

Add to that the fact that Trolltech is actively helping the KDE project
(Aaron Seigo,, David Faure, Simon Hausmann and others) and at least I get
the impression that the trolls take KDE *very* serious.

Bye
Alex

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 20:54 UTC (Mon) by ajross (guest, #4563) [Link] (14 responses)

To be fair, I tried to be precise: one can develop commercial KDE software, but not with KDE as it is shipped by linux distributions. You need to obtain a separate license from a separate company (Trolltech), which is "odd" from a business perspective. Yes, it is affordable to anyone with a non-trivial revenue stream from their product. And yes, the Trolls certainly have the right to sell a commercial product. Nonetheless, this is definitely a complication for anyone (especially an IT manager unfamiliar with linux) intending to do non-GPL KDE development. And it's one that the Gnome libraries don't share.

But the technical/design collisions are actually more troubling to me. Here is the next one: X.org and Qt have picked divergent paths for their vector graphics APIs. Take a look at their websites:

http://cairographics.org/introduction
http://doc.trolltech.com/4.0/qt4-arthur.html

My quick reading (not being an expert on either) tells me that these have maybe 80% duplicated feature sets -- Qt lacks Cairo's postscript-like arbitrary paths for stroking/filling, but has more working backends for proprietary platforms like win32. But they're completely source-code incompatible. This is a problem. It means that useful software (e.g. an SVG interpeter or charting engine) will work with one or the other, never both. And all linux distributions will need to include both. And KDE (which has not moved to Qt 4 yet) will be forced to pick an API. And we'll need to sit through more flamewars about which is better.

As far as I can see, Qt's new paint engine exists only because of scheduling/marketing issues. The Trolls could have wrapped Cairo in a Qt-like C++ API, but they chose to write their own instead so that they could get Qt 4.0 out the door on their schedule. That's empatically not a "bad" thing. But it is a problem for KDE, which now seems to be firewalled off from X.org development with Cairo.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 21:56 UTC (Mon) by aseigo (guest, #18394) [Link] (13 responses)

> It means that useful software (e.g. an SVG interpeter or charting
> engine)will work with one or the other, never both.

besides being an oversimplification, why does this matter? if someone
writes an SVG engine using Cairo, link to Cairo and you're done. they
write it using Arthur, link to Arthur and you're done. and the way Arthur
is written, a Cairo back end could certainly emerge once Cairo is mature
and interest is there.

> which now seems to be firewalled off from X.org development with Cairo.

cairo is not the only, or most useful, thing happening around X.org these
days. you may be interested to know that Trolltech is actually sponsoring
a TON of X.org development these days, from render acceleration to actual
X.org drivers.

you're making mountains out molehills and making the community out to be
far more divided than it is.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 22:23 UTC (Mon) by ajross (guest, #4563) [Link] (12 responses)

> you're making mountains out molehills and making the community out to be far more divided than it is.

Well, I'm obviously outranked here so I won't argue further. Nonetheless, I'd feel a lot better if your response had been something more along the lines of "Yes, we know Arthur and Cairo codebases represent duplication of a (rather complicated) feature set, we think this is a bad thing, and we're working on a way to merge the APIs". Your response sounds to me more like "Who cares about toolkit-independent rendering APIs anyway? Look at all the other X.org stuff we support."

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 23:13 UTC (Mon) by aseigo (guest, #18394) [Link] (11 responses)

well, if Cairo did meet the needs, it would be used. but there's the issue
of systems that do not have Cairo now and probably never well that need to
be addressed. Arthur is not a way to draw to X, it's a way to draw.
period. much like how Qt's file i/o classes are not a way to work with
files on UNIX, they are a way to work with files.

as i noted, at some point there may well be an Arthur backend that targets
Cairo. i don't see this being a barrier to working together or code dupe.
looking at the current trend of these things, e.g. poplar for pdf,
kdom/ksvg/khtml/kjs for webcore, gecko for moz, etc... the shared code
happens below the rendering layers anyways.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 23:57 UTC (Mon) by ajross (guest, #4563) [Link] (10 responses)

> well, if Cairo did meet the needs, it would be used. but there's the issue of systems that do not have Cairo now and probably never well that need to be addressed. Arthur is not a way to draw to X, it's a way to draw. period.

I'd strongly suggest you take another look at Cairo, because that's not really correct. Cairo (just like Arthur) was designed from the beginning to have a pluggable backend architecture. They claim to have backends currently (in various stages of development) for memory buffers, OpenGL, PNG, Postscript, XLib, MacOS/Quartz, and Win32. What other platforms are required to "meet the needs" of the Trolltech crew?

I suspect your answer will not be features but timing -- the Qt 4 release needs to be out now, not on Cairo's schedule. Which is really my point: the trolls' marketing requirements (which have almost nothing to do with KDE -- just check the Qt 4.0 release page, it doesn't even contain the string "KDE" once). have cause what, to my eyes, is a regretful fork in the vector graphics APIs available on the free software desktop.

To someone who uses and develops only on KDE, that's perhaps doesn't seem as big a problem as it does to those of us who use other toolkits and desktops on occasion. The KDE/Gnome fork should be *closing* as time goes on, and they should be sharing *more* of the underlying technology. But the opposite seems to be happening, and it strikes me that the biggest force driving this wedge is Trolltech's Qt licensing.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 7:42 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

As someone who uses KDE, and has done for years, it looks to be 6 of one and half-a-dozen of the other. Sure, KDE isn't necessarily going to use Cairo, since Arthur fills the same need; on the other hand, both KDE and GNOME are going to use Poppler.

However, DCOP massively predates DBUS, and I have yet to hear a justification for the differences between DBUS and DCOP that doesn't boil down to "we wanted something not KDE for an IPC mechanism". It wouldn't have been terribly hard for the GNOME devs who wrote DBUS to have used the same "on-the-wire" data format as DCOP, thus making bridging DCOP to DBUS, or replacing DCOP with DBUS simpler.

Further, at the point GNOME was started, there were projects like Harmony, which were aiming to completely reimplement Qt in a fully free fashion; the GNOME devs chose to go their own way, rather than work on KDE. In any case, why should KDE and GNOME share stuff, unless both sides feel it's worthwhile? They're different, compatible desktops, not two different skins for the same thing. Poppler is worth sharing, since the people working on Evince and KPDF agree that it's worth having; maybe a vector backend isn't worth the work of sharing?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 16:56 UTC (Tue) by bronson (subscriber, #4806) [Link] (8 responses)

That's easy. http://www.google.com/search?hl=en&q=dbus+vs.+dcop The idea was not "we wanted something besides KDE." It was "we wanted something that would work well without KDE, Gnome, ANY desktop environmnet, or even X11." Since DCOP is so tightly coupled to X11 IPC, it required a ground-up rewrite anyway.

As far as GTK+ vs. Qt (this is still being discussed??), the Gnome guys had to select a different API because there was serious concern about using Qt's interfaces. What good is Harmony or any clone toolkit if Trolltech still owns the API? He who owns the API owns the system (or at least exclusively steers its development). In addition, API-related lawsuits were a pretty common thing back then.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 17:45 UTC (Tue) by farnz (subscriber, #17727) [Link] (7 responses)

So, let's get this straight: GNOME chooses to do something differently to a released, stable KDE technology, and there's sound reasons to do so (so GNOME is OK). KDE does something differently to an (at time of original development) unstable GNOME technology, and this is an example of refusal to think about cross desktop cooperation?

Personally, I think the fuss over cross desktop cooperation is overblown; if it's worth having, someone will do the work needed. If it's not worth having, why fuss about it? The pointing fingers, "you're not being helpful" approach just makes it clear to me (as a KDE user) that I don't want to go near GNOME due to the politics (and I already have KDE apps that cover everything I do). No doubt it has a similar effect on GNOME users (who decide not to touch KDE because of the politics).

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 18:20 UTC (Tue) by ajross (guest, #4563) [Link] (4 responses)

And as expected, we're now in full-on flame mode. Just to clear up some of the inevitable misstatements:

KDE, as of yet, has implemented neither Arthur nor Cairo, as it is still based on Qt 3.x and therefore Xlib. Qt 4, the first release to include the Arthur technology, just shipped. Gtk+ 2.8, the first release to include a Cairo rendering backend, is suppoed to ship "RSN" (the most recent release date target was about a week ago).

To my reading, this would put Arthur and Cairo at roughly the same level of maturity and stability, plus or minus a week or two. It's not at all clear to me that the trolls (not KDE -- AFAIK the decision to develop Arthur was not made by the KDE team at all) made their decision based on stability. It seems more likely that it was based on a perceived feature need in the Qt toolkit and release schedule.

So the decision (to fork from the X.org rendering API) seems to have been made on the basis of Trolltech's marketing needs, and not KDE's goals. Add this to the fact that Cairo is a somewhat more capable API (Qt4 lacks arbitrary path-based stroking and filling) and the Trolltech decision seems to me to be counter to the interestes of the KDE project.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 18:31 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

Cairo is not the X.org rendering API. That's RENDER (see X.org. Cairo is one API built on top of RENDER, and Arthur is another. Why is it so bad that there's two competing APIs?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 19:37 UTC (Tue) by ajross (guest, #4563) [Link] (2 responses)

> Cairo is not the X.org rendering API. That's RENDER

I really should just stop, but the flames keep getting louder than the facts:

Neither Cairo nor RENDER are "official" in any real sense. The render extension is a comparatively low-level X protocol thing designed to expose the underlying graphics hardware's capabilities in a general (Porter-Duff compositing) way.

Cairo is a vector graphics API in the tradition of Postscript and PDF. It happens to have a RENDER extension backend, just as it has an OpenGL backend, or an Xlib one, etc... My saying it was "the" X.org rendering API was unfortunately imprecise, and I guess I should apologise. Nonetheless it seems clear to me that the original intent of the library was for eventual use as the "standard" drawing API for X windows GUI toolkits, just as DisplayPostscript was standard for NeXTStep, or Quartz for OS/X, etc... Please browse through the papers on cairographics.org -- it's really quite interesting and exciting.

Unfortunately (getting back to my point) the Cairo API looks like it is not going to be available to KDE applications. Instead, Trolltech has decided to implement a similar but somewhat inferior API in Qt4. I think this is a bad thing for KDE. It means, among other things, that a unified theme engine with Gtk (something that many people, including especially linux distributors, want badly) is going to be more difficult because the toolkits don't share the same rendering API.

That's all I'm trying to say: KDE is, obviously, constrained by Trolltech's architectural decisions with their Qt product, and these decisions are not always in (what I perceive to be) the best interests of the Linux desktop. The cairo thing is one example. There were others higher up in the thread. I just think that perhaps the KDE team should be looking at this situation more critically than they are, instead of responding to it as a flame from the "gnome" side.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 21:22 UTC (Tue) by farnz (subscriber, #17727) [Link]

And this is where we disagree; I don't see Cairo as the eventual standard for X Window System GUI toolkits, not least because they've not managed to get TrollTech onboard. Indeed, Cairo isn't even mentioned on the X.org pages, while RENDER is, implying that RENDER is "more" of an official X.org standard. Further, both Cairo and Arthur can render using RENDER, just as both GTK+ and Qt can render via other X11 operations. If we'd been having this debate ten years ago, there's a good chance that we'd have been arguing about the future of the standard toolkit for X applications.

My feeling is that if it were worth KDE's while using Cairo, someone would have gone and done it; as it is, TrollTech have done their own thing, which KDE might adopt from a simplicity perspective (although the devs are more than competent to decide that they prefer Cairo and thus go and use it separately, just as the KDE devs don't rely on plain Qt themes, but have gone and created KDE themes, or indeed the way some applications now use GStreamer for multimedia).

On the API issue, please go and look at the kdelibs module; there's stuff in there that duplicates Qt stuff, but done differently (and probably better from a KDE perspective); Arthur does not imply that KDE will not use Cairo, it just means that Cairo's C++ API has to be enough better than Arthur to be worth the hassle.

To take the flame issue: firstly, there have been some major flamewars on both sides of the fence relating to interoperability; the recent ones that I've seen have all been started by someone claiming that one desktop is worse because it's not adopted a technology the other has (Cairo in this case, but I've seen KIOSlaves, DCOP, DBUS, ATK, Pango, KCacheGrind and others used), then trolling whenever people dare to argue. Secondly, precisely because Qt is not controlled by KDE, the KDE team do look at what happens elsewhere; if Cairo is worth adopting over Arthur (if the API is nicer, for example), it'll be implemented in kdelibs. If it's not, that work won't be done. Thirdly, there is a degree of unification between Qt and GTK themes, although all the work on that has been done from the perspective of allowing GNOME apps to look like KDE side (I'm referring to the GTK-Qt theme engine). OK, so it's by no means perfect, and it does mean that only Qt themes can be used (whereas I'd assume you're after a unified theming system such that a theme is desktop-independent), but there is no equivalent going the other way (allowing Qt to use GTK themes).

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 10, 2005 4:11 UTC (Wed) by bangert (subscriber, #28342) [Link]

> That's all I'm trying to say: KDE is, obviously, constrained by
> Trolltech's architectural decisions with their Qt product, and
> these decisions are not always in (what I perceive to be) the
> best interests of the Linux desktop.

so let me ask you: how can an additional technology be a constraint?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 18:22 UTC (Tue) by bronson (subscriber, #4806) [Link] (1 responses)

Each organization made the best decision it could at the time. Trolltech had sound financial and scheduling reasons to develop their own solution. I suggest ignoring the monday-morning quarterbacks... Despite their noise, they are definitely in the minority.

Personally, I use the best apps from each desktop (Gaim, K3B, etc). What does politics have to do with anything?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 18:53 UTC (Tue) by farnz (subscriber, #17727) [Link]

The politics is the "monday-morning quarterbacks"; I'm already in a pure KDE comfort zone, but when I put my nose over the border to see if GNOME offers me anything, I see all these "KDE's bad!" posts, without any reasonable justification.

Thus, I'm not interested in trying GNOME; I'm happy with KDE, and from that perspective GNOME's cheerleaders are offputting. I'm sure that someone in my position, but on the GNOME side gets a similar view of KDE.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 21:26 UTC (Mon) by ewan (guest, #5533) [Link] (8 responses)

Since the advent of the QPL/GPL version, it prevents using the free KDE to develop commercial software. Both of these are limitations that, I suspect, most KDE users and developers would prefer not to have.

I really don't see why anyone thinks that - if we wanted it to be easy to develop non-free software we'd all be using a BSD system rather than a predominantly GPL one. I want a system that encourages the greatest amount of software freedom; sometimes that means finding a way to live with non-free software as a stopgap measure. If we're going to have to put up with that I'd rather the people responsible contributed to free software with their money if not their code.
The GNOME approach seems to me to bend over backwards to accomodate parasites who want to use the results of other people's work without giving them anything in return, and I honestly can't see why that's helpful.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 21:40 UTC (Mon) by ajross (guest, #4563) [Link] (7 responses)

Right, that was the point of the linked article. The problem is that the sentiment doesn't map well to real world situations. If you're an IT manager thinking of developing an in-house desktop application, KDE is "complicated". The version you get with your linux distribution forces your software to be GPL (eek!). Or you can buy an SDK from a third-party company named "Trolltech" you may never have hard of that doesn't sell KDE or linux. And even then, you don't want to actually use the Qt SDK; you want to link against the Qt on the distribution. You just need the non-GPL license. And then some geek wanders in to tell you that you don't technically have to release the software under the GPL, so having a GPLed internal application may be just fine. At which point you chuck the idea and go back to windows, where at least you know what you're getting with your MSDN license.

In contrast, an LGPL'ed shared library works the way that someone from the commercial world expects. Your software stays "yours", and the platform stays the platform. No confusion.

I'm trying really hard not to turn this into a flame war. There's nothing "wrong" with the Qt license from the perspective of a free software developer. But it is a complication, and therefore a barrier to entry, to developers coming from the commercial world. It seems to me like a lot of the KDE people have their heads in the sand about this, and might productively start thinking about a post-Troll KDE toolkit.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 22:00 UTC (Mon) by aseigo (guest, #18394) [Link]

having worked with Qt in the real world for many years now, the licensing
is rarely an issue outside of tiny shops with no budget. professional
devel shops and medium->large sized corps doing in house devel tend to not
even bat their eyes at these issues, especially when compared to the money
saved when working with Qt as a foundation.

is it a possible deal breaker? yep. is it, in practice, the huge blocker
of an issue some are making it out to be? no.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 8, 2005 23:49 UTC (Mon) by pynm0001 (guest, #18379) [Link] (2 responses)

So in a real-world situation a corporation developing an application is
going to choose a GUI toolkit with no commercial support instead of one
with? You pointed out a similar example yourself: Many companies
willingly buy MSDN licenses when they don't have to. The Platform SDK is
available from Microsoft for free, and they'll even mail you the CD for a
very reasonable fee. And yet, companies spend big bucks on a MSDN
license.

Why is this? Perhaps it's because of the support that such a license
buys the company and its developers. Perhaps they want someone to yell
at when something doesn't work. Perhaps they just feel better knowing
that somewhere in Redmond is a Microserf whose only duty is to make sure
that they are able to easily develop their needed software.

Who is the GTK+-serf that is doing this today? When a bug in GTK+ is
breaking their application, who do they contact? Novell? Red Hat?

The fact is that in the "real world", the PHBs and executives in the
corporations like being able to hold someone accountable. It's called
Covering Your Ass, and it's the basis of the business plans of many
companies that make money from taking shit from executives in a panic,
including the companies behind MySQL, JBoss, and yes, even Qt.

I would like to know what is up with the FUD regarding: 'Your software
stays "yours", and the platform stays the platform.' This sounds very
similar to the GPL-as-a-virus argument that has been parroted and quickly
discredited many times before. Except that in this case you bought the
*QPL*-ed edition. If you have not read the QPL before, it appears to be
similar to the LGPL by my reading, you can read it at
http://www.trolltech.com/licenses/qpl-annotated.html

But to try and head off the flame war: You're right when you say that
companies trying to develop proprietary software using a Free library are
going to have trouble. Trolltech offers them a way out, a way that for
the vast majority of corporations is a net money saver. For users of
Free software such as KDE and Scribus, we get a commercial-quality
library backed by dozens of the smartest developers money can hire. This
is not to mention the developers sponsored by Trolltech to work on non-Qt
software, such as the upcoming Exa hardware acceleration patches for
X.org.

So if a few companies are legally restrained from leeching off of the
hard work of others without either paying the Trolls for their trouble,
or sharing the results of their burden like the rest of us, I'll go ahead
and say that I honestly would not shed a tear.

Regards,
- Michael Pyne

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 0:14 UTC (Tue) by ajross (guest, #4563) [Link] (1 responses)

> So in a real-world situation a corporation developing an application
> is going to choose a GUI toolkit with no commercial support instead
> of one with?

This is a straw man. Commercial customers that buy their linux from distributors like Red Hat or Novell most certainly do get a GUI toolkit with commercial support. And yes, Red Hat and Novell both track bugs in Gtk+ (and Qt, for that matter) for their customers.

The problem (trying to state this very carefully so as not to be misinterpreted again) is that Red Hat and Novell aren't able to offer support for non-GPL'ed KDE application development in the same way that they are able to for Gnome applications. This is not "bad" from a free software perspective. But it is "complicated" for the customers insofar as it differs from the way it works with competing products (Gnome, OS/X, MSDN, Solaris, etc...)

I'll stop now. But *please* re-read my earlier posts, with an eye to the facts that (1) I'm not arguing that developers should be choosing Gnome/Gtk over KDE/Qt and (2) I'm personally very much a fan of the GPL. But that doesn't mean that all things Troll are a good thing for KDE, either. You don't have to be pro-Gnome to think that, perhaps, a less "complicated" relationship with the underlying toolkit might be a good thing for KDE.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 2:06 UTC (Tue) by pynm0001 (guest, #18379) [Link]

> The problem (trying to state this very carefully so as not to be
> misinterpreted again) is that Red Hat and Novell aren't able to
> offer support for non-GPL'ed KDE application development in the
> same way that they are able to for Gnome applications.

Although very true, the point to this is that Trolltech *can*. Sure it's
a different entry that must be entered into Accounts Payable, but I think
we've already established that for most serious businesses, the license
cost is not a large factor. The question in this case then is... who do
you pay for support.

With LGPL'ed software like GTK+, you pay whoever can help you. With
GPL'ed software like Qt and MySQL, you *also* pay whoever can help you.
In these cases there happen to be companies behind the software
development, who have chosen the GPL so that if you use their library
commercially they at least get a piece of the action.

> But it is "complicated" for the customers insofar as it differs
> from the way it works with competing products (Gnome, OS/X,
> MSDN, Solaris, etc...)

But that's what I'm not seeing. How does this differ? With MSDN you pay
Microsoft their fee and do what you want. With Solaris you pay Sun their
fee and do what they want (for a long time you had to pay just for decent
dev tools, same with MS). Likewise with Apple and OS/X. When using Qt
(for *commercial* development!), you pay Trolltech. Simple. Just like
companies have done for years now.

In fact the odd one out in this case is GTK+ based software. There's
certainly corporate support behind it with the likes of Red Hat and
Novell, and all the other companies making good software with it. But
there's not really that *one* company you go to for GTK+ support. Not
that this is a problem per se for users of GTK+, but I don't see how this
complicates commercial development using Qt either.

> I'll stop now. But *please* re-read my earlier posts, with an eye
> to the facts that (1) I'm not arguing that developers should
> be choosing Gnome/Gtk over KDE/Qt and

Noted. Although I hope you understand why it is that a lot of KDE devs
have come to the defense of their chosen toolkit. ;)

> (2) I'm personally very much a fan of the GPL. But that doesn't mean
> that all things Troll are a good thing for KDE, either. You don't
> have to be pro-Gnome to think that, perhaps, a less "complicated"
> relationship with the underlying toolkit might be a good thing
> for KDE.

Well there are certainly things that have been in Qt that KDE has had to
ignore, or to do better. Sometimes it gets recycled back into Qt (I
believe Qt 4 has a lot of improvements inspired by KDE code). And it's
obvious as a general rule that a desktop environment should not live and
die by its toolkit.

Luckily that's not an issue for KDE. It's certainly true that KDE has
*had* a complicated relationship with Qt. That's not true anymore. Qt
is even more Free than Gtk+ is now. Of course, this will inconvenience
some people, just as there are devs out there anxiously awaiting the day
that Trolltech loses their minds and BSD's Qt. ;)

Trolltech can't make everyone happy, and nor should they try. KDE, on
the other hand, needs to look after their best interest. Right now, I
can tell you that there is no viable competition to Qt toolkit-wise for
use with KDE. Since KDE is in the business of making the best Free
Desktop Environment out there, this isn't a bad thing for KDE. The fact
that there is a vibrant commercial development environment around Qt/KDE
is icing on the cake. :)

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 0:25 UTC (Tue) by man_ls (guest, #15091) [Link]

f you're an IT manager thinking of developing an in-house desktop application, KDE is "complicated".

Great, so Qt educates IT managers while GTK lets them stay ignorant. Way to go, TrollTech!

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 0:27 UTC (Tue) by huffd (guest, #10382) [Link]

Ajross, You're trying too hard to be kind. These people will never make the link. The only thing they accept is total capitulation. I received a letter the other day from Eric Lafoon that made any discussion or question on the matter sound like a hate crime.

I'd love to publish the communication in it's entirety but here's a quote bye Eric Lafoon I would put fascist hate-mongers masquerading as open source advocates, like yourself, somewhere behind them. He was referring to Microsoft.

And He asks me why so much hate has been generated?

You can draw your own conclusions as I know many already have.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 4:36 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> you don't technically have to release the software under the GPL, so having a GPLed internal application may be just fine.

Exactly. So where's the problem?

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 8:15 UTC (Tue) by cloose (guest, #5066) [Link]

> it prevents using the free KDE to develop commercial software

It doesn't prevent anything. You can develop closed-source software with KDE. You just have to pay for a Qt license.

It only effects those developers/small companies who want their users to pay for their closed-source software but who don't want to pay for their development tools. So this effects mainly Shareware developers and really small companies that create custom software.

I'm not sure if we really care about those two groups. Especially since at least the first group doesn't stand a chance against free software alternatives anyways.

BTW, your Cairo example is badly choosen. Although it's on freedesktop.org, only GNOME has decided to use it so far. IIRC the KDE developers never said that they will use it and with Qt4 IMHO the chance that it will is rather slim.

Not everything on fdo is automatically a cross-platform standard.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 9, 2005 12:02 UTC (Tue) by halla (subscriber, #14185) [Link]

"That's just a fanboy response." No -- it's the response of someone who
has been using Linux for over ten years, who was there when motif was okay
to develop GPL applications against, and Qt not, who maintains a large
free application, who likes his software and his platform free
and who is sick and tired of the kind of arguments you put forward.
Because, in the end, it's the GPL zealot who started Gnome who's now
hankering after proprietary software, not the people who set out to write
a free desktop and still do that.

Qt, the GPL, Business and Freedom (OfB)

Posted Aug 24, 2005 18:22 UTC (Wed) by pastone (guest, #32047) [Link]

The most important feature of the GPL is the right of anyone to
write software, for themselves, without any requirement for distribution,
with no one caring.

This is fundamentally a right to privacy.

Trolltech removes that right for all Qt based code, including KDE, by the
way they "wrap" the GPL.

This is against the spirit, if not the letter of the GPL.
This is why KDE still has license problems after all these years.
This is why it is still a valid question to ask if KDE is finally ready to
get away from the Qt library because of the Qt license restrictions.

KDE is on a slow death spiral as people migrate to Linux... Paid
programmers cannot safely learn Qt/KDE without risk of litigation to
themselves or their employers, since code written while "learning" could
later, in court, be claimed as some banned commercial activity, because
there was not a paid up Qt license, and they did not start a sourceforge
project for their "hello world/qt" project. Once the investment in
learning is done, it is hard to reinvest later, thus the spiral.

Trolltech's business model is the same as SCO's... you use our stuff at
the risk of litigation...

Qt and thus KDE is not under the same right to privacy as embodied in the
GPL. Pray that GPL v 3.0 removes the right to use the term "GPL" when
someone removes standard GPL rights. If that happens, KDE will be shown
to have no license at all.

Phil