Qt shared with static runtime license question
-
Hi! I want to know, will
Qt
license be violated when I use the sharedQt
with static runtime? Static runtime means only for exampleWin
libs will be embedded into the executable not theQt
libs. Thanks. -
Hi,
You are aware that you'll have to also rebuild Qt to use the static runtime ?
-
Yes, I need to rebuild
Qt
from the source with static runtime. So will theQt
license 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
Qt
shared libs, but it requires 40Windows
libs 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 theQt
licenses if I use sharedQt
compilation 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.
-
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.
-
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.
-
@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.
@jsulm
I think the OP's proposal is a little more complex than that. Read again what @SGaist has posted above.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.DLL
etc. 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?
-
-
@jsulm
I think the OP's proposal is a little more complex than that. Read again what @SGaist has posted above.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.DLL
etc. 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.
@jsulm
The OP does not want static Qt, he states explicitlyI 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.
-
@jsulm
The OP does not want static Qt, he states explicitlyI 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.
@JonB said in Qt shared with static runtime license question:
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 said in Qt shared with static runtime license question:
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 I don't know whether I know this topic better than you :-)
@Cobra91151 I'm not an lawyer, so please don't charge me if you violate any license :-) -
@JonB I don't know whether I know this topic better than you :-)
@Cobra91151 I'm not an lawyer, so please don't charge me if you violate any license :-)Hi! I don't think any
Qt
licenses will be violated, because theseWin
libs as you mentioned early are unrelated toQt
.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 theQt
libs (.dlls). -
I have checked this option but it fails to compile. From the
configure /help
command:-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
Win
components are in those locations:C:\Windows\System32\downlevel C:\Windows\SysWOW64\downlevel
I can create some batch script/or static console app to copy those libs to the project directory and add additional step to
qmake
to execute every time when it needed. So, it will be managed automatically.