Slashdot Mirror
Qt Becomes LGPL
Aequo writes "Qt, the highly polished, well documented, modern GUI toolkit owned by Nokia, will be available under the LGPL starting with version 4.5! It was previously only mainly available under the GPL and a commercial license. Selling licenses was an important part of Qt under Trolltech as it was the company's main source of income, but Trolltech is a fruit-fly compared to Nokia, who want to encourage and stimulate the use of Qt Everywhere [PDF]. This is fantastic news for all commercial developers looking to create cross-platform applications without the need to buy a $4950 multi-platform license per developer."
The only complaint I've seen before about Qt is that it's too expensive for proprietary apps, and that's not an issue anymore. I won't be surprised to see a large uptick in Qt usage now, and that's a big plus for cross platform apps, as Qt is quite portable.
Game! - Where the stick is mightier than the sword!
Over the years I have said many times that TrollTech should have lowered their prices considering things like the Apple Developer's kit and MSDN are significantly cheaper for more functionality.
I have been in need of a good GUI toolkit for years. I have used just about all of them but for my own projects I either use the native toolkit of the OS I'm working on or FLTK for cross-platform stuff. Qt is much more functional than FLTK though with all their SQL and other utility classes. This is really cool. I bet Qt is now going to become the defacto GUI toolkit for everything.
I wonder how long until someone makes a Qt version of GNOME (ha, I can't imagine how much work that would take). You could start with making a Qt version of The GIMP.
Since GNOME is currently brainstorming over how to make GNOME 3, I'd say this announcement come right on time.
Let's focus on the applications and not on reinventing the wheel.
The toolkit feud has gone on for far too long. Let's share a common toolkit. GNOME is using more Vala and C#/Mono these days and Vala/C#/Mono on top of Qt would make gnomies very happy I think.
Re-implementing GNOME on top of Qt with the traditional focus on HIG should not be all that hard.
This is an exiting opportunity for GNOME. I wonder if they'll embrace it and make the Linux desktop go forward.
Perhaps now we can finally get enough momentum to end this Gnome\KDE battle and get KDE to win so we can settle on ONE desktop environment so we can get back to writing 40 different window managers.
QT + KDE = 1 Desktop Standard Linux (hell even Windows) folk can get behind.
Gnome + KDE = Goblin Desktop (You can thank me for coming up with that name
Merge the teams, move forward with KDE and lets get Linux on the desktop in earnest.
-=[ Who Is John Galt? ]=-
Excellent news!
And a sensible move - the best way for any technology to become a standard (defacto or otherwise) is for it to be freely available and demonstrably good.
Now this is both we can predict swift adoption of it. Some firms may view Linux as a hobby, but even that is changing - my new job I started last week has two Ubuntu PCs in this very room I am typing from.
Open source desktops fail really hard from a strategic point of view because of the split between GTK and Qt. They store l10n and i18n settings in separate places, they look different, the dialogs have different configurations, etc. It creates a desktop that feels less unified, more like a bunch of random applications than a single system.
Of course, porting GNOME would take so long that people would forget that GNOME even exists. The unfortunate reality is that this split will only be resolved when either GNOME and all of the associated GTK applications die, or KDE and its associated applications die (unfortunately, that would mean a loss of K3B, one of the applications that made open source desktops usable for non-technical users).
Palm trees and 8
I wonder what will happen to PyQt? They have traditionally offered the same licensing as Trolltech, but at a much cheaper rate. I'm curious to know what Qt's change to the LGPL will mean to them.
.there is enough of everything for everyone.
I considered QT when I was looking for a good GUI for an open source project I was considering, but ended up rejecting it on licensing agreements. It has actually gotten better licensing twice since then, and now I would actually choose it.
That project, sadly, never happened because I never found a GUI toolkit I thought would do what I needed. How many other projects were similarly stalled like this?
This is indeed good news.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
With this development, I hope Firefox and Adobe developers will jump on board...fast. I would also like to see the folks at OpenOffice.org on board the QT bandwagon as well. The interfaces I see on Openoffice and Adobe's PDF reader would look better with QT in my opinion.
I have a hunch Nokia is looking at XCode and Apple instead. After all, the main battle for them is in the mobile market, and Apple made a big deal about the iPhone being based on OS X. So this is a bid to win over the talented developers.
QT is available on more platforms, true, and it always has been. Still, XCode was free for anyone with a Mac, and the developer kits for the iPhone only required that you own a Mac and that you registered as a developer.
Qt supports more than just Windows/Linux/Mac OSX... It also supports embedded applications (Qt/Embedded - used for Qtopia, which assumes nothing more than a framebuffer graphics interface), and most recently also Windows CE.
I think Google's decision to go with their own graphics API for Android is looking very much like "not invented here". The Qt API is excellent (I've been using the free version for years), and it's available pretty much everywhere. Now with LGPL licensing, any remaining objection has pretty much disappeared. Qt Jambi (the Java API for Qt) would be perfect for Android.
...no reason for Gnome to exist anymore! ;)
KDE is Qt-based but with a lot of CRAP added on top, just for desktop integration reasons, much like GNOME on top of GTK+. I do not need GNOME to run many GNOME apps; this is not so much the case with KDE (at least with version 3).
I love Qt 4 by itself. It's stylish, looks good on Windows and Mac, very portable and a VERY easy API IMO. (Only thing I do not like very much is C++.)
My problem with desktop environments (which is the problem interoperability is SUPPOSED to solve) is there is barely any. You might be able to IMPORT settings from one desktop email app to another's (say they both use MBOX format). I found that KMail imports Thunderbird MBOX files terribly. Besides, if you have Kaffeine for a media player, how do you import those settings to another? Do we need standards here too (a standard settings file for media players)? (Personally I think it is a bit over the line, but could be very useful). Maybe a whole set of standard preferences files?
Right now I cannot move to KDE 4 or GNOME. I am a little bit stuck on KDE 3 (at least till KDE 4 can do everything correctly) and my life is in Kontact. I love KDE, but the ability to switch at any time with ease would be great.
The Linux kernel has flourished without any real competitors for while now...
No sig for the moment.
No one forces you to use GPL libraries. Though I agree that LGPL is much more appropriate for base libraries. This is probably the main reason I haven't used GPL libraries like Qt and don't use mySQL as a database engine. I understand in the case of mySQL it's different, legally vs. what mySQL AB likes to interpret, but I respect their position, and don't use their product for a lot of things.
I don't have a problem with the GPL, I usually use more liberal licensing like BSD, Creative Commons Attr. or MIT myself, and find GPL incompatible for inclusion. If you use GPL code, your code is GPL, it's that simple... if you don't like it, don't use it. There's LGPL, MPL, BSD, MS-PL and a host of other options. You have no place to bitch about it. I like the GPL for applications, it prevents people from subverting your application without giving back (not so great in web/SaaS models though). I think that SaaS using modified GPL apps does subvert GPL a bit. It's a balancing act, trying to preserve your rights as the original developer, while allowing people to utilize your code.
I happen to kind of like MS's MS-PL license. It's kind of like BSD with a nuclear deterrent clause (anti-patent/anti-lawsuit). I feel it's probably more appropriate in most cases over BSD. Since it would allow you to protect yourself, at least a little, from the patent trolls. Sure it works better for larger companies like MS, but is a kind of cool idea just the same.
Michael J. Ryan - tracker1.info
I personally think it sucks to see that those who are materially acting contrary to those ideals are sharing the benefits of this code.
Out of curiosity, how do you feel about Samba? Or Wine?
I have somewhat different priorities -- I would rather see end-users benefit. Most often, this means I'd rather see something open than closed (I'm looking at you, Flash), but not always.
For example, many games, by their very nature (FPS, for instance), are only secure against cheating through obscurity. It might be possible to make a dual-licensed version of that work, given sufficient "trusted computing" to ensure that only the official binary is used in certain settings. A GPL3'd version wouldn't work at all.
I would like to see the day arise where the closed source commercial software industry dies because it's forced to re-invent more and more wheels that open source software developers do not have to re-invent
That actually has very little to do with open or closed, and everything to do with communication and cooperation.
I've been doing a lot of Rails work lately... Seems just about everything Ruby (especially Rails stuff) is MIT-licensed. The idea is that if an idea is good, and generic enough, you'll release it back to the community rather than try to maintain it yourself -- but when you use that stuff in your own proprietary project, you don't have to worry about licensing.
The net result is, only the stuff which is actually relevant to the site in question are at all subject to re-invention. And even then, not necessarily -- provide an API, and others will just use your service instead of reinventing it.
Nor is an aversion to the GPL strictly a proprietary thing. If you've got a large codebase in an OSI-approved, but GPL-incompatible license, it's a problem, and the GPL is about the least compatible FOSS license out there.
As a simple example: We absolutely do have to reinvent the wheel with ZFS, if it's to ever exist in the Linux kernel, largely because the kernel is GPL'd. And if btrfs ends up being good, and anyone wants to port it to OS X, BSD, or OpenSolaris, they're going to run into the same problem. We do each of those using things like FUSE, not for any technical reason, but to avoid licensing problems.
The only way to avoid reinventing the wheel is to follow sqlite's example, and go public domain -- or to define "proprietary" as "not using the GPL", which is just stupid.
Don't thank God, thank a doctor!
Interesting point.
Nokia DOES presume to tell you what you can do with your LGPL code. Read this quote:
"Can I switch from using Qt under the LGPL to commercial afterwards?
"Users of the LGPL versions of Qt need to comply with the LGPL licensing terms and conditions. Qt's commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt."
Wow! How do they know how you "initially" began development?
It seems as though some lawyer or marketing guy with no technical understanding got involved.
How does this affect the open source cross-platform GUI toolkit WxWidgets?
Replying to myself:
Personally I think the LGPL is not doing what it was intended to do, because when it was written they were thinking only about libc and not libraries that might not be included with the operating system.
Static linking should be allowed. The requirement that should be enforced is that if you modify the code in the LGPL library itself, you have to distribute the modifications. The rules are a bit more complicated so that you are not allowed to modify it to call a pointer that is set to point at a secret implementation, and other tricks.
The LGPL requirement for shared libraries is actually a big hindrance to complex libraries. It pretty much requires the binary api to be frozen. As anybody who has tried to write anything that complicated knows, that is quite impossible.
The other popular solution is to add a "linking exception" to the GPL/LGPL. Something called Classpath has the most popular wording. This pretty much makes the LGPL work like most people expect. One problem with this is that the "linking exception" completely hides all the differences between the GPL and LGPL (ie the result is exactly the same if you add the linking exception to either one). But without the name "LGPL" people don't think they can use the code in closed source. I think it would help a lot if GNU would standardize the wording of the "linking exception" and make it commonly known, so that people who see "GPL+linking exception" would know that it is even more useful than LGPL.
The GPL is a true quid pro quo. It says "I will give you my code if you give me yours."
"Give back your changes to my code", on the other hand, is an unequal bargain. You can't realistically claim that a handful of bug fixes are of equal value to an entire library.
You don't have to like the GPL, but please stop spreading FUD. There is nothing "immoral" about a license that merely requires repayment in kind.