qtdeclarative 6.7+ with QML and dynamic linking wrt. license implications
-
Hi
Qt 6.7 got the following change included:
commit a021bd427328c495cf9969be820a3cfbd41996c6The change means that builtins are now an actual module. Always linked statically.
In:
src/qml/qqmlbuiltins_p.h
it is specified that the module can be licensed under commercial or GPL or LGPL.I want to be able to link qtdeclarative dynamically, but due to that change, qmake will always include libQt6QmlBuiltins.a when generating the Makefile and hence mean I will use that static library.
Question:
1: What are the implications of using that static library in the application ? As I read https://www.qt.io/licensing/open-source-lgpl-obligations, it means that the source code for that application needs to be public accessible. -
Including the builtins in user projects was certainly not the intended result of this change. What happens if you manually remove the builtins from the Makefile?
-
-
Hi
Qt 6.7 got the following change included:
commit a021bd427328c495cf9969be820a3cfbd41996c6The change means that builtins are now an actual module. Always linked statically.
In:
src/qml/qqmlbuiltins_p.h
it is specified that the module can be licensed under commercial or GPL or LGPL.I want to be able to link qtdeclarative dynamically, but due to that change, qmake will always include libQt6QmlBuiltins.a when generating the Makefile and hence mean I will use that static library.
Question:
1: What are the implications of using that static library in the application ? As I read https://www.qt.io/licensing/open-source-lgpl-obligations, it means that the source code for that application needs to be public accessible.@chbs said in qtdeclarative 6.7+ with QML and dynamic linking wrt. license implications:
What are the implications of using that static library in the application ?
You need to provide the user of your app with a way to link against a different version of the library (under the LGPL). This could be handled by providing your object files and a description how to link the object files against their Qt library. It does not mean that you have to provide your source code (this would only apply under the GPL, but you have the choice between GPL and LGPL).
There hasn't been a legal battle about this (the above is not legal advice and I am not a lawyer). So, Qt tries to be safe by telling you to make your source available under the GPL. Also, they try to scare you into buying a commercial license (then it is perfectly fine to link statically without any additional obligations).
BTW the website also states:
Libraries that must be statically linked, such as the QtMain Library (QaX Server, QaX Container) have been licensed under a BSD-style license.
So, you could check if libQt6QmlBuiltins is licensed under the BSD-style license. This would be the easiest way out.
-
@SimonSchroeder :
First of all: I am for sure also not a lawyer. Just a simple developer.
The file used, src/qml/qqmlbuiltins_p.h, declares multi licenses:
// Copyright (C) 2023 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only
So I am a bit unsure of what the resulting license of the static library is.What I was hoping for, is what @Ulf-Hermann is also doing and changing so the library is not static, since it did not really make sense (in my opinion).
I am puzzled to why noone else have been looking into their generated makefiles and wondered why a static linking was suddenly done. As far as I can tell, it should happen as soon as the application uses QML hence happen for quite alot of people.
I geuss few people actually look in the generated Makefiles..@Ulf-Hermann :
I did test removing the builtins from the Makefile and building my code. Removing the builtins, makes the code compile, and seemingly work (did not do a complete test of all the features in the application). That can of cause be done, but it seems wrong to:
run qmake
manually fixup the generated Makefile
run make