Also you can't statically link the GPL version which is just a bit of a pain.
I agree if it allowed static linking and wasn't huge it would be perfect. Even so there aren't any better alternatives, but it sucks you can't make something as small and portable as e.g. putty.exe, or depends.exe.
This way, you can get under 20 megabytes: https://youtu.be/mbs3-XE0HNE?t=1180
Sadly I don't think it's possible to have at the same time "portable" (including to platforms without UIs at all, like DirectFB on linux) and small. Putty and depends.exe aren't portable at all.
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.
> If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application
The only thing that matters from the point of view of the LGPL is that your users are able to update the LGPL parts in your app. This is possible with static linking. Else for instance how would LGPL be possible with languages that don't even have a notion of linking (eg script languages), or which only allow static linking ?
See also : https://stackoverflow.com/a/15322678/1495627
I certainly wouldn't base a business on that risky interpretation, and the one business that I have been in that used the LGPL version of Qt dynamically linked it. It's just less risky (plus you don't need to build it yourself then).