I was under the impression that it was available under the lgpl and only had to open source changes to the actual library that you aren't likely to need to make not your application.
You have to ensure you keep your business code separate from the Qt code. It's extra work that people might not want to deal with when they are more comfortable with other options that don't require special care.
You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
There's certainly a reason people worry about Qt licensing.
I don't mean to be harsh, but everything you wrote here is either wrong or misleading.
> You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
This isn't true [1].
> You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
If I'm distributing a game written with SDLv1 on mobile, I don't have to do anything at all differently than if I distribute the exact same game on desktop. Many, many games did this.
> You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
This is also not at all true [2], in fact they couldn't release Qt under the LGPL if it were. That would be LGPL with a non-commercial-use clause, which would be incompatible.
> There's certainly a reason people worry about Qt licensing.
Yeah and honestly, it's because there's a lot of bad information out there. GPL and LGPL are subject to so much FUD. We as developers have a responsibility to know the facts.
No, you don't. You just need to provide a way to replace or relink Qt libraries. Unless of course you modify Qt itself, but then you only have to publish those modifications. Absolutely nothing requires you to "keep you business code separate from the Qt code".
I am wondering what is the issue with dynamically linking Qt, are developers statically linking with MS c/c++ runtime or GUI libs ? From my experience you must install c++ runtimes on windows or if you use C# you need to ask your user to make sure to have it installed, where with Qt you ship the dlls.
My understanding is that Windows has an odd memory allocation system where each DLL has its own allocator. Qt historically wasn't designed for that; it will allocate and return objects on the heap with the understanding that user code will free them.
They may have solved this since by using a custom allocator on windows for Qt types.
Is this related to statically linking? HOW are alternatives like Electron? can you bundle your Electron app into a big binary file ? From my experience in year back when doing desktop apps there was never a pressure to combine your dependencies into 1 big binary