"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."
Also, Chromium's Blink renderer has a lot of LGPLv2 source files that date back to the KDE KHTML days[1] and as you can see by the numerous proprietary applications that use Electron and Chromium Embedded Framework, that this doesn't hinder companies from using LGPL libraries as long as they abide by the license.
However, one thing to note: the OSS version of Qt uses the LGPLv3 license, which has additional restrictions (like the "Anti-Tivoization" clause) which make it incompatible with the iOS AppStore thus forcing you to use the commercial version of Qt in those situations. Not sure about the Mac and Windows 10 app stores, I am curious if anyone knows/has experience with LGPLv3 and those stores?
> which make it incompatible with the iOS AppStore thus forcing you to use the commercial version of Qt in those situations.
Not necessarily. If you're able to distribute versions of your app to iOS users so that they can link it against their own Qt libraries, you'd be in compliance with the LGPL.
I've seen companies that distribute via the App Store, but also provide object files with instructions to link them against user supplied Qt libraries and to get them on iPhones/iPads.
"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."