QT 4.5 + LGPL - closed-source possibility?

[irrdev]

I don't pretend to be a lawyer, for I'm not. However, I was extremely surprised by Nokia/Trolltech's recent announcement that QT 4.5 would be made available under both a LGPL and a Commercial license - the GPL option is dropped. I understand that a closed-source/proprietary application can be statically link to a LGPL library without infringing the library's license. Several examples of this exist, most notably with the GTK+ LGPL-licensed library. The trick is to properly statically compile/link the library so that none of the library's code is compiled into the executable. I don't believe that QT by default is compiled statically linked, but it wouldn't be that difficult to modify. Am I right in believing, therefore, that properly compiled the QT 4.5 library could be used with a proprietary application without obtaining a Commercial license? Unless Trolltech is planning to use a modified LGPL license which explicitly doesn't allow for static linking, I think that this would be legal. Any insight into this matter?

[nvteighen]

Not a lawyer either... (Kilon, where are you?? :))

Static linking means the whole library's code is embedded into your program. LGPL only allows proprietary usage with dynamic linking (which doesn't include the library); static linking forces you to LGPL or GPL your code... as you know LGPLv3 is just a set of additional permissions over GPLv3. As static linking is a derivative work mode not covered by the LGPLv3 Section 4, you have to go "back" to what GPLv3 says... You have to GPL but you can keep at option any additional permissions, so LGPL in such a case is possible too (Sections 6 and 7).

That's what I understood... at least. LGPL is really complex, that's why I don't use it and just use GPL even for libraries.

[Scartaris]

The trick is to properly statically compile/link the library so that none of the library's code is compiled into the executable.

Static linking = the library is part of the executable.
Dynamic linking = the library is not part of the executable, it is loaded as run time on an as-needed basis. Basically, that means that end-users need to install the required package/library themselves to run your executable.

[Gordon Bennett]

The app can remain closed-source as long as it dynamically links to LGPL libraries - static linking violates LGPL conditions. If you dynamically link, your installer can download and install any LGPL libraries it needs (besides, statically linking takes up more space).

It's not surprising that they decided to make Qt LGPL - for just linking to libraries and high-level functionality, the GPL is too restrictive compared to performing the same GUI functionality on another OS. This is why GTK is more widely used than Qt due to its early LGPL status; due to Nokia/Trollech's decision, now ordinary people can use Qt without having to hire expensive lawyers :)

[nvteighen]

The app can remain closed-source as long as it dynamically links to LGPL libraries - static linking violates LGPL conditions. If you dynamically link, your installer can download and install any LGPL libraries it needs (besides, statically linking takes up more space).

It's not surprising that they decided to make Qt LGPL - for just linking to libraries and high-level functionality, the GPL is too restrictive compared to performing the same GUI functionality on another OS. This is why GTK is more widely used than Qt due to its early LGPL status; due to Nokia/Trollech's decision, now ordinary people can use Qt without having to hire expensive lawyers :)
Well, you know LGPL is something Richard Stallman invented according to a strategy (http://www.gnu.org/licenses/why-not-lgpl.html) and GTK+ (a GNU project) chose LGPL because Qt was at the beginning a restrictively licensed library. So, in order to compete, LGPL was perfect to place GTK+ in the market... I guess GTK+ is that established that it could now switch to GPL without any hassle.

Qt seems to have learned the lesson and try to broaden its target. Let's see what happens; but I don't expect too much change from what we've seen till now.

[winch]

There is no problem with static linking if the user can replace the statically linked LGPL libraries.
One way to do that is to supply the .o files for the program so the user can relink it with a modified library.

Probably doesn't make much sense to do that unless you are using a platform where dynamic linking is difficult or impossible.

[Repgahroll]

So I don't need to buy Qt as long as I link the library dinamically?

Then I release my code binary under closed-source licence and put Qt together under LGPL?

If it's right someone would only buy Qt if he wants to modify the library and release under proprietary closed-source licence.

I'm interested because I want to launch a freeware (closed-source) program, and it's using Qt, I can't open the source because i didn't it alone, and the other guy don't want to open his part of the source.

Thank you.

[Bachstelze]

So I don't need to buy Qt as long as I link the library dinamically?

Then I release my code binary under closed-source licence and put Qt together under LGPL?

If it's right someone would only buy Qt if he wants to modify the library and release under proprietary closed-source licence.

I'm interested because I want to launch a freeware (closed-source) program, and it's uwint Qt, I can't open the source because i didn't it alone, and the other guy don't want to open his part of the source.

Thank you.

Right.

[Repgahroll]

Thank you very much!