You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Slycot license is GPL whereas python-control license is BSD. #1057
Ok, I may self-answer my question: slycot is not necessary (but it is desirable). Python-control can run without slycot for many use-cases. If your work falls in such use-cases, then you can consider your work bsd license compliant.
If you are using python-control functionalities that require slycot, then your work must adhere to gpl licensing. Make sense?
Sadly, interpreting the relevance/consequences of GPL can be complicated. Notes:
Slycot is under the GPLv2 (not the current GPLv3). The Linux kernel also has license GPLv2 and is famous/infamous for being lax regarding licenses of kernel modules.
Running the software as a service (a.k.a. users over a network) does not imply the need to distribute changes. For that requirement, you need a license like the GNU Affero GPL.
If Slycot with GPL is a significant difficulty in your work, consider the task of getting permissions so we can switch Slycot to BSD-3-Clause. If you do this, be sure to confirm how to do it correctly (legally). There are other projects that have changed licenses before, so there is precedent.
The point is that private organizations prefer to stay on the safe side and generally the utilization of open-source software is forbidden. However, some permissive companies allow the solely utilization of MIT-like licenses open source software, and typically utilization of GPL license software is blacklisted. In python-control specific case, the situation is a bit on the grey zone, since the statements around slycot could be further clarified. Such uncertainty would be enough to forbid employees to use python-control package. That would be a pity IMO.
Perhaps it could be good to add some clearer and sharp notes explaining when the gpl constraints apply and how to avoid fall into that use-case in the README file?
I am thinking to further stress this aspect through a statement like the following: "If you are not allowed to use GPL licensed software just don't install slycot.
The python-control package will still work but some functions may be penalized or will simply don't work, but you are guaranteed to be in the BSD-licensed domain" or something similar. Any thoughts?
Activity
ubaldot commentedon Nov 12, 2024
Ok, I may self-answer my question: slycot is not necessary (but it is desirable). Python-control can run without slycot for many use-cases. If your work falls in such use-cases, then you can consider your work bsd license compliant.
If you are using python-control functionalities that require slycot, then your work must adhere to gpl licensing. Make sense?
slivingston commentedon Nov 13, 2024
Your self-answer is correct, but I am not a lawyer.
Note the section about license in the Slycot README: it is possible to switch to BSD-3-Clause if we get explicit permission from all authors.
slivingston commentedon Nov 13, 2024
Sadly, interpreting the relevance/consequences of GPL can be complicated. Notes:
ubaldot commentedon Nov 13, 2024
Ok, I see, thanks.
The point is that private organizations prefer to stay on the safe side and generally the utilization of open-source software is forbidden. However, some permissive companies allow the solely utilization of MIT-like licenses open source software, and typically utilization of GPL license software is blacklisted. In python-control specific case, the situation is a bit on the grey zone, since the statements around slycot could be further clarified. Such uncertainty would be enough to forbid employees to use python-control package. That would be a pity IMO.
Perhaps it could be good to add some clearer and sharp notes explaining when the gpl constraints apply and how to avoid fall into that use-case in the README file?
I am thinking to further stress this aspect through a statement like the following: "If you are not allowed to use GPL licensed software just don't install slycot.
The python-control package will still work but some functions may be penalized or will simply don't work, but you are guaranteed to be in the BSD-licensed domain" or something similar. Any thoughts?
bnavigator commentedon Nov 13, 2024
See also python-control/Slycot#152, #928