Qt shared with static runtime license question
-
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.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?
-
-
@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.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 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
Qtlicenses will be violated, because theseWinlibs 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 theQtlibs (.dlls). -
I have checked this option but it fails to compile. From the
configure /helpcommand:-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:C:\Windows\System32\downlevel C:\Windows\SysWOW64\downlevelI 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.
