Skip to content

Slycot license is GPL whereas python-control license is BSD. #1057

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ubaldot opened this issue Nov 12, 2024 · 5 comments
Open

Slycot license is GPL whereas python-control license is BSD. #1057

ubaldot opened this issue Nov 12, 2024 · 5 comments

Comments

@ubaldot
Copy link

ubaldot commented Nov 12, 2024

It looks like that python-control (BSD license) relies on slycot (GPL license). Shouldn't python-control be released under GPL license as well?

@ubaldot
Copy link
Author

ubaldot commented 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
Copy link
Member

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
Copy link
Member

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.

@ubaldot
Copy link
Author

ubaldot commented 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?

@slivingston slivingston reopened this Nov 13, 2024
@bnavigator
Copy link
Contributor

See also python-control/Slycot#152, #928

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants