So, I think there are absolutely no limitations to using Qt LGPL in a commercial application. All you get from the commercial license is support.
Note: I'm not a lawyer, don't hang me if you get sued or something. But I do think I'm right about this.
I thought you were required to allow linking to a newer or modified version of a LGPL library? So one limitation is you have to either dynamically link or provide a mechanism to relink.
This linking restriction is not a part of other product-scoped copyleft licenses like the MPL and the EPL.
Google has now killed off Sparrow entirely, but they used to make it available for download so that an end-user could in principle re-link it, to comply with the LGPL.
It would appear that once again the FUD is unjustified, and in reality GNU/SFLC licenses well made
This sentence is missing a "closed source". If you license your application under GPL, you will have none of these problems.
If you link statically, you also have to make your object code available for relinking if needed. But that generally comes down to doing something like "ar q libMyApp.a *.o" and then the user would make the app with "gcc -o MyApp libMyApp.a -lQtWhatever".
If you distribute as some package (like .apk for android), you'd have to make it possible for user to change the library. Simply allowing users to download .apk files would make it work, since they can unzip them, change the library and rezip them back.
So, I wouldn't really call those "limitations". Just pesky things you have to do if making a commercial app with lgpl lib.
Oh, and there is no requirement to link with a newer version of the library, to the best of my knowledge. That's generally impossible since newer versions might (and do) deprecate features that were available in the older versions.