Qt shared with static runtime license question

Cobra91151

Hi! I want to know, will Qt license be violated when 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. Thanks.

SGaist

Hi,

You are aware that you'll have to also rebuild Qt to use the static runtime ?

Cobra91151

@SGaist

Yes, I need to rebuild Qt from the source with static runtime. So will the Qt license be violated or not in such case? Thanks.

SGaist

What license are you referring to ? There are three.

Cobra91151

@SGaist

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 40 Windows 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 the Qt licenses if I use shared Qt compilation with a static runtime? Thanks.

SGaist

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.

Cobra91151

@SGaist

So, I can use it legally. Good. Thank you for the answer.

jsulm

@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

@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

@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

@jsulm
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.

jsulm

@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

@jsulm
Fair enough. For anyone reading this, I imagine @jsulm knows better than I do in this area, and his comments should be respected over mine.

jsulm

@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 :-)

Cobra91151

@jsulm

Hi! I don't think any Qt licenses will be violated, because these Win libs as you mentioned early are unrelated to Qt.

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 Qt libs (.dlls).

Cobra91151

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.

Cobra91151

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.