As the Qt legal gal I receive numerous questions from companies looking to use Qt, wanting to know which license makes the most sense for them. Obviously licensing can be a complex topic and there are specialists out there who are dedicated to this topic.
To help our existing and potential customers I put together a presentation at Dev Days to give an indication of licensing options for Qt. Given the response at both events, I thought there is need enough to continue communicating about this topic, and to discuss with our community the rights and obligations of each of the licenses we offer.
With the release of Qt 4.5 we introduced the Lesser General Public License (LGPL) as a licensing option. We now have three licenses under which we make Qt available:
- Commercial license
- Lesser General Public License (LGPL) v. 2.1:
- General Public License (GPL) v.3.0
We have uploaded my Dev Days presentation slides to Slideshare (embedded below) – they should provide an overview of the impacts of each license choice and the factors to be considered when deciding. In addition I have prepared a brief summary here so you can see for yourself. We have focused on the commercial license and the LGPL as those are the two that tend to generate questions. We are of course always willing to do more posts on this subject if the community requests it.
Here is a breakdown of our two main license options:
Commercial License
This is a proprietary license developed by Nokia. This is the license that comes when customers purchase Qt.
Facts:
- It is designed to allow licensees to keep all code private, and also includes support and upgrades for a one-year period.
- Because Nokia is the developer of the commercial license agreement, we are also able to modify the license as part of the commercial negotiation process or tailor it to particular customer usage scenarios.
- You have to purchase license seats from us and we license Qt on “a per developer and per platform” basis. Contact our Qt Sales Team (qt-sales@nokia.com) for pricing and product information.
LGPL
The LGPL is a license agreement written (and copyrighted) by the Free Software Foundation. The LGPL is a “copyleft” open source software license but is less restrictive than the GNU GPL.
Facts:
- The LGPL version 2.1 license was created by the Free Software Foundation and is copyrighted by them. This means that the terms cannot be changed or negotiated by us.
- Users can develop proprietary applications that dynamically link to the Qt libraries without having to release their application source code.
- All modifications that are considered “works based on the Library” must be licensed under the LGPL v. 2.1 and need to be shared with downstream recipients in source code format (i.e. contributed back). In the Qt context this means that modifications made to Qt itself must be licensed under the terms of the LGPL.
- If you are shipping an executable, you must include any data and utility programs needed for reproducing the executable (i.e. must provide components needed to recompile with a new version of the library) unless such data and utility programs are normally distributed with the major components of the operating system on which the executable runs
- Copyrights and notices need to be maintained
Because the LGPL is a complex legal document, we always suggest that you have your legal counsel review the license prior to beginning development work to ensure that the LGPL is appropriate for your development project. Please note that once you begin with the LGPL you cannot then convert to a commercial license due to a restriction in our commercial license agreement.
Handy reference chart:
|
Commercial |
LGPL v. 2.1 |
GPL v.3.0 |
|
| License cost | License fee charged | No licensing fee | No licensing fee |
| Must provide source code for changes to Qt | No, modifications can be closed | Source code must be provided | Source code must be provided |
| Can create proprietary applications | Yes – no source code must be disclosed | Yes – if dynamically linking to the Qt library | No, application is subject to the GPL and source must be available |
| Support | Yes, with a valid maintenance agreement | Not included, but available separately for purchase | Not included, but available separately for purchase |
| Charges for device runtimes | Yes | No, distribution is royalty free | No, distribution is royalty free |
Have a look through the slides and post any comments or questions you might have below and we will do our best to answer them. If there is sufficient volume then we will post a few follow up blog posts on this topic.
{ 11 comments }
Maybe the most important decision (and the one that changed many things) is the release of Qt in LGPL.
Now, there is absolutely no reason to not adopt and use Qt by everyone.
Question for clarity:
dynamically linking = QT “shared” mode correct? (as opposed to Qt “static” mode for app delivery)
Not directly related, but as there is no more news about it, I was curious to know if the Qt Ambassador project was still in progress ?
One complicated matter is the usage of Qt under LGPL v2.1 for an embedded device. A certain reading of the license might require end-user to be able to actually re-run their modified Qt library within the device, thus requiring the device to be “open” for modifications (though such modifications could void any guarantee offered by the vendor, of course).
This is related to the famous “TIVOization” issue, which was addressed by FSF with GPLv3; but it is debatable whether LGPL v2.1 already prohibits TIVOization (aka: not allowing modifications to run on the original platform) or not.
We usually suggest our partners to either seek legal advice on this matter or to avoid LGPL on “closed” embedded devices at all (whichever is more economic for them…). The situation is made more delicate by the fact that using Qt on embedded devices is not royalty-free.
I don’t understand why Qt choose a so restricted license like LGPL.
And if LGPL is the best, why not add some exceptions to the LGPL license, to make it even better???
For Linux/GNU, no problem, all the Qt runtime libraries are part of the Linux/GNU distributions repositories, but and Microsoft Windows?
Why Qt don’t have an standart Qt runtime library on their site, so final users can download and install it in their Microsoft Windows systems?
I make an application using Qt and them have to distribute the EXE and all the BIG Qt DDLs, this is overkill.
One solution is to make a Static EXE, but them I will have to put my source code open too…
Come on, why Qt don’t put an exception to its LGPL license to allow Static Linking?
Thanks for this blog which clarifies Nokias position in whether it is allowed to use static linking with code licensed with LGPL. It does however not mention that some of the third party libraries upon which Qt is built (JavaScriptCore used by the QtScript module for instance) only is licensed with LGPL. This means, as I have understood it, that if you intend to use these parts of Qt, you will need to comply with the LGPL license also with a commercial license. Static linking may therefore be safe only when developing open source applications.
There are people that claim that static linking is allowed as long as you provide the user with a way to relink the application with updated versions of the LGPL:ed code, see for instance http://www.gamedev.net/community/forums/topic.asp?topic_id=541047.
How do I get the source for 4.6 and Creator? I would like to build them for Solaris 5.10/SPARC…
Thanks!
Technical nitpick:
Dynamic linking is simply the easiest way to comply with the LGPL, but compiling your code into a static library and allowing it to be relinked to modified library binaries also complies. (Of course, shipping your source so it can be rebuilt and relinked ALSO complies.)
THANKS for post Cristy. Very helpful.
I’d like a clarification about the last two points under LGPL, about shipping an executable and copyrights need to be maintained.
If I create a proprietary program using LGPL that makes no modifications to Qt; is not a ‘work based on the Library’ – am I correct that I can license it with any license I want to use, and in this case there are no copyrights or notices to be maintained, other than my own?
In other words, that last two points apply only to situations where modifications are being made to Qt, right?
Thanks
@Andy Korn
“Why Qt don’t have an standart Qt runtime library on their site, so final users can download and install it in their Microsoft Windows systems?”
That probably has something to do with lack of inter-compiler ABI for C++ libraries (e.g. each compiler lays out virtual tables in its own way, not to mention mangling). You can build (on Windows) Qt libs with at least two compilers, which may itself be incompatible with its own older versions. There would be several “Qt runtime libraries” on Nokia’s site and user would have to guess which one fits your particular application. I think it’s better to have application to bundle libraries together with its exe.
If I’m correct with this assumption, then C++ is really an awful platform for deployment and Qt classes need to be re-built on some stable C api underneath, something like COM does …
Thanks for the comments so far. I have tried to address some of the most prominent points raised.
@tom h: Yes, dynamic linking is referred to as a “shared library mechanism” in the LGPL v. 2.1. The requirements are included in Section 6(b) of the LGPL.
@ Andy Korn: The LGPL v. 2.1 was selected as we believe the LGPL v. 2.1 is the open source license that best meets our goals. Those goals are to promote a rich and vibrant Qt developer ecosystem in which third parties are able to contribute to the Qt code base, while also fostering development and distribution of applications by our users in the commercial environment. While there were several factors driving our decision to select the LGPL, one main factor was that it requires that modifications to the “Library” (i.e. Qt) be shared with downstream recipients and this very much ties in with the our strategic goals. Therefore every Qt user contributes to the continued development of Qt by (i) either by paying a license fee for a commercial license; or (ii) sharing their Qt modifications as required by the LGPL.
I also want to clarify why we haven’t added an exception to the LGPL v. 2.1 to clarify the static linking issue. First and foremost, the LGPL only permits you to add additional permissions, not additional restrictions. In my opinion, offering a legal interpretation of the FSF copyrighted text would not be considered an additional permission. Moreover, even if we believed we could add an additional permission to authorize static linking, this would be extremely problematic and result in specialized license version of LGPL. An important factor in making the decision to use the LGPL was that it was a well known open source license and a specialized version of the LGPL with several additional permissions deters developers in that they have to dedicate time to reviewing these additional permissions. Furthermore, you cannot force downstream distributors of the program to also provide the additional permission when they are redistributing the program.
For Qt, we did add an additional permission to the LGPL to clarify the use of template code. In this case, we did so to acknowledge a technological advancement that came into use after the LGPL was written.
@Stefan Josefsson: You are correct that Qt is shipped with a few libraries that are only licensed under the LGPL. They are: QtScript, QtWebkit, QtHelpModule and Phonon. In these cases, the LGPL license applies as these libraries are derivative works of other LGPL-licensed libraries. Even though these libraries are licensed under the LGPL, it doesn’t mean that our commercial customers can’t use them. It merely means that they will need to dynamically link to these libraries and otherwise comply with the LGPL. Furthermore, please note that although QtScript is a derivative work of Java Script Core (JSC), it is merely used to generate code and does not affect the licensing of the code it generates. The code created by the JSC generator would follow the license of the API it binds.
@Marc: You can get access to Qt 4.6 at: http://qt.nokia.com/whatsnew.
@Adam Higard: There is debate in the legal and open source communities as to whether static linking is permissible under the LGPL version 2.1. The uncertainty is caused by an inconsistency in the LGPL license itself. The LGPL v. 2.1 defines “a work based on the Library” to be anything that would be a derivative work under copyright law. Unfortunately, the LGPL is neutral from a legal jurisdictional point of view – the question of which jurisdiction’s copyright laws should be considered is undefined and open to interpretation depending on numerous factors such as where the application is distributed, created, etc. In many jurisdictions, an application that is statically linked with the LGPL licensed library will be considered a derivative work. Thus, in accordance with the LGPL’s definition of a “work based on the Library”, a statically linked application could be subject to the provisions regarding modification and distribution of the Library included in Sections 1, 2, and 4 of the LGPL. Those who believe that static linking is permissible under the LGPL v. 2.1 primarily refer to Sections 5 and 6(a) of the LGPL to support their argument. Those arguing that static linking is permitted under the LGPL argue that Section 5 specifically acknowledges that the executable that results from the static linking of the application with the library is a derivative work of the Library. However, the language in Section 5 gives some indications that despite the executable being a derivative work, it can be distributed in accordance with Section 6. Unfortunately, it is precisely this acknowledgment that the executable may be a derivative work that creates the inconsistency within the license.
Due to the varying opinions on whether static linking is permissible, it is Nokia’s recommendation that Qt users dynamically link their applications to the LGPL-licensed Qt libraries so as to ensure that the application source code, which a user may want to keep private, does not have to be shared with downstream recipients. Ultimately, however, this decision is one of risk and the individual Qt user should make this decision based on their own specific circumstances. Some of the recent posts have stated a desire to have Nokia’s position on whether static linking is permissible. Because the LGPL v. 2.1 source code obligations can be enforced by any recipient of the application and LGPL-licensed library, Nokia’s position on this issue is not particularly relevant and is merely one opinion among many.
@Robin Lobel: Work is ongoing for the Qt Ambassador Program and more information will be communicated in early 2010.
@Edgar Crowdy: The application you describe above is a “work that uses the Library” under the LGPL and you may license the application under terms of your choosing provided that such license terms permit modification for the customer’s own use and reverse engineering for debugging such modifications. The main point of the LGPL is that user of an application can modify the Qt libraries, relink to the application and run the modified program.
Regarding the copyright notices, you only need to maintain the copyright notices already included in the Qt libraries since you have not modified the libraries. Of course, as you pointed out, you would include your own copyright notice with the application.
Comments on this entry are closed.