(I know this is replying to a week-old post - I've been on holiday.)
And of course, IANAL - this is just my understanding of the LGPL in
general, and not Qt in particular.
It is perfectly legal to use dynamically linked Qt in commercially
(or how ever you want to license it) distributed application. There are
only such limitations:
1. Your application must be dynamically linked to the Qt components that
came with your downloaded LGPL Qt distribution. No static linking allowed.
That's not quite true (assuming Qt uses the standard LGPL). You can
also make your application available in a linkable object form. The
point is that the user (anyone legally obtaining the application source
or binary) should be able to take the source for the LGPL library (Qt in
this case), modify it if they want, re-compile it, and link it with your
application code. The linking can be static or dynamic.
Of course, having the LGPL code as a dynamic library is by far the most
common solution - but linkable object code for static linking is allowed.
2. You can’t make changes to the Qt source code itself and sell your
application based on the changed version of Qt.
The LGPL does not allow Qt to make that kind of restriction. I suppose
it is possible that Qt are using a modified LGPL with additional
restrictions like this, but I did not see that on their website (though
I only had a very quick look). The whole point of LGPL is that you -
either the developer or the end user - can take the code and change it
as you want. But any changes you make must be made available to anyone
else to whom you give or sell the binary code, so that they too can
modify the LGPL'ed code (and re-compile and re-link it). But you can't
make changes to the Qt stuff and keep these changes secret from your
customers (as you can when using the commercial Qt license).
3. You must inform users of your application that Qt is used in the
application in some licence text or in a readme somewhere within your
distributed application files.
I don't know that you need mention Qt explicitly like this, but you /do/
have to provide the user with the source code for the LGPL code (i.e.,
the Qt library), with any modifications you have made. You can include
the source directly, or a written offer valid for 3 years (etc., etc.).
In practice, at least in the *nix world, you provide the application
without any Qt library and dynamically link to the shared libraries on
the end-user's system. As you are not distributing any LGPL code (using
headers is allowed), you don't have to say much - but of course you
would list the Qt dll/so files needed as part of your system requirements.
4. You must provide a copy of the Qt LGPL licence file together with your
distributed application files.
These things above can't be show stopper problems.
They are not - a lot of systems are made using the LGPL versions of Qt.
The biggest annoyance with Qt is that it tends to create large binaries.
Lesser annoyance is that it uses custom preprocessors that do not
understand too well C++ (particularily templates and preprocessor) and
other tools tend also not to understand Qt crap (underlining it red
and reporting errors).
It is this second point that puts /me/ off using Qt - I can live with
big binaries for my PC software.
Another annoyance is that until relatively recently, the Python bindings
(PyQt) were under the GPL (or a commercial licence), rather than the
LGPL (or Python licence), meaning you couldn't use Python and Qt without
making the whole application as GPL or paying for the commercial
license. Now that Nokia's PySide bindings are complete for Python LGPL
Qt development, I might look again at it for future software.
