Submitted by “The Free Standards Group will unveil Linux Standard Base 3.1, the first LSB version to include explicit Linux desktop application support, April 25 at the Desktop Linux Summit in San Diego. The standard has already been endorsed by Linux leaders Red Hat and Novell, along with other major Linux players such as AMD, Asianux, CA, Dell, HP, IBM, Intel, Mandriva, RealNetworks, Red Flag, and Turbolinux, according to the FSG.”
‘Because LSB 3.1 is a codification of what the major Linux distributors are already doing, Zemlin also noted, this latest version of the standard includes Trolltech’s GPLed Qt C++ libraries. At one time there had been a great deal of resistance to the use of Qt in Linux and KDE. Even now, after the matter was settled in 2000 to everyone’s satisfaction, some people still think that Qt’s licensing terms make it in some way incompatible with Linux. As Zemlin observed, though, “We standardize what the major distributions are shipping and all the major distributions are shipping Qt.”‘
What does this mean for distros like Ubuntu?
‘”LSB-compliance is very important for Ubuntu,” said Mark Shuttleworth, Ubuntu’s main backer, in a statement. “We believe that Linux offers the world freedom of choice, freedom to innovate, and freedom to localize. The Linux Standard Base is a crucial enabler of those freedoms, creating confidence in the standardization of the core platform while still preserving the ability of the platform to evolve and improve.”‘
Interesting. Does Ubuntu normally ship the QT libraries? Did past LSB standards include GNOME libraries?
Does Ubuntu normally ship the QT libraries?
Yes. At least, they’re on the CD, I’m not sure if they’re installed by default. For Kubuntu, they obviously are installed by default.
I don’t think that past LSB standards included Gnome libraries, but they did include the GTK libs which was a sticking point for many people. Just goes to show that you can’t just make up an arbitrary standard and expect people to follow it. Good to see that they came to their senses.
Good to see that they came to their senses.
To accept this statement as truth would somehow imply that they had lost them to begin with. The main sticking point with Qt is still its licensing. I don’t think many people will dispute its technical prowess (myself included). However, if Linux distributions are to succeed long term, they need to be friendlier to commercial software (this includes games and drivers!!!).
Having a toolkit like Qt as a standard will be great for “free software,” but toolkits like Gtk with licensing friendly to businesses of all sizes, are still needed as long as Qt remains GPL only (GPL only in the sense that you have to pay for it if you want *any* other licensing terms — don’t nitpick
). I have no problem with Qt being GPL only, and it being part of the LSB standard, as long as toolkits like Gtk continue to be part of the LSB as well.
Licensing fees for the development of software, using standard platform SDKs, are draconian in my opinion. The two mainstream software platforms that make up 98% of the desktop market both have completely royalty and licensing fee free platform SDKs (Windows and OS X). Linux needs to continue to develop equivalent, standardized SDKs that share these same terms. Not all applications can be expected to be open source.
This is why I believe that KDE will not be embraced by commercial applications long term. I think that long term the GNOME desktop will see more commercial support than KDE, as many one man entrprenuers and small businesses will refuse to pay the “trolltech tax.”
Now before you paint me as a troll, let me be the first to say that I think that Qt makes a great toolkit for free software. I personally have used it to build a project or two, and found the documentation and toolkit itself to be wonderful. I also do not criticize Trolltech for wanting to charge money for their product. The only thing I’m criticizing is the mindset of those who would exclude commercial development from small developers on the Linux platform by closed-minded forceful adoptions of GPL only libraries like Qt.
I can only hope that future desktop integration libraries will allow small application developers to release software that will help the Linux platform thrive, while keeping both the KDE and GNOME “camps” happy.
Edited 2006-04-25 02:23
Licensing fees for the development of software, using standard platform SDKs, are draconian in my opinion. The two mainstream software platforms that make up 98% of the desktop market both have completely royalty and licensing fee free platform SDKs (Windows and OS X). Linux needs to continue to develop equivalent, standardized SDKs that share these same terms. Not all applications can be expected to be open source.
This comes up frequently, but let’s look at the business model. To say that the SDK’s are “free” for Windows and OS X isn’t *exactly* true; there is a fee but it is incorporated into the price the end user pays for their license, and the third-party developer gets a free ride at least as far as that is concerned.
Continued development of a suitable application framework carries a cost. In the case of GTK, this cost is subsidized both by commercial interests (ie. Red Hat, Novell, IBM) and by contributing developers simply collaborating in an OSS model. In the case of Qt, this cost is subsidized by Trolltech from revenues generated on developer licenses.
If a company like Adobe produces software using GTK, the only development costs they face are related to producing the software, and the cost recovery and profit generated from product sales remain in Adobe’s bank account.
If Adobe chooses to use Qt, then in addition to internal development costs, they also pay a fee to Trolltech. Once again Adobe keeps the profit generated from product sales, but Trolltech has also generated revenue to invest back into Qt development.
Under the GTK model, companies like Red Hat and Novell need to see cost recovery for their development investment come from the increased linux desktop support and sales they would hope to see from wider application adoption, and the commercial distros are competing with the Debians/Ubuntus/etc. of the world. So how many licenses with support contracts will Red Hat and Novell (just using them as a couple of prominent examples) have to sell in order to not only re-coup their investment in developing GTK but their other development and support overhead costs? What if Red Hat gains 80% of the commercial desktop market at Novell’s expense, will Novell be able to justify maintaining the same commitment to development? Can Red Hat afford to increase development? Can Ubuntu contribute extra resources to development if their desktop becomes popular in enterprises?
Under the Qt model, Trolltech generates revenue from commercial developers utilizing Qt regardless of the distro chosen for deploying those applications, effectively making Qt self sustaining.
Which model is more effective? Who knows, too many variables involved. Is one model superior to the other? Same answer.
I only bring this up because the “GTK is free” argument comes up a lot. It’s not free. Sombody somewhere has to pay the bill, it’s just not the developer in this case. But if the people paying the bill don’t start seeing return on their investment, will they continue to pay the bill?
Qt offers something commercial companies like and understand, a proven business model that provides continuity. And as has been suggested many times before, the license fee pays for itself in terms of man hours saved by developers (though I’m not a developer myself so can’t state that authoritatively).
GTK offers something the community likes, freedom from royalties or proprietary licenses, and it is vital that there is an alternative to being forced to use GPL or proprietary licenses.
But is it free? I’m not too sure about that, but like I said, time will tell. I’m just glad that there is a choice between the two, developers can choose the one that works best for their requirements, and that I think is the most vital thing.
I can only hope that future desktop integration libraries will allow small application developers to release software that will help the Linux platform thrive, while keeping both the KDE and GNOME “camps” happy.
Absolutely. Third party developers have resisted developing KDE or Gnome specific apps specifically to avoid choosing sides, so here’s hoping Portland really does move things forward for the ISV’s and we users can start to see a little DE integration regardless of our choice, rather than the generic GTK/Qt apps we’re stuck with now.
This comes up frequently, but let’s look at the business model. To say that the SDK’s are “free” for Windows and OS X isn’t *exactly* true; there is a fee but it is incorporated into the price the end user pays for their license, and the third-party developer gets a free ride at least as far as that is concerned.
Hence why I specifically said royalty and license free. I never implied that the library itself had no development cost, etc. Although the point you raise is important…
As far as the rest of the arguments about who “foots” the bill, that wasn’t really what I was addressing. I was just pointing out that it would be silly to standardize on a graphical toolkit that esentially required that all developers pay a “tax” (licensing fee or royalty) to be able to develop effective or integrated applications for that platform. Trolltech’s licensing fees might be easily paid by large copmanies like Adobe, but smaller companies (especially one man shops) might end up spending more than they make in a year on a particular product in licensing fees alone!
Regardless of how the other platforms got their SDKs or how they obtained their resources, Linux and other alternative platforms will need licensing free and royalty free integrated, standardized SDKs for desktop applications before it will reach mainstream success (i.e. 30+% of the market). At least that’s what I believe.
It doesn’t matter which toolkit is used. Because project Portland API will give uniform access to anything else, app written with GTK will have good integration with KDE desktop, with exception of widget “look”.
Good to see that, at last, the LSB includes Qt.
As the article says, the Qt licensing problem was solved six years ago. Qt has been GPLed for six years. Qt is GPL software just like any other piece of GPL software. Besides, the beauty of the GPL is that even if you don’t want to trust Trolltech, you can still safely use Qt, because the GPL is so strict on contributing back that one can’t play nasty with it. Concretely, if Trolltech went mad tomorrow, one could just fork Qt to keep it free. And don’t say that this wouldn’t happen, because the same scenario already happened with other projects (cf. the XOrg fork that followed the XF86 license change)
Keeping Qt outside the LSB was impossible to justify :
– Qt is Free-as-in-Freedom
– Qt is used by many applications, especially KDE, but not only
– Qt is a brilliant piece of software.
Besides, the beauty of the GPL is that even if you don’t want to trust Trolltech, you can still safely use Qt, because the GPL is so strict on contributing back that one can’t play nasty with it. Concretely, if Trolltech went mad tomorrow, one could just fork Qt to keep it free.
Actually, if Trolltech went “mad” tomorrow (ie. closed up shop, refused to further develop Qt, decided to close it off from GPL), then the current version of Qt would automatically revert to a BSD license under the terms of their legal agreement with the KDE foundation, and people could do almost WTF they want with it. Good to know we have options.
Keeping Qt outside the LSB was impossible to justify :
– Qt is Free-as-in-Freedom
– Qt is used by many applications, especially KDE, but not only
– Qt is a brilliant piece of software.
Well, I won’t disagree, but by that criteria there are probably lots of libraries and applications that should be considered.
The biggest driver, from my understanding, was that KDE/Qt had pretty much established itself as a (not “the”, just “a”) de facto standard in the linux community, and the LSB is supposed to represent a baseline of common libraries, packages and standards already in place.
Now that we have both QT and GTK libraries, all we need is for the LSB to include a package type to standardize on. Like RPM.
Now that we have both QT and GTK libraries, all we need is for the LSB to include a package type to standardize on. Like RPM.
RPM is the packaging standard for LSB…
RPM is the packaging standard for LSB…
Which makes Shuttlesworth’s and other’s statements about LSB compliance being very important “funny” at best. Especially since their distributions are based around dpkg.
“Which makes Shuttlesworth’s and other’s statements about LSB compliance being very important “funny” at best. Especially since their distributions are based around dpkg.”
Not at all, considering Debian supports rpm.
There’s a difference between “supporting RPM” and relegating to such a low class citizen that saying it’s “supported” is laughable at best. Until RPM is an integrated part of their system, Debian supporting RPM means little. Can you install RPM based packages and have them depend on debian packages? Can you install debian packages and have them depend on PRM packages?
If all of this has changed since I check last, I apologize profusely. However, saying that Debian supports RPM is like saying that Linux distributions that include dpkg support “debian packages.”
Now that we have both QT and GTK libraries, all we need is for the LSB to include a package type to standardize on. Like RPM.
And once they do that they can also propose that the only standard archive format is tar.gz and outlaw zip, rar, tar.bz2 and so on.
Perhaps you meant to say that “the location and organization of meta information about the package management” should be standardized.
<Bah, ignore this>
Edited 2006-04-25 06:01
a unified GNU/Linux desktop standard doesn’t make sense without it.
I know that all those distroes have big userbases, but somehow I think that while they talk about standards, Ubuntu creates them.
Wether people like it or not, the “standard” desktop is going to be the one mostly used, and IMHO that’s going to be Ubuntu. I’m not their fanboy, but currently they are on the best track when you compare price and usability.
Third party developers have resisted developing KDE or Gnome specific apps specifically to avoid choosing sides
Not only to avoid choosing sides but also to avoid the dependency, i.e. keeping the product more crossplatform.
At least for companies using Qt this is an important factor.
However the main desktop environments are moving to better out-of-process services instead of library implementations, so I find it very likely that third party applications will be better integrated in the future while still not use any desktop frameworks directly.
For desktop integration the choice of toolkit is almost as irrelevant as the choice of programming language.
and considering Ubuntu is into the SMART package manager
.
It still has no chance of taking any decent amount of market share from another company.
Why?
Three reasons.
If you look at the quality of help documentation on any Linux program you’ll find it’s either incredibly out of date, missing whole chucks, or written by programmers who can’t write.
When users go looking on a search engine for help they often find millions of highly technical articles on bug issues and are scared off.
Lastly when they want to configure a feature or option, they’re told that they have to manually edit a text file rather than get an easy option to click upon in a GUI window.
If Linux ppl want ordinary humans to use Linux daily then they need to address these serious short falls.
Oh hum! 🙂