Qt Becomes LGPL 828
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."
time to port gnome! (Score:5, Insightful)
It is a mistake to even think of porting (Score:5, Insightful)
Strategy fail (Score:5, Interesting)
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).
Re: (Score:3, Interesting)
Re:Strategy fail (Score:5, Interesting)
Which is just not possible. Where is the CD burning program in GNOME that beats K3B? Where is the music player that beats Amarok? In the other direction, where is the office suite that beats OpenOffice.org? You cannot avoid mixing GTK and Qt apps on a desktop without hurting yourself.
"Honestly, I have no trouble using mixed apps on the same desktop."
Just three days ago at FUDCon, I saw someone try to use KGPG on their GNOME desktop. He had localized GNOME in Dutch, and when KGPG pops up...everything was in English. The localization settings are stored in different places, which is a problem that goes beyond "installing themes to make it look the same." There is also the failure to have OLE across Qt and GTK, which has so far only been solved by disparate hacks in specific applications, and only works for certain cases. The copy and paste problems being solved was a good thing, but that is only one of many issues that arise from mixing GTK and Qt apps on a single system.
Re:Strategy fail (Score:4, Informative)
Which is just not possible. Where is the CD burning program in GNOME that beats K3B?
Brasero, it's there now. I was honestly a fan of K3B, but version 0.9 of Brasero is great. It looks like it has as many features as K3B, but everything is damn simple and clear.
Where is the music player that beats Amarok?
Unfortunately neither Banshee nor Rhythmbox can beat this one. Hopefully, competition will push them to become better!
Re: (Score:3, Interesting)
AFAIK it's only using GTK to graphically draw the widgets, not to do layout or things like that.
Re:Strategy fail (Score:4, Interesting)
Re:Strategy fail (Score:4, Interesting)
What I'd like to see is a decoupling of basic stuff like dialogs from the toolkit.
the idea is that filechoosers, print dialogs and other stuff like that should be separate applications, that comunicates with the calling app using a standard way, adopted by all.
this way GTK, QT, GNUStep, etc. apps. all would have _AT LEAST_ those items in common. that'll make the user able to use muscular memory to use those elements no matter wich toolkit was used to build the app, something that we don't have right now.
Re: (Score:3, Insightful)
People who are picky enough to care about which text editor and which IRC client can handle the notion of different apps using different structures where integration is important. For example on a Mac I use TextEdit when I want integration and VI when I want features.
Re:How would *you* know? (Score:5, Insightful)
Re:Strategy fail (Score:5, Interesting)
That is the chance and duty of freedesktop.org. Combining the parts that are common and the platforms can agree upon. Defining the standards (like trash, cache, drag+drop, etc.).
It is getting better and better (e.g. I think KDE+GNOME both use DBUS now? ), some services/libs (NetworkManager) are already commonly used.
What I'd really like to see is a common password storage.
Re:Strategy fail (Score:4, Funny)
What I'd really like to see is a common password storage.
It's called a .txt file. In the ~/.secretstuff/ directory.
Let's hope both GNOME and KDE lives on... (Score:4, Insightful)
Seriously there's lots of business that depends on GNOME and/or GTK, and lots of reasons to keep them alive...
Competition among desktop environments is good and having two large desktop environments if probably a good idea... As it drives competition and innovation.
Re: (Score:3, Funny)
There is possibility that major GUI appications will move gradually towards managed code (Java) so QT + GTK would become only sort of low-level windowing library sitting between X and Java apps. Major IDEs (Eclipse, Netbeans) are proof-of-a-concept, except startup times issue, which certainly should be addressed by Sun VM. I would welcome such transision but it will not happen in next 5 years, thats for sure. There are just too many C/C++ apps in Linux to rewrite and some of them (Office, Browser) are reall
Re: (Score:3, Interesting)
Re:time to port gnome! (Score:5, Informative)
Qt Designer is part of the core package, and is excellent.
Re:time to port gnome! (Score:4, Insightful)
Re:time to port gnome! (Score:5, Informative)
There is also now Qt Creator [qtsoftware.com] which show some promise as a cross-platform IDE.
Re:time to port gnome! (Score:4, Insightful)
Gtk is mostly a widget toolkit. You get a lot more with Qt. And I find Qt Designer to be much more thorough than Glade.
Re:time to port gnome! (Score:5, Informative)
Just to clarify for anyone new to Qt...
Qt Designer and Qt Creator are two entirely different things.
Qt Designed is drag-n-drop interactive GUI design tool that lets you design the GUI portion if aplication windows, dialogs, etc without coding. You just drag widgets and layout managers off a menu and drop them into the interface your building. It's an awesome tool. Your interface gets saved as a ".ui" file from which Qt automatically generates the corresponding C++ code as clean C++ classes. To add callback/etc behavior, or to further customize the GUI, you just subclass the generated classes and take it from there. It's done very well so that almost always you can further change the user interface using Qt Designer without affecting the subclasses you've added. Qt Designer has been there since early on and just keeps getting better and more powerful.
Qt also includes a tool "qmake" that makes building Qt apps ridiculously easy - qmake takes a high level ".pro" file that lists the various types of file making up your project (source files, header files, Qt designer .ui files, resource files, etc) and what type of target you're building (application, DLL, etc), and from the .pro file generates a Makefile that you then run using your normal make program (e.g. GNU make, or mingw32-make under MinGW).
Qt Creator is an IDE for development of Qt based applications, and seems to deliver the expected functionality of an IDE. It's pretty much brand new, and I havn't personally used it (nor intend to since I don't find IDEs to help my productivity).
Re:time to port gnome! (Score:5, Interesting)
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.
Re:time to port gnome! (Score:5, Informative)
If I recall, Gnome was created because people didn't feel the Qt/KDE license was "Free" enough.
It wasn't that. It was that the Q public license was incompatible with the GPL. QT was Q public and KDE was GPL. KDE is clearly a derived work of the Q public license. That means as far as Debian legal was concerned redistribution of KDE was a license violation.
TrollTech handled this by licensing QT under the GPL (they actually first went through the QPL but that didn't solve the problem). That fixed the legal problems but it meant that any and KDE app had to be GPLed because the userspace exemption (as per Linux kernel) wasn't there. Now KDElib is LGPL which means with QT being LGPL you don't uneed the exemption.
Re: (Score:3, Interesting)
Thanks for the clarification. I recall reading that years back, but I didn't recall the specifics.
GTK wasn't designed to power a full desktop platform originally. Gnome is at a crossroads where they either completely rewrite GTK, they bandage it while trying to preserve some compatibility, or they consider a move to Qt.
The single largest objection I hear from Gnome devs about Qt isn't that Qt isn't a good toolkit, but rather that they prefer to code in C. Color me ignorant, but aren't there language bind
Re:time to port gnome! (Score:5, Insightful)
Competition is great, however GNU/Linux should not be competing against itself. There is too much fragmentation in Linux-land, 10 apps that all try to do the same thing, but each one does certain aspects better, yet none get it all right. Instead consolidate all that effort to 2 or 3 apps.
Linux gets to compete against Windows and OS X. Are you old enough to remember the Unix-wars? All the big Unix versions were all doing things their own way whilw MS and Apple were working on more consistent offerings. We all know what happened to the major Unix players.
Sadly, Linux desktop seems to be repeating the past. Constantly reinventing the wheel with tons of yet-another-app-X syndrome.
I have been using Linux since early Red Hat days. Then I used Slack, built my own Linux based on LFS for about 2 years. Then on to Gentoo, then to Fedora then finally Ubuntu.
Ubuntu made things a lot better IMO, however it still suffers with a felling of many apps tacked together instead of a more cohesive product. This was the main reason I switched to OS X 2 years ago and have been happy with that choice.
I still find myself missing Linux and would love to see a more unified final product. I don't want to have to be bothered with looking for a Gnome/GTK+ based app for Ubuntu so it works/integrates best.
There have been too many times I where I couldn't find a good Gnome/GTK+ based app but found it with a KDE based app. However, that one app pulls in a lot of KDE based bloat that I don't want/need. So I would try to switch to KDE from Gnome for a while, but found the same issue where I would have to pull in/use a Gnome/GTK+ based app.
Lather, rinse, repeat.
Re:time to port gnome! (Score:4, Interesting)
The Linux kernel has flourished without any real competitors for while now...
Re:time to port gnome! (Score:5, Insightful)
The argument was primarily a licensing one: LGPL versus GPL. Going for GTK+ because it was LGPL wasn't a weak argument.
With both QT and GTK+ being LGPL, the argument will be about toolkit quality, third-party support and language experience (C++ versus C). This is a much more useful comparison, and as a developer well-versed in GTK+ I'm looking forward to using both.
From QT4.5 onwards, the best tool for the job wins. Thanks Nokia!
Re: (Score:3, Interesting)
"Not using C++" is still an argument for GTK.
Re:time to port gnome! (Score:5, Informative)
Presumably your "arguments" don't include the vast developer and language support for Gtk?
Also we're using and compiling Gtk on Windows [fedoraproject.org] just fine. It even has nice native look and feel.
Re: (Score:3, Insightful)
Re:time to port gnome! (Score:5, Informative)
GTK+ is object oriented C. (Yes - object oriented C.) It relies on a ton of crazy libraries to work. It's only cross-platform if you mean "Windows and Linux" and even there "cross-platform" is a giant stretch.
Versus Qt, which is C++, has a much cleaner set of interfaces, and is really "cross-platform" on Windows, Linux, and Mac OS X.
The only reason I ever used GTK+ over Qt was due to licensing concerns. (And not just for closed software, also due to GPL/Apache licensing incompatibilities.)
So, yes, Qt is much better documented and much cleaner than GTK+.
Re:time to port gnome! (Score:5, Interesting)
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.
Re:time to port gnome! (Score:5, Informative)
I am told, though I have not tried it, that it is harder to develop multithreaded programs in GTK than in Qt. This matters a lot more than people like to think; how many times have you seen a UI not getting updated because of some background operation, and then had some uninformed user think that the program was freezing or crashing?
Finally, while both are object oriented, GTK is written entirely in C. Object oriented programming in C is pretty harsh, and the only other option you really have is to use the Python binding, which introduces a whole new set of issues. Qt is a C++ toolkit, which makes for much cleaner code when it comes to object orientedness. They did extend C++ somewhat with MOC, but that just introduces some new keywords that fit in very well with the general structure of C++.
Re:time to port gnome! (Score:5, Informative)
More.. (Score:5, Funny)
Ars Technica report (Score:5, Informative)
Re:Ars Technica report (Score:4, Interesting)
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.
It's official... (Score:5, Funny)
...no reason for Gnome to exist anymore! ;)
Re:It's official... (Score:4, Interesting)
...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.
Let Joy Be Unconfined (Score:5, Funny)
Whilst being very good at code and generally geekery, Trolltech are total rubbish at the support game, leaving paying developers (i.e. me a few years ago) feeling massively shafted when being told "here's the code, fix it yourself". WTF am I paying for If I have to not only find your bugs, but fix them as well?
Now everything is back as it should be - free code and no support, the way God intended.
Hurrah (Score:5, Insightful)
Wierd... (Score:3, Funny)
It's not every day that a cross-platform GUI framework suddenly turns into (becomes) a licence...
Large uptick in Qt usage? (Score:5, Interesting)
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.
Re:Large uptick in Qt usage? (Score:4, Interesting)
The only complaint I've seen before about Qt is that it's too expensive for proprietary apps
Then you've not been listening. Many don't like the noteworthy long start up times of Qt apps compared to say Gtk. Many don't like the need for obtuse tools like SIP. I know for a while they were working to address the long start up times I've not followed where that went. Perhaps it's no longer an issue.
Frankly, the API of Qt make Gtk look like a pile of vomit, but simple fact is, Qt is not the perfect GUI programming environment.
Re:Large uptick in Qt usage? (Score:5, Informative)
Re:Large uptick in Qt usage? (Score:4, Interesting)
GTK, wxWidgets, XForms, V, Motif, MFC, Borland VCL, Visual Basic, Swing, AWT, GNUStep and Qt,
I've used most of those, although NEXTStep rather than GNUStep. I used Qt very heavily in the late 90's and early 2000's, but moved to wxWidgets a few years ago, in part due to Qt's licensing costs, and now never plan to go back.
I've found wx easy to use, well-documented, well-supported across platforms and languages (using wxPython heavily at the moment as well as C++) and generally lighter weight than Qt.
The things wx "lacks" are things that I don't need and don't want anyway, like a nice GUI builder--although arguably BOAConstructor fits the bill for wxPython, and I guess maybe DialogBlocks for C++. I use code generators for all my UI coding, which gives me far more flexible and robust layouts much more rapidly than a GUI builder can.
Comment removed (Score:4, Informative)
Re:Large uptick in Qt usage? (Score:4, Interesting)
Wow, great news (Score:5, Interesting)
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.
Re:Wow, great news (Score:5, Informative)
A lot of people don't know this, but GTK stands for 'The GIMP Toolkit', and Gnome used this toolkit. Not the other way around!
http://en.wikipedia.org/wiki/Gtk [wikipedia.org]
Die Gnome (Score:3, Interesting)
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.
That would be a disaster (Score:5, Insightful)
Re:Die Gnome (Score:5, Insightful)
I really like Gnome better than KDE. You can run QT applications under Gnome just fine. :)
What I wonder is if we could see OpenOffice or Mozilla move to QT for the widgets
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Screwed up kernel... BTW, what distro are you running, and what version of KDE 4.x did you run?
I am running Ubuntu Hardy Heron with nVidia drivers. The problem was the KDE, and I think it was 4.0, went and updated my kernel. This in turn hosed my nVidia drivers for some god aweful reason and brought down my whole desktop.
I used to use OpenSuse before Ubuntu and that was where I really liked KDE the best. It was nice because under OpenSuse you could switch between KDE and Gnome quite effortlessly and this
Re:Yeah but KDE doesn't work. (Score:5, Insightful)
The Ubuntu devs screwed up their KDE 4 packages in a bad way. That isn't KDE's fault.
Furthermore, KDE doesn't depend on video drivers. If the Ubuntu devs made a certain Nvidia driver a dependency, then they screwed up big time. KDE does not change your kernel or video driver in any way.
I'm not calling you a liar or saying you didn't have problems. I'm sure your box got hosed somehow, but it is more likely the problem was with Ubuntu's packaging.
It should also be noted that the QT 4/Nvidia problems have largely been remedies. Qt 4 used Xrender heavily, and Nvidia's driver had a piss-poor Xrender implementation. The forthcoming Qt 4.5 is supposed to move away from using Xrender all over the place, and the latest Nvidia driver has much better Xrender support to boot. openSUSE even provides a repo with weekly snapshots of the KDE 4.2 branch compiled against the weekly snapshots of Qt 4.5. In theory it is unstable, but I've had good luck with it so far.
I know I'll get modded Troll for this, but I don't care. Ubuntu has got some serious problems, and is very overrated. openSUSE puts out quality KDE 3, KDE 4 and Gnome desktops. They support all 3 currently (though KDE 3 is being dropped in the future).
Novell hires a large staff of developers that make quality packages, fix upstream bugs, backport features, etc. As much as I hated Novell for the MS deal, Novell is one of the best contributors to several upstream projects, and openSUSE is a fantastic distro.
I can't recommend it enough.
Re:Vala makes the creating widgets argument moot (Score:4, Insightful)
"I wasn't necessarily saying Vala was an app development language (although it could be)."
GNOME devs are already writing full apps with it, so it is being used as such.
"If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components?"
yes, i understand that is what has driven Vala's design and implementation. i just don't agree with the "we'll wedge another home grown language in between the C and the other languages" approach. i think it's overly complicated and limits the number of people who can (and will) hack on it.
time will tell if i'm smoking crack or not, of course .. =)
"Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code."
that is produces C is both a feature and a bug. it makes debugging much more awkward (and for a while wasn't even possible at all! how do you go from your generated C to your Vala code in gdb? there's a plugin now for gdb, but really .. oy vey!) and you lose all the interesting security possibilities of managed code.
"How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach?"
it's simply a language that is well known. pick a different well known language if you wish. make your own runtime if you wish. certainly add your own sugar on top (see QScript for a really nice example of how that can all be done with JavaScript). there's nothing particularly magical about the Vala syntax, except that it's a new language specific to one toolkit.
which is precisely my point.
"it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding."
let's do this then: let's come back to this in 2-3 years (it takes time to get these things going, i know) and see if that theory works out.
my theory is that it will just be one more baroque tool that people working with Gtk will have to get their head around (and people complained about moc with Qt; they ain't seen nothing yet ;) thereby limiting the pool of candidate developers. as a non-transferable skill it won't gain much in the way of value that might cause people to learn it "just because", and yet people will write applications with it. i expect to see more and more vala usage in Gtk+/GNOME (because, well, that's already happening =) and it will cause the project to become more insular rather than less.
i do expect that those using it will get more done with vala than with plain C, but not to an extent that will make up for the number of people lost by not choosing a language syntax that is already widely known or a language that avoids compile cycles, dealing with the intricacies of C debuging, etc.
given that it's homegrown, it will also soak up resources maintaining and extending vala itself that could be put elsewhere.
combined, i expect individual efficiency of existing contributors to increase due to vala, but the overall effect on the project to be a net negative. i predict that in a few years vala will get quietly binned. bonobo 2.0 if you will: a cool idea that "just has to work, it's so well designed and advanced!" but which just didn't pan out in reality.
again, i could be wrong. and i certainly don't want to see the GNOME team falter. but vala gives me the heebie-jeebies.
Excellent news! (Score:4, Interesting)
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.
Re: (Score:3, Interesting)
Some firms may view Linux as a hobby
I am working on a Qt application right now. Previously, we planned to release only for Windows since each additional platform cost extra in licensing fees. Now, we can support Linux and OS X as well.
Way to go, Nokia! (Score:5, Insightful)
I love to see when a company understands that giving something away they will get ten times more in return. And nowadays that happens too rarely.
For a while it seemed that Nokia is about to lose to its competitors, because of Symbian and bad software. This will totally remedy it. I've also heard from Nokia insiders that they're actively dumping everything related to Symbian. It won't take more than couple of years and all their phones use Qt.
Seeing how well Apple has been selling iPhone applications, I can only imagine the potential Qt phones have in future. With Symbian that just wasn't possible, it was a total nightmare for the developers.
PyQt? (Score:5, Interesting)
Finally! (Score:4, Interesting)
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.
KDE is a perfect cross-platform environment (Score:5, Informative)
One year after Nokia bought Trolltech [kdedevelopers.org], they've released Qt as LGPL. This positions Qt and KDE in an excellent position for cross-platform application development for FOSS *and* commercial projects. KDE libraries were already licensed under LGPL. This means the entire stack is now LGPL.
In the mean-time, Qt Creator, an IDE for developing Qt applications, has been announced. This will be all you need to write cross-platform applications with Qt.
Qt Jambi (java bindings for Qt) will also available under LGPL. Qyoto (mono bindings) and the other bindings (Perl, Python, Ruby) will be able to make releases under LGPL now.
These are exciting times!
Re: (Score:3, Insightful)
Yet when Nokia purchased the Trolls people insisted they would try to close up Qt and fight FOSS. Nokia did oppose open formats in HTML 5 for some crazy reason, but maybe Nokia isn't so evil after all.
Nokia did not purchasee Trolltech for reselling Qt (Score:3, Informative)
Nokia never insisted anything of the sort.
While they may have opposed the HTML 5 standard, their opposition is based upon their relationship with Webkit (recall that Nokia is one of the big players backing Webkit ... in addition to the fact that Qt now bundles a derivative of it).
When Nokia purchased Trolltech, they promised not to change much. That's the opposite of what you just claimed. Those of us heavily entrenched in the Qt world knew that there was likely to be a shift in priorities ... the pro
Re: (Score:3, Interesting)
http://en.wikipedia.org/wiki/HTML_5#Ogg_controversy [wikipedia.org]
I realize that Nokia bought Trolltech for Qtopia. Nokia is now trying to push a mobile GTK platform while owning the Qt platform. I did think it was a really smart move to give Nokia n810 tablets to KDE devs. Then the KDE devs worked on getting KDE 4 to work on the n810. Nokia could easily ship a full KDE 4 based desktop on future smart phones and tablets.
No copyright assignent (Score:3, Insightful)
If they do what this article suggests they will, this is a big step towards better code and community involvement. Go Qt, go!
Jump onboard Firefox and Adobe! (Score:5, Interesting)
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.
Re:Jump onboard Firefox and Adobe! (Score:5, Interesting)
Re: (Score:3, Insightful)
There is a QT port of Firefox but when I tried it it was still in the very early development stages and was unusable.
GTK is not the target... (Score:5, Interesting)
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.
We all know why GNOME is ill (Score:4, Funny)
It caught Mono through an ill-considered tryst with Miguel ;)
Re:It's not great news for everyone (Score:4, Informative)
Re:I'm not a copyright lawyer (Score:5, Informative)
Could someone summarise the difference between the LGPL and the GPL? Thanks.
LGPL allows closed-source programs to link with the library in question.
Re: (Score:3, Informative)
If you have a piece of GPL code in your program, all of the program must be GPL. LGPL only applies to the LGPL code and any changes you make to it (your original code can be under any license)
Re:I'm not a copyright lawyer (Score:4, Informative)
Totally wrong. You didn't read the link.
What the FSF means by "compatible" is that you can include BSD code in GPL projects. However, you CANNOT include GPL code in BSD-licensed projects. My comment stands.
Re: (Score:3, Informative)
I have a Motorola Z6 that contains QT binaries (most likely QT embedded) on it so they are already using it on their linux phones at least.
Re: (Score:3, Insightful)
Re:Hello Moto (Score:5, Funny)
No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it. Which is within their rights, but thoroughly corrupt and domineering of them.
Which makes sense, as Stallman is the ugliest type of human being--the zealot.
cough Kettle, pot, black, what?
Weird license restriction: (Score:5, Interesting)
Nokia DOES presume to tell you what you can do with your LGPL code. Read this quote [qtsoftware.com]:
"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 [wxwidgets.org]?
Re:Hello Moto (Score:4, Insightful)
Re:Hello Moto (Score:4, Insightful)
Under their definitions of "use" and distribute
Their definition - where 'their' is the person licensing the code. Just because they are words which can be used in contexts different from those implied by the licenser, doesn't mean that they are incorrect definitions. In the context of the GPL, they are the correct definitions.
The GPL says that the same terms must also infect any code that links to it. Hence the immoral aspect of it and why I advocate against it.
It's not immoral, because no one is forcing you into that position. You have to willingly submit to the terms in order to be bound by them... i.e. no one is forcing you to distribute code under the GPL, unless you take their GPL'd code and willingly incorporate it into your own.
By your logic, any consensual act you don't like the ramifications of is immoral...
Re:Hello Moto (Score:5, Insightful)
No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it.
Flat out wrong. The GPL restricts what you can do with other peoples code who have chosen to license it under the GPL. If you don't want those restrictions on your code then don't creative derivative works from GPL code.
Don't bitch because you can't leech other peoples code: Your code, your rules means their code, their rules.
Re:Hello Moto (Score:4, Interesting)
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.
Re:Hello Moto (Score:5, Funny)
Which makes sense, as Stallman is the ugliest type of human being--the zealot.
Stallman is a member of a Jewish political movement from the first century AD whose primary goal is to incite the people of Iudaea Province to rebel against the Roman Empire?
Re:Hello Moto (Score:5, Funny)
Stallman is a member of a Jewish political movement from the first century AD whose primary goal is to incite the people of Iudaea Province to rebel against the Roman Empire?
No, he's a ground melee fighter armed with psi-blades, serving as the core of many Protoss forces, especially in the early-to-mid game.
Re:Hello Moto (Score:5, Funny)
You mean... The Judean People's Front?
Re:Hello Moto (Score:5, Interesting)
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.
Re:Hello Moto (Score:4, Insightful)
No, the GPL just presumes to attempt to restrict what I do with my code that has no GPL code in it.
Um, no, that's simply not true. The GPL presumes to tell you what you can do my MY code. You are perfectly free to accept the license terms or not. Your own code is unaffected by anything other than your own decisions and their consequences. You're just not allowed to deny me the right to control what's done with *my* code. If you think you should have that right, you're certainly more corrupt and domineering than RMS.
Re:Hello Moto (Score:5, Insightful)
Re:Hello Moto (Score:5, Insightful)
The definition of derivative work is the issue.
I'd love to be able to utilize GPLed code, provide the code, credit the author(s), and create a work that utilized that functionality, intact, as an accoutrement to the rest of the application.
Unfortunantly, a strict reading of the GPL leads me (and my companies OSS group) to believe that this would mean that my entire application is a derivative work that would fall under the GPL. I've gotten around this in the past by having the GPLed code in a plugin form that is dynamically specified and then dynamically loaded so that the application is significantly distanced from the GPLed code.
Perhaps that's not how the GPL is intended to work, but there's enough leeway in interpreting it, that you have to be really careful.
Re:Hello Moto (Score:5, Insightful)
The problem is that you're criticizing the GPL for not living in your perfect dream world.
I think the GPL is way better, because I know, that in reality, businesses tend to rip you off, fuck you in every hole, and leave you bleeding on the street, (metaphorically speaking) if they just can!
It's the rule of profit maximization. The first rule of every business. And more often than not, it's unfortunately the only rule.
And that's exactly why we need the GPL to enforce giving back something. Because in reality, businesses will not give back anything. Why would they? To lose money and then to lose against their competition who is winning because they are not giving anything back? Makes no sense.
But why would you care about your reality, if you can perfectly continue to rant about your dream world not coming true, while ignoring it?
Re:Hello Moto (Score:4, Insightful)
The whole point of the GPL is to strengthen those who are materially sharing your ideals while diminishing those who are materially acting against them. I personally believe in the ideals behind the GPL, and I personally think it sucks to see that those who are materially acting contrary to those ideals are sharing the benefits of this code.
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 and is unable to remain competitive. That day just got further away.
Re:Hello Moto (Score:4, Interesting)
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.
Re:Hello Moto (Score:4, Insightful)
If you want to release your code under the GPL, great, thank you very much. If you want to release your code under a commercial license, or not release it at all, I also support that decision.
Allowing a GPL option for QT was great for the open source community. However, since QT is a library, the LGPL is a very good choice now that the owner of QT doesn't need the income from selling commercial licenses, and has an interest in having the library used more extensively. It's a good move on Nokia's part.
QT gets all the benefits of the open source community development, but is now also compatible with small closed source development that can't afford an expensive commercial license.
Re:A GUI for MySQL? (Score:4, Funny)
At last! Qt has gone LGPL! The final obstacle to our creating a front-end for MySQL has been removed!
What on earth are you talking about?
Re:It's good news, but is it too late? (Score:5, Informative)
Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView (actually, *no* toolkit out there has anything like this).
You are right that Qt uses very umm... baroque C++, but the fact is that it is a very good toolkit, the best opensource one out there. Using new features don't guarantee a top result, and vice versa.
Re:Kills any idea of using Qt in our products (Score:5, Insightful)
So buy a commercial Qt license. These are still available have no GPL/LGPL in them.
Re: (Score:3, Informative)
Re:congratulations to Nokia (Score:5, Insightful)
I'm assuming we're talking about development for Linux, or cross platform here, since this is QT. Two questions:
1) Why would you program in C# on Linux? Mono support is years behind the feature sets that MS is rolling out. There are a variety of languages/frameworks that are better supported than .NET.
2) What's wrong with GUI programming in C++? QT tools seem pretty nice to me, and objects are much easier to work with than a mountain of procedural code. C++ should also be plenty efficient for application space.
So, what advantages are there in using C/Gnome?