LGPL -- help me get a more concrete understanding of which classes I need to make available in the .dlls
-
I'm confused about the nuts and bolts of widget classes and how to ensure they comply with the LGPL.
Let's suppose I'm making an app for commercial distribution that uses Qt under the LGPL. For the sake of over-simplification, suppose the app has a main.cpp that creates and shows a widget of the class MyWidget, which is a custom class that inherits from QWidget. The custom MyWidget class is very simple:
(a) it contains a button and a label;
(b) MyWidget.h declares a signal that is fired when the button is pressed;
(c) MyWidget.cpp declares (and MyWidget.cpp defines) a slot that puts text in the label.Obviously, the thinking behind all of this is that I want to keep the UI (i.e., a QWidget child class) separate from the logic (regular C++ code that does not inherit from any Qt class), so the UI code relies on slots and signals to (a) tell the logic when the user interacts with the UI so the logic can handle appropriately, and (b) allows the logic to tell the UI to update in some appropriate way.
I realize that the LGPL says we need to make available to users the Qt library and any modifications to the Qt library. In my example, are MyWidget.h and MyWidget.cpp the kinds of modifications that need to be made available to the user for the user to modify/replace? If so, do developers generally have to make their entire body of UI code available to users under the LGPL, or are developers handling this some other way to reduce the volume of code subject to the LGPL? I'm not trying to debate the merits of the license or anything here -- I am getting started on a pretty large app and have decided to use Qt, and it would be very helpful to know in advance whether I need to set all of the UI files up for distribution as .dlls.
Thanks for your insights!
-
I'm confused about the nuts and bolts of widget classes and how to ensure they comply with the LGPL.
Let's suppose I'm making an app for commercial distribution that uses Qt under the LGPL. For the sake of over-simplification, suppose the app has a main.cpp that creates and shows a widget of the class MyWidget, which is a custom class that inherits from QWidget. The custom MyWidget class is very simple:
(a) it contains a button and a label;
(b) MyWidget.h declares a signal that is fired when the button is pressed;
(c) MyWidget.cpp declares (and MyWidget.cpp defines) a slot that puts text in the label.Obviously, the thinking behind all of this is that I want to keep the UI (i.e., a QWidget child class) separate from the logic (regular C++ code that does not inherit from any Qt class), so the UI code relies on slots and signals to (a) tell the logic when the user interacts with the UI so the logic can handle appropriately, and (b) allows the logic to tell the UI to update in some appropriate way.
I realize that the LGPL says we need to make available to users the Qt library and any modifications to the Qt library. In my example, are MyWidget.h and MyWidget.cpp the kinds of modifications that need to be made available to the user for the user to modify/replace? If so, do developers generally have to make their entire body of UI code available to users under the LGPL, or are developers handling this some other way to reduce the volume of code subject to the LGPL? I'm not trying to debate the merits of the license or anything here -- I am getting started on a pretty large app and have decided to use Qt, and it would be very helpful to know in advance whether I need to set all of the UI files up for distribution as .dlls.
Thanks for your insights!
@GuitarMan said in LGPL -- help me get a more concrete understanding of which classes I need to make available in the .dlls:
are MyWidget.h and MyWidget.cpp the kinds of modifications that need to be made available to the user
No, you don't modify Qt code here so it's no modification of Qt code.
You have to make available the Qt which you compile your program against somewhere though. -
@GuitarMan said in LGPL -- help me get a more concrete understanding of which classes I need to make available in the .dlls:
are MyWidget.h and MyWidget.cpp the kinds of modifications that need to be made available to the user
No, you don't modify Qt code here so it's no modification of Qt code.
You have to make available the Qt which you compile your program against somewhere though.@Christian-Ehrlicher
Thanks! -
@GuitarMan said in LGPL -- help me get a more concrete understanding of which classes I need to make available in the .dlls:
are MyWidget.h and MyWidget.cpp the kinds of modifications that need to be made available to the user
No, you don't modify Qt code here so it's no modification of Qt code.
You have to make available the Qt which you compile your program against somewhere though.@Christian-Ehrlicher said in LGPL -- help me get a more concrete understanding of which classes I need to make available in the .dlls:
You have to make available the Qt which you compile your program against somewhere though.
To be more precise: You need make the source code of Qt available. It is not sufficient to link the Qt web page for download. You need to have the source code and provide it (written offer valid for at least 3 weeks or access in the same way as access to your application – if user download your application they need to be able to download the Qt source from your server as well). Furthermore, you need to provide a way for the user to change the Qt version. If you are using DLLs then you are fine.
