Disclosure of Application Source Code under LGPL v3.0
-
Hello All,
There is a system level application I am designing for my Clients with the help of PySide6. It is written in the Qt website :
https://www.qt.io/development/open-source-lgpl-obligations
that if we dynamically link the package as is then it will fall under “work that uses the library”, and is outside the LGPL v3.0 scope.
So if I do dynamic linking then I don't have to share my source codes right? -
Hello All,
There is a system level application I am designing for my Clients with the help of PySide6. It is written in the Qt website :
https://www.qt.io/development/open-source-lgpl-obligations
that if we dynamically link the package as is then it will fall under “work that uses the library”, and is outside the LGPL v3.0 scope.
So if I do dynamic linking then I don't have to share my source codes right?@MSDev said in Disclosure of Application Source Code under LGPL v3.0:
So if I do dynamic linking then I don't have to share my source codes right?
Correct.
But you need to provide your customers/users a possibility to link the application with their own version of Qt (if they ask for this). This means: you have to provide object files, so that they can link by themselfs.
Keep in mind: I'm not a lawyer! -
@MSDev said in Disclosure of Application Source Code under LGPL v3.0:
So if I do dynamic linking then I don't have to share my source codes right?
Correct.
But you need to provide your customers/users a possibility to link the application with their own version of Qt (if they ask for this). This means: you have to provide object files, so that they can link by themselfs.
Keep in mind: I'm not a lawyer!@jsulm said in Disclosure of Application Source Code under LGPL v3.0:
This means: you have to provide object files, so that they can link by themselfs.
I believe you are mixing dynamic and static linking. With dynamic linking everybody can just replace the DLLs/.so's with their own copy. Usually, you don't have to provide anything separate in this case. In order to be pedantic: If you deliver the dynamic Qt libraries you need to also provide the Qt source code or a written offer valid for a specific amount of time (I don't remember the timespan; the LGPL references the GPL for this) to obtain the Qt source code from you.
@MSDev said in Disclosure of Application Source Code under LGPL v3.0:
So if I do dynamic linking then I don't have to share my source codes right?
Even if you use static linking you don't have to share your source code. However, it guess it would be more difficult when using Python as you would usually provide the object files which would allow linking with the static Qt library. The LGPL only offers rights for the library itself, but does not say anything (too specific) about the license for your own source code.
-
@jsulm said in Disclosure of Application Source Code under LGPL v3.0:
This means: you have to provide object files, so that they can link by themselfs.
I believe you are mixing dynamic and static linking. With dynamic linking everybody can just replace the DLLs/.so's with their own copy. Usually, you don't have to provide anything separate in this case. In order to be pedantic: If you deliver the dynamic Qt libraries you need to also provide the Qt source code or a written offer valid for a specific amount of time (I don't remember the timespan; the LGPL references the GPL for this) to obtain the Qt source code from you.
@MSDev said in Disclosure of Application Source Code under LGPL v3.0:
So if I do dynamic linking then I don't have to share my source codes right?
Even if you use static linking you don't have to share your source code. However, it guess it would be more difficult when using Python as you would usually provide the object files which would allow linking with the static Qt library. The LGPL only offers rights for the library itself, but does not say anything (too specific) about the license for your own source code.
@SimonSchroeder said in Disclosure of Application Source Code under LGPL v3.0:
I believe you are mixing dynamic and static linking.
Yes, missed the dynamic part
-
Hello All,
There is a system level application I am designing for my Clients with the help of PySide6. It is written in the Qt website :
https://www.qt.io/development/open-source-lgpl-obligations
that if we dynamically link the package as is then it will fall under “work that uses the library”, and is outside the LGPL v3.0 scope.
So if I do dynamic linking then I don't have to share my source codes right?@MSDev said in Disclosure of Application Source Code under LGPL v3.0:
So if I do dynamic linking then I don't have to share my source codes right?
In addition to what my colleagues have said. Since your code is in PySide/Python rather than C++, how do you propose not to "share your source code" anyway? Unlike the C++ situation your Python files are required at runtime and are perfectly readable to anyone. Unless you do some sort of "obfuscation" or you can force somehow to compile the Python you won't be supplying any "object" files of your own anyway?
