Is there a list of what I can and cannot do in my code using the Qt framework under the LGPL license and keep my source code closed? For instance, can I subclass Qt classes like QWidget, etc.?
Thanks!
A:
I'm pretty sure you have to pay for the non-LGPL licensed version of Qt in order to keep your source closed.
There's an in-depth discussion of these in this question
Jweede
2009-06-14 15:57:59
If this were GPL, rather than LGPL, this guidance would be correct enough -- but the entire point of the LGPL is that some proprietary uses are possible, while changes to Qt itself still need to be released.
Charles Duffy
2009-06-14 16:00:05
Ah, learn something new every day.
Jweede
2009-06-14 16:01:03
+2
A:
Yes, LGPL (Lesser GPL) basically means if you modify any of the Qt framework code, you are to release those changes to the public. All other uses of the code that belongs to you and uses Qt does not have to have the source code released.
I repeat, any changes to Qt code has to be released back to the public if you distribute your program.
If it was GPL, then all your source code would have to be released to the public when you distribute your program.
DoxaLogos
2009-06-14 15:58:49
I wouldn't think so. It's your widget if you do it in a separate file. If you play around with the actual QWidget code that belongs to Trolltech, you would.
DoxaLogos
2009-06-14 16:01:56
How can I at least ensure I'm dynamically linking everything from the framework? I think if I'm dynamically linking then all is good.
Roger B
2009-06-14 16:04:05
That's a question that depends on your compiler and IDE. You might want to post that as a separate question to SO:-)If you static link, it is murkier. Some people believe you have to at least provide the object files of your code along with the library(Qt), so they can test modifications to Qt and your code. That's not releasing your source code, but still be a pain.
DoxaLogos
2009-06-14 16:20:32
+1
A:
The answers so far are generally correct, but bear in mind the only answer that matters (i.e. is legally binding) is the real license. And if this is important, you should get real legal advice.
Matthew Flaschen
2009-06-14 16:07:50
+4
A:
There is a white paper available from ICS.
Qt under LGPL - what are the implications for you?
And yes you can subclass all the Qt classes under LGPL, our sales representative from Nokia has confirmed it.
We at ICS believe this is fantastic news and we applaud Nokia/Qt Software for taking this bold and perhaps unprecedented step. This will undoubtedly make Qt the de facto standard in cross-platform development.
You may be wondering, "What does this mean for my Qt development?" To answer that, we have written a whitepaper detailing the implications of LGPL for Qt developers. It is available in pdf format, free of charge, from www.ics.com.
TimW
2009-06-14 16:09:16
+1
A:
Simple answer. If you have to recompile Qt for your changes to work then you are creating a modified work. You can extend a class without rewriting the base class so there is no need to modify the LGPL library.
SpliFF
2009-06-14 16:10:02
A:
Just use dynamic linking and don't modify Qt at all.
The specifics of doing this depend on your platform.
abababa22
2009-06-14 16:16:44
+1
A:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
As a general guide, if your user can swap out the version of the LGPL library that you used for another version of their own - you have met the requirements of the LGPL.
Subclassing or deriving from an LGPL object wouldn't be a derived work - reusing code or algorithms from the library in your own code is more likely to be a derived work.
Martin Beckett
2009-06-14 16:16:52