Repository navigation
Slycot license is GPL whereas python-control license is BSD. #1057
Description
Activity
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?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.
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.
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?See also python-control/Slycot#152, #928
It looks like that python-control (BSD license) relies on slycot (GPL license). Shouldn't python-control be released under GPL license as well?