PDA

View Full Version : Clarifying LGPL



Hsilgos
12th June 2010, 00:20
I have: Qt, Windows, MSVS2008
I use qt under LGPL for commercial product and have some question.
1) I want to link all statically. I found next solution: I compile all application and Qt libraries to .lib - static libraries. In my library (let it be myapp.lib) i export only entry point (let it be int MyEntryPoint(int argc, char *argv[]) ). I create header (let it be "myheader.h") for my library and declare my entry point in one. Then i create exe-project and write simple code:
#include "myheader.h"
int main(int argc, char *argv[])
{return EntryPoint(argc, argv);}
and link all statically to one executable file. According to Licence i destribute myapp.lib and myheader.h. Other user can relink application with changed version of Qt. As i understand i keep LGPL.
Can i do this scheme? Can i use 'phonon' in this scheme? Can i use same steps on Mac OS?

And other question. I use 'qtbrowserplugin' add-on in my project. On Windows it's ok, but on Mac OS exists some problems - safari and firefox work incorrectly with this wrapper. Do you plan to update this add-on or it's better for us try to resolve this problem independently?

wysota
12th June 2010, 01:37
As i understand i keep LGPL.
Can i do this scheme?
Short answer: ask your lawyer. Longer answer - according to me that's not enough, you have to provide means for changing the version of Qt used for your library to maintain LGPL of Qt, so at least you need to provide object files of your library to make it possible to relink it into the library and relink the final executable. The source code itself can be kept closed, though. The trick with the entry point is not necessary for anything, you can provide the object file for the main() function as well. In my opinion the binary executable itself automatically becomes redistributable when linked statically so your customer can give it to as many people as he wants and you won't get paid for it. In doubt please refer to the short answer.

Hsilgos
12th June 2010, 12:15
you have to provide means for changing the version of Qt used for your library to maintain LGPL of Qt, so at least you need to provide object files of your library to make it possible to relink it into the library and relink the final executable.
But user will have possibility to change Qt or change Qt's version and relink. :confused: It's not necessary to provide objective files for it. Final executable are built from my statiс library and Qt static libraries.

wysota
12th June 2010, 12:20
If your static library needs Qt then to build it you need to link it against Qt. As it uses Qt it falls into Qt-derived work category which means the user needs to be able to replace the version of Qt used by your static library with another one which means he has to be able to relink your library which means he needs either the sources or the object files for it.

Hsilgos
12th June 2010, 16:49
If your static library needs Qt then to build it you need to link it against Qt. As it uses Qt it falls into Qt-derived work category which means the user needs to be able to replace the version of Qt used by your static library with another one which means he has to be able to relink your library which means he needs either the sources or the object files for it.
Not quite. Only application needs Qt. i.e. application link to my library and to Qt. My library only imports functions from Qt, but do not include (do not link to) Qt. At the final buld step we have my library, Qt's libraries and source file with function main(). And all this links to one executable file. According to LGPL we can provide my library. User can freely link other Qt.

wysota
12th June 2010, 17:13
Not quite. Only application needs Qt. i.e. application link to my library and to Qt. My library only imports functions from Qt, but do not include (do not link to) Qt.
Qt is more than functions from its libraries. It's enough that you include Qt headers into your code. I don't think the 5% clause applies in this case. I'm not sure though, ask your lawyer :)

I understand that you wanted to do something like in the attachment.

Hsilgos
12th June 2010, 17:41
Qt is more than functions from its libraries. It's enough that you include Qt headers into your code. I don't think the 5% clause applies in this case. I'm not sure though, ask your lawyer :)
I understand that you wanted to do something like in the attachment.

But even if i redistrubute application with dynamic-link Qt (what LGPL offers ), we have same problems: "Qt is more than functions from its libraries" :)
I understand you, thank for your replying. :)

What about qtwebrowserplugin? Do you know something?

squidge
12th June 2010, 18:27
If you dynamic-link, Nokia gives you license extension to be able to #include parts of the Qt library into your own code without it being regarded as a derived work :)