> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
That last sentence is key. It is a recommendation to dynamically link OR provide application source code. We don't want to be forced to provide application source code, so according to QT.io, dynamically linking is the way to go.
On top of that, there are GPL-only licensed QT modules that aren't suitable for use by closed source applications. Programs using QT on locked down OSes aka iOS and Android are subject to LGPL version 3's anti Tivo-ization clause. I'll revert to my original claim: Using QT is complex for commerical products.
Specific questions about dynamic linking and derivative works re: LGPLv3 have never been tested in a court of law, in any jurisdiction, so all we have to go on are tea leaves and armchair Internet lawyer-ing. The FSF and GNU are certainly entitled to their own opinion about their own license, but they also have a vested interest in casting as wide a net as possible. There are plenty of dissenting opinions out there,
by actual lawyers. The important point is that GNU/FSF wouldn't be one deciding what's what in a court of law, a judge is. That judge gets to decide if the specific technical differences between static linking vs dynamic linking are even relevant in the first place. They might decide there isn't one!
Since it hasn't been tested in a court of law, different people are going to have different opinions on what's actually right. QT.io gives a specific recommendation on how to use their library, so I'll defer to what they have to say, but everyone's free to make their own decisions.
> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
https://www.qt.io/licensing/open-source-lgpl-obligations#lgp...
That last sentence is key. It is a recommendation to dynamically link OR provide application source code. We don't want to be forced to provide application source code, so according to QT.io, dynamically linking is the way to go.
On top of that, there are GPL-only licensed QT modules that aren't suitable for use by closed source applications. Programs using QT on locked down OSes aka iOS and Android are subject to LGPL version 3's anti Tivo-ization clause. I'll revert to my original claim: Using QT is complex for commerical products.
Specific questions about dynamic linking and derivative works re: LGPLv3 have never been tested in a court of law, in any jurisdiction, so all we have to go on are tea leaves and armchair Internet lawyer-ing. The FSF and GNU are certainly entitled to their own opinion about their own license, but they also have a vested interest in casting as wide a net as possible. There are plenty of dissenting opinions out there, by actual lawyers. The important point is that GNU/FSF wouldn't be one deciding what's what in a court of law, a judge is. That judge gets to decide if the specific technical differences between static linking vs dynamic linking are even relevant in the first place. They might decide there isn't one!
Since it hasn't been tested in a court of law, different people are going to have different opinions on what's actually right. QT.io gives a specific recommendation on how to use their library, so I'll defer to what they have to say, but everyone's free to make their own decisions.