Solved Qmake.conf mkspec licensing
semlanik last edited by A Former User
I want to use opensource Qt in commercial project and shared library. This project based on embedded armv7 platform. I need to create my own mkspec for this platform.The only thing in mkspec will be special qmake.conf.
Do I need to open source of this mkspec or I can just simply create it and build qt using it?
Is it source change in terms of LGPL license?
Thanks for answers.
Hi and welcome to devnet,
For licensing questions, you should contact Digia/The Qt Company directly. Their are the most knowledgeable on that subject concerning Qt.
T3STY last edited by
I have contacted the company (via the "Contact us":http://qt-project.org/contact link on the bottom of the forum) about the LGPL terms and the answer was quite nice, even if who replied wasn't a lawyer. Here is the email I sent and the answer I received, I hope it helps.
The first thing I want to ask you is what am I allowed to do and what am I NOT allowed to do by using the LGPL licensed Qt libraries within a commercial work?
My basic understanding of using an LGPL licensed Qt in a commercial work is that I can use the libraries as long as my work is not itself a derived work of the libraries. That is:
(a) dynamically linking does not constitute a derived work. I may use all the Qt libraries that are available under LGPL license by dynamically linking with the Qt libraries.
(b) I may create and distribute, under a license of my choice, in the form of object code and/or source code (b-1) a library that uses the Qt libraries; (b-2) or an application that uses the Qt libraries; (b-3) or a combination of (b-1) and (b-2); as long as (a) is still valid.
(c) I may NOT create and distribute my work under a different license than LGPL (or other compatible licenses) if my work constitutes a derived work in any way; that is (c-1) by statically linking with the Qt libraries; (c-2) or by using a modified version of the Qt libraries; (c-3) or a combination of (c-1) and (c-2).
So, as long as I dynamically link with the Qt libraries I am free to distribute any work of mine under any license I want, for any purpose, including commercial ones. Obviously, the commercial purpose applies to my work only, and not in any way to the Qt libraries.
Until this point, did I get it right?
The second thing I want to ask you is about the redistribution of the Qt libraries with a commercial work.
Suppose I have my work, that doesn't violate any of the LGPL statements, and I am ready to distribute my application:
am I allowed to include a free copy (by every means of it, including free-of-charge) of the Qt libraries with my application? If not, how should I proceed for making the right Qt libraries available to the users?
First, I'm not a lawyer, so I don't give out legal advice. If you really want proper legal advice, ask a lawyer.
First, the most up to date link to license information is:
From the Qt project perspective, we generally appreciate that developers give something back, for open source it would be code, and for commercial developers it would be the price of the commercial license. We do understand that when starting a small project sometimes commercial projects are done with the LGPL license. But once you have a million dollar business, please remember us.
As far as I can tell, you have understood the LGPL license correctly.
The main change in LGPL v3 is to block so called Tivoization. (check that out if you are considering an embedded project)
As for sharing the Qt libraries, I can't provide a better solution than this thread http://stackoverflow.com/questions/8534964/requirements-when-distributing-a-commercial-application-which-is-dynamically-lin
Hope this helps.
<name removed, not sure if I am allowed to write it publicly>
None of the links I've read did ever mention in the license the makefiles or the build chain used to compile a project. From my point of view, your mkspec file is what allows you to compile your source code, so it should fall under the same terms as your application's source code license terms.
semlanik last edited by
Thanks for the answers, we decided to contact with Digia.