Questions of the LGPL with QT
-
Hi :)
I plan to use the LGPL V3 for QT 5.8 (or 5.9 since that one came out today) for an application that is closed source.
I do have some specific questions which I can't answer myself by reading the LGPL licence. I do know that I need to host a location for the QT source myself and I do not need to compile it myself.
Please inform me if something is legal and/or is against the idea of the LGPL.- What are the limitations of a wrapper class? This sounds probably a bit weird. The wrapper I have so far wraps the vector3D so I can change the values of vector3D with one call (aka: setXYZ). I'll make that one open source, however it could be that I want to make one that isn't.
- Am I allowed to check if the libraries of QT do what I want? For example: write a function that checks if sockets work the way they should (with a hash etc). I know I shouldn't check if the hash of the libraries are correct, since that would violate the LGPL.
- What are good places to say I use QT? Since I use the LGPL I want to make sure everyone who uses the application knows it. So I plan to set it in the README, the opening of the application and in the credits.
- This is probably a weird question: Can I advice against changing the libraries of QT? I'll maintain the project and there will probably bugs. If someone changes the library it could be that the change made the bug (not very likely, however I would like to know this).
Thank you for the long read, these questions will help me a lot understanding the LGPL more :)
Greatings,
gangerM -
Hi @gangerM
Those are pretty detailed questions. Actually so detailed, that I would talk to an open source ipr lawyer. (and this time I mean it, usually it's just said to point out to the person asking that they are not talking to a lawyer, which I most definitely am not)
- I'm not qualified to answer that, my understanding of the (L)GPL is not sufficiently deep. This will easily turn into a philosophical discussion on what is a wrapper and what is original work. Easiest way to avoid that is open source the wrapper.
- You mean testing at run time to see if the library functions work as they do on normally? I guess the question is what you do if the answer isn't what you expect? The point of the clause is to make sure the user can change the library and the application or device will still work. So normal error checking code must be ok, but stopping artificially on a changed library is not ok. Not an easy question, although not as philosophical as the first one. (ok, almost as philosophical)
- Those are quite sufficient. I recall that having it in the "about" section of the application is sufficient.
- Borderline on being in line with the intent of the LGPL. Probably(?) ok if you point out that the user is free to switch in their own compatible library. I do see the point of saying that the library you ship with is the best thing to use. Most applications probably don't do this, because most users do not get the idea of changing the libraries underneath.
I have to say that you already have a pretty good grasp of the LGPL when you can ask this level of questions.
