Nokia has announced that starting with version 4.5, Qt will be available under the LGPL 2.1. From the announcement,
The move to LGPL licensing will provide open source and commercial developers with more permissive licensing than GPL and so increase flexibility for developers. In addition, Qt source code repositories will be made publicly available and will encourage contributions from desktop and embedded developer communities. With these changes, developers will be able to actively drive the evolution of the Qt framework.
This exciting change, made with consultation of the
KDE Free Qt Foundation, should encourage KDE and Qt use among commercial and proprietary developers and makes the philosophy of "Qt Everywhere" complete.
Kai Öistämö, Executive Vice President of Devices at Nokia expands,
"By opening Qt’s licensing model and encouraging more contributions, Qt users will have more of a stake in the development of Qt, which will in turn encourage wider adoption."
The change in licensing for Qt is happening under the mantra "Qt
Everywhere" and is a step to remove any and all possible blocking objections
for not using Qt. Nokia explains further,
Qt will be available under the LGPL version 2.1 with the upcoming Qt 4.5 release. Qt will also continue to be licensed under commercial license terms, as well as the GPL, version 3.0.
Nokia will also be opening up the development of Qt. A clear path for the
extension of external contributions is currently being built, including
publicly available source code repositories and access to the same level of
support, independent of the license.
The simple fact behind this is that Nokia is less reliant on the
income from Qt licensing than Trolltech (now Qt Software) was, and this has
given Qt Software more room to approach the market with more permissive
licensing strategies in order to increase adoption of the Qt toolkit.
This is part of the 10x growth target announced at last year's Akademy
to achieve ten times as many developers and ten times as many free software community users.
Or as KDE and Qt developer Thiago Maciera put it "we want KDE to be ten times as big".
While kdelibs has always been available under the LGPL, this marks the first
time that both Qt and kdelibs will both be available under the LGPL.
This will help make the licensing of KDE's libraries more permissive, flexible
and coherent. KDE's licensing is summarised on href="http://techbase.kde.org/index.php?title=Policies/Licensing_Policy">TechBase,
and can be described as "LGPL or equivalent for libraries, GPL otherwise".
Meanwhile, Nokia reiterates their commitment to a commercially viable and,
technology-wise, best-of-breed toolkit. In fact, the performance and
functionality improvements that can be seen in the upcoming Qt 4.5 release are
impressive. Running KDE 4.2 with Qt 4.5 is already being tested by several
engineers inside Qt software, which has resulted in a number of bug fixes in
both KDE and Qt. Independent of the licensing changes, the KDE release team
plans to update the version of Qt in KDE's development tree (qt-copy) shortly
to snapshots of Qt 4.5 which is due to be released in March.
All-in-all today's news means tremendous things for Free and Open Source software. The
possibility of extending the reach of all of our work is exciting in and of
itself, and this announcement could lead to a veritable explosion of Qt and
> support itself by selling services
up until now Qt Software has been selling the right to build hermetically sealed proprietary wares in combination with technical / professional support.
that isn't changing going forward.
what they are doing is trading some of their current market for market segments they haven't been able to tap into _at all_. by growing the overall market at a lower conversion rate they hope to achieve two things: greater adoption of Qt (strategically good for Nokia) and numerically more licenses sold (operationally good for Qt Software division)
> it makes it possible for other companies to offer support
that's been true for years, and in fact many companies do just that.
> These companies will not bear the cost of developping Qt
those companies don't bear that cost now, either.
Why LGPL 2.1, and not 3 ?
First LGPL v2.1 is license compatible with all other copyleft licenses from Free Software Foundation. Please take a look at the license matrix from FSF: http://gplv3.fsf.org/dd3-faq
This ensures there is no license incompatibility when making free software with Qt LGPL v2.1.
Second as a first step we have selected LGPL version 2.1 as this version best fits our purposes and we are most comfortable with at this point in time. We will continue to evaluate the adoption, use and legal interpretation of LGPL version 3 by the community and may use version 3 for future releases.
Any chance getting it to do v2 or later?
Also, especially now that you're not requiring copyright assignment, you need to ensure that Qt can be upgraded to later versions even if some of the contributors don't like the new license (say, LGPL v4). Probably you'll be doing something like the KDE e.V.'s license voucher anyways, but make sure you don't lock yourself into a specific version of a license.
Luckily section 3 in LGPL v2.1 allows re-licensing to future GPL versions (e.g GPL version n=2, n+1; n-> infinity). Not all know this part of the LGPL. Continuing releasing Qt as GPL v3 is for convenience, not leaving a perception that Nokia is revoking that version.
LGPL v2.1 section 3 says:
You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
That's actually new to me and a major coolness.
At first I thought that it would still be insufficient as the "any later version" clause is still required for the LGPL itself, but in fact all the compatibility issues with free software requiring any version of the GPL are solved by this section, and for proprietary applications based on LGPL software, it should not make a lot of difference. Neat.
Now that the argument that KDE-is-based-on-a-commercial-library-and-so-does-not-pass-our-zealot-philosophy is no longer valid, I wonder what the KDE detractors would now say. I'd bet they didn't even expect this happening, another point against KDE wiped off their list, ha!
I can't wait for articles comparing KDE over GNOME based purely on their technical merits and not based on the license of their underlying toolkits.
We should express our thanks by supporting Nokia products!
"Now that the argument that KDE-is-based-on-a-commercial-library-and-so-does-not-pass-our-zealot-philosophy is no longer valid, I wonder what the KDE detractors would now say."
My guess? "KDE is built on a toolkit whose copyright is held by a commercial company that hates OGG and open web standards, rather than the glorious Free Software Foundation."
There's also the standard "KDE is bloated/ cluttered/ buggy/ crashy / looks over functionality (KDE4 onwards)/ everything begins with K/ the only software project in history to have a dodgy x.0.0 release", etc. People who truly hate KDE will always be able to find things to criticise, whether their criticisms are valid or not.
Like Sun develops it accessibility framework, Redhat works on this and that. Not sure what percentage of Gtk developers are paid, but I think its fairly substantial.
This fact won't stop trolls though, you're right. :)
personally, i'm hoping it doesn't devolve into a Qt vs Gtk, KDE vs GNOME argument.
discussion is great, arguing sucks.
i'd rather sit back and be happy about this news for what it is, the rest of the toolkit world out of mind. =)
I believe the point was, this will hopefully end some of the toolkit bickering by removing the argument that Qt is less than free. (Is that like less than fresh?)
It is actually possible to develop closed source software with a LGPL'ed version of Qt 4.5? The LGPL 2.1 states:
5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
I did not look at the Qt sourcecode, but usually templates and macros are defined in header files and if you include a header file which contains e.g. a template definitions which is longer then 10 lines of code, you have to release your code under LGPL as stated above. I think that is why people usually use GPL + runtime exception. What do you think about that?
I forgot this. Here is an example from libstdc++: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01s02.html
The source code is distributed under the GNU General Public License version 2, with the so-called Runtime Exception as follows (or see any header or implementation file):
As a special exception, you may use this file as part of a free software
library without restriction. Specifically, if other files instantiate
templates or use macros or inline functions from this file, or you compile
this file and link it with other files to produce an executable, this
file does not by itself cause the resulting executable to be covered by
the GNU General Public License. This exception does not however
invalidate any other reasons why the executable file might be covered by
the GNU General Public License.
Hopefully that text is self-explanatory. If it isn't, you need to speak to your lawyer, or the Free Software Foundation.
Legal at Nokia has worked really hard on what is meant by suitable shared library mechanism and "work that uses the Library". The recommendation is to do dynamic linking since copyright laws may vary between different countries.
Q: What is a suitable shared library mechanism?
One that uses at runtime a copy of the library already present on the users computer system (rather than copying library functions into the executable)
-- This is dynamic linking!
One that will operate properly with a modified version of the library (if the user installs one as long as the modified version is interface compatible with the version that the original was made with).
Q: Im deploying on a device what does the LGPL mean for me?
When creating a device that will include LGPL and proprietary components, you need to ensure that you comply with the following restrictions in the LGPL:
-- Modifications made to the library itself must be licensed under the
terms of the LGPL
-- A proprietary application that is a work that uses the library needs to be dynamically linked with the library in order to avoid becoming a combined work that results in a licensing incompatibility
-- Users need to be aware that an executable might be a combined work with the library unless a suitable shared library mechanism is used (i.e., one that, at runtime, uses a copy of the library already present on the users computer system (rather than copying library functions into the executable), or one that will operate properly with a modified version of the library (if the user installs one as long as the modified version is interface compatible with the version that the original was made with).
At the end. Since this is complicated and copyright law may vary between different countries, please consult your own legal advisors regarding this issue.
Read the following from Nokia:
** Can I transition my commercial Qt project to LGPL and how?
Customers who have developed applications with Qt will be able to dynamically link their proprietary applications to the LGPL licensed Qt library. Additionally, as customers own the modifications they make to Qt under the commercial license, they may relicense such modifications under the LGPL if they wish.
** Why would I want to buy a commercial license? What is the difference?
The commercial Qt license includes email support, access to upgrades and allows you to develop fully closed source software. The LGPL carries some restrictions regarding the ability for users to relink libraries and other restrictions that may impose architectural requirements that some organizations might not be comfortable with.
Thanks. I think it is clear that Nokia wants to allow proprietary applications to link to the LGPL licensed Qt library. However, to develop such an application you need to include the Qt header files and the LGPL 2.1 states (as far as I understand) that you must release your application under LGPL if you include header files which contain a non-trivial amount of code (functions with more then 10 lines of code etc.). C++ templates are defined in header files, thus you will include header files with functions that contain more then 10 lines of code if you link to Qt. I just pointed that out because someone mentioned that in a German forum and I thought maybe the Nokia people overlooked that (however, seems not very likely to me). If so, it would probably be a good idea to add an exception to the license like libstdc++ does.
Just to make it clear: I am very happy that Nokia released Qt under LGPL. I do not want to critisize Nokia in any way. (I have never used Qt for closed source software, only for open source stuff, so personally I don't care).
No, if a library is LGPL (not GPL), you can use it without opening up your own code. Yes, that means you can include the headers (otherwise you won't be able to use the library, right?)
Only if it's GPL you will have to open up your own code.
"The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there's no way to make that work with C++, where much of the library consists of inline functions and templates, which are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL."
Except that it does work in C++! Take a Qt application binary, that links with libQtCore.so.4.2.0. Now replace libQtCore.so.4.2.0 with libQtCore.so.4.4.3. The app still runs!!! Version 4.4.3 is most certainly a modified version of 4.2.0. Yet the app runs. This is because Trolltech designed Qt to be forwardly binary compatible.
No it wont work. The code for QList is in the Qt Application binary, not in libQtCore. To replace that one needs to recompile the application and thus have the source code. Nokia needs to add the appropriate exceptions to the LGPL, which they may or may not do.
What does your legal department say? Nokia's says it's okay to link with LGPL from non-LGPL application.
Qt will still be available under the GPL with exceptions.
But regardless, the licensor's intentions carry legal weight. Nokia intends for Qt to be dynamically linked to from C++ applications, for its base classes to be subclassed, and it's template containers to be used, without "infection" by the library's license.
Woohoo! Now that is some extremely good news I would never expect! I wish more such pleasant surprises happen :).
Seriously, this remedies the most important problem there was with Qt. Now, with THE best toolkit out there being available for free to people objecting to the GPL - I see GTK fall and fall in popularity in not-so distant future :).
Now the only thing that I find Qt lacks is bindings for the C language. But maybe I'm too greedy ;).
Lets now hope they port all their phone sync software to QT so it can be multiplatform and i could fully sync to Kontact. If that happens then i'll also be buying a Nokia smartphone
the biggest problem with the PC Suite as i understand it is not so much the use of Qt, which it is already doing, but accessing all the platform specific APIs outside of Qt to do what it does. so there's work yet left to be one there. hopefully it will get done, though that's not yet a given.
Thanks for the update. If they do sort it out, it will open up another large sector in their battle with RIM etc and put them in the driving seat for smartphones. I do love my blackberry so i tolerate having to sync etc it via my girlfriends PC but I would defect to Nokia once the PC suite is available.
I sure hope they'll port their stuff to opensync plugins. At least, Nokia should start opening up to opensync. IIRC, Michael Bell (the syncml-plugin-master) said there's noone at nokia answering questions about nokia-phones acting up when syncml-syncing.
Nokia's PC-Suite could simply be a opensync-frontend. And in KDE, it would be kitchensync.
Now how sweet would that be?
This is the best news about Qt of the past ten years!
A software galore based on Qt is coming!
Let's celebrate that!
yes, viva nokia, thanks, what a news to begin 2009 with.
This is awesome news.
I wish it happened 1.5 years ago.
Well done Nokia, this move will win you many friends in developer's community!
Now GNOME and GTK's existence is a big question mark, though :(
"Now GNOME and GTK's existence is a big question mark, though :("
I'm guessing that distros such as Redhat will continue to rally around GNOME (they seem to be almost actively antagonistic towards KDE, even regardless of licensing), so I don't see GNOME/ GTK disappearing any time soon :)
"I'm guessing that distros such as Redhat will continue to rally around GNOME (they seem to be almost actively antagonistic towards KDE, even regardless of licensing)"
Actually, they haven't had the opportunity to act "regardless of licensing" yet.
I read a comment from a SUSE guy once who said that while he liked KDE, he understood why distros like SLED and Red Hat went with Gnome. In an enterprise roll-out, you want everyone to have the same desktop, and you want them to be simple. Instead of offering up the choice of KDE and Gnome, some people just want choices. They want to install Linux and get a default desktop. Personally, I think KDE is better for people moving from Windows, but plenty of people feel that Gnome is simpler and easier to learn.
The Fedora guys seem to really dig KDE 4, so I wouldn't say Red Hat on the whole is antagonistic towards KDE.
I never understood why you would roll out Gnome on a corporate desktop. The slight usability advantage of Gnome over KDE is gone after you've used either desktop for about a week full-time, and after that the optimized workflow you can have in KDE makes a big differencen in terms of productivity. I'd rather have my employees take a week more to get used to something and be more productive afterwards than having the shortest time possible to get used to it. After all, productivity matters - if it didn't we could all continue to use dos 5.0 and WP 5.1 or something...
"I read a comment from a SUSE guy once who said that while he liked KDE, he understood why distros like SLED and Red Hat went with Gnome. In an enterprise roll-out, you want everyone to have the same desktop, and you want them to be simple. Instead of offering up the choice of KDE and Gnome, some people just want choices."
It doesn't explain on what basis you would pick Gnome, and some 'easy to use' benchmark is particularly feeble. On a corporate desktop you need the technology and you need the applicatiins ultimately otherwise there is no hope whatsoever, and it seems as though 'easy to use' has become a standard excuse for not having them. Gnome has proved itself incapable of delivering on that front and the LGPLing of Qt just highlights that even further.
Of course, this won't happen overnight, but even Redhat has become pretty flexible lately.
GTK+, being such an awful toolkit, had its image badly spoiled by Mono.
Their other desperate attempts with "easier" bindings didn't work so well (gtkmm, java-gnome etc.).
I think even die-hard redhat and ubuntu developers will have to have another look at straight pros/cons comparison of both toolkits and we know already what the outcome will be :).
The hype about web applications and cloud computing makes this announcement a little bit less exciting, still very valuable.
I disagree with the mono statement myself. Mono was the one thing that GTK had going for it. With Mono, you at least had a toolkit with a full set of libraries under a nice license (there was some controversy here for a while).
GTK by itself is so limited - how do you write networking code? What is the state of the CORBA stuff? Where are the tutorials on how to write a simple app that integrated with GNOME? At least with Mono, there is direction to the project.
Isn't that practically an oxymoron? :P
>so I don't see GNOME/ GTK disappearing any time soon :)
Which, IMO, is a very good thing. For years KDE and Gnome have been moving closer and closer to being able to create a consistent look and feel (the shared icon spec, qt's gtk widget scheme, gtk-qt) as well as compatibile interfaces (eg, dbus) so using Gnome apps in a KDE environment (or KDE apps in a Gnome environment) is much less intrusive than it once was.
As Gnome and KDE consist of different people with different philosophies, and generally approach things from different directions initial but more and more frequently come up with a common solution thats superior to either of the original implementations (think D-Cop and... cobra?, then DBus replacing both after a time; KHTML/WebKit is looking like a similar example that has an interesting origin).
This (LPGL Qt) is definitely very exciting news for KDE (and Gnome), especially when combined with a combined aKademy/GUADEC... I foresee a very interesting few years coming up!
An antagonist is, put simply, a "bad guy". I think you're thinking of a different word.
Are there any plans for the Flat Forty to return? It makes reading fast-moving discussions far more pleasant, and I've been missing it a greal deal :)
Will all the bindings, like PyQt, be LGPL too?
AKAIK PyQt is commercial. I don't think they'll go LGPL, too.
It was commercial during Qt3 phase (i.e years ago). Currently, it has the dual license. I assume they will follow suit and go LGPL (staying GPL would be a a PR suicide and cause reimplementation).
No, it has always(Nearly, not sure if the the Qt 1 was only GPL) been dual licensed GPL and commercial.
QtJambi is going to be LGPL though.
I can answer for C# and Ruby.
I'm not sure how the Ruby source code in QtRuby that the bindings depend on, can be 'dynamically linked' with a commercial application as per the requirements of the LGPL. Maybe we would have to add a 'Ruby exception' or something to make sure that QtRuby could be used for commercial in house development. The LGPL seems to really only consider compiled languages. But if making QtRuby LGPL will make it more popular, then it seems a good idea to change the license from GPL to LGPL.
C# is compiled into dynamically linked .dlls which seem to be the sort of thing the LGPL license has in mind. I think we will change the Qyoto license to LGPL to make it more competitive with GTK# which is LGPL. We haven't had a discussion on kdebindings on what to do yet, but I would be surprised if we don't end up LGPL'ing Qyoto.
Truly great news! Not the least because we now finally will not hear more from people complaining about the license :D
Why the hell does it use the fascist LGPL, and not the Truly Free BSD? I guess I'm switching to Enlightenment. It's too bad that I am forced to abandon such a great peace of software like KDE/Qt only because it is restricted by a fascist un-free license.
:P ;) xD
Either they open up their licensing scheme to compete against Android and the iPhone or they slowly see their market share erode and phone hardware sales diminish.
With the Palm Pre being a potential, they made this move in hopes they can get a large pool of FOSS devs to keep them competitive. Smart move, but reactive and not pro-active.