Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Qt shared with static runtime license question
Hi! I want to know, will
Qtlicense be violated when I use the shared
Qtwith static runtime? Static runtime means only for example
Winlibs will be embedded into the executable not the
You are aware that you'll have to also rebuild Qt to use the static runtime ?
Cobra91151 last edited by Cobra91151
Yes, I need to rebuild
Qtfrom the source with static runtime. So will the
Qtlicense be violated or not in such case? Thanks.
What license are you referring to ? There are three.
I don't know exactly which one, but I will explain what I want to do. I have the application, it's built with
Qtshared libs, but it requires 40
Windowslibs to run (components), so I need to manage that additionally every time and it's not easy task. But I want to have it embedded into the executable, so they will always be there. Will I violate any of the
Qtlicenses if I use shared
Qtcompilation with a static runtime? Thanks.
Building Qt or any other library against the static runtime of Visual Studio doesn't mean the you are going to get a fully static build of your application regarding the Windows API you might be using. Just that you won't have to distribute the VS runtime dlls (with all the implications it will have regarding security updates of the runtime).
In any case, it's not the same as building a static version of Qt if you are thinking about the GPL/LGPL license.
So, I can use it legally. Good. Thank you for the answer.
@Cobra91151 If you want to use static Qt build and you do not have commercial license then you will need to make sure you're not violating GPL! With a static Qt build GPL applies, that means you will need to release your app under GPL (or compatible license) as well if you distribute your app.
JonB last edited by JonB
If I understand right, the OP wishes specifically to just avoid distributing the C/C++/VC/MSVC/Win dynamic runtime libraries, while still distributing the Qt libraries as dynamic. Thus, again if I am correct, he wishes to:
Recompile the Qt sources such that the DLLs produced already have the static C/system runtime libraries embedded in them --- no need for
MSVCRT.DLLetc. at runtime.
Compile his own sources also to use the static system/C libraries rather than dynamic ones.
That's assuming it works this way. I am unsure whether the "embedding" of the static system/C libraries happens separately for the Qt DLLs and his own code as he generates each one, thus producing two separate "copies" within each, or whether it happens only once when his final executable is produced (linked) against the Qt libraries. I also cannot be certain whether there is a problem effectively having two separate copies of the static system/C libraries in the final executable, e.g. are there supposed to be any common, shared variables in the runtime which would now be duplicated and thus not work?
I have never mixed static static & shared libraries in the way the OP suggests. I would ask him whether, given that he is prepared to distribute Qt DLLs with his application, it is really worth going to all this trouble in order to avoid distributing the system/C DLLs at the same time? I do not recognise the figure of "it requires 40 Windows libs to run (components)", that seems very high.
Although the OP may not need to change any Qt source code, in order to achieve this, if I understand right the OP must compile the sources of Qt himself, to cause static C/system library linkage. That means that I, as an end user, cannot simply "download and plug in" the latest dynamic DLLs of Qt, as I please. I am not a Qt expert or company representative, and have no vested in what the OP does one way or the other. But I would wonder whether this does not contravene the LGPL (for the community version) spirit or terms, which I thought intended to ensure that any (compatible) version of the freely-available Qt shared libraries can be used at runtime?
@JonB My comment is for the case he wants to build Qt statically. I don't see how Qt licensing can be violated if he wants to build libs statically which are unrelated to Qt.
JonB last edited by
The OP does not want static Qt, he states explicitly
I use the shared Qt with static runtime? Static runtime means only for example Win libs will be embedded into the executable not the Qt libs.
He does not want to "build libs statically which are unrelated to Qt.". He wants to build shared, dynamic Qt libraries (DLLs), but he wants to change the Qt build process so that it links with static C/system libraries instead of the dynamic ones which Qt's shared DLLs (e.g. as downloadable from the web) are built for. This assumes that you must change the build process (flags) for Qt libraries in order to cause it to use static C/system ones, not just change your own application's link command, which I believe is the case.
He does not want to
OK, my last post was not expressed correctly. Lets do it this way: I don't see how Qt licensing can be violated if he wants to link against static libs which are unrelated to Qt.
I know what he wants to do. My post about static Qt and GPL was simply for the case...
JonB last edited by
Cobra91151 last edited by Cobra91151
Hi! I don't think any
Qtlicenses will be violated, because these
Winlibs as you mentioned early are unrelated to
Here is the screenshot of these libs (as example):
By the way, when building static test application with
Visual Studio 2017, all of them are embedded. So, I want just to distribute the
I have checked this option but it fails to compile. From the
-static-runtime ...... With -static, use static runtime [no] (Windows only)
So, it means it won't work with shared
Qt, only with static. I need to think about another way to deal with those libs.
Now I have a solution how to deal with those libs. All
Wincomponents are in those locations:
I can create some batch script/or static console app to copy those libs to the project directory and add additional step to
qmaketo execute every time when it needed. So, it will be managed automatically.