GPLv3 License Violation

[btschwertfeger]

Description

I am writing to bring to your attention an issue regarding the licensing of your project. It appears that the project includes a submodule licensed under the GNU General Public License version 3 (GPLv3), but the repository as a whole is licensed under the MIT license without any appreciation of the authors of the GPLv3 project. This constitutes a violation of the GPLv3 license terms.

Issue Details

• Repository: https://github.com/alan-turing-institute/clim-recal
• Submodule: https://github.com/alan-turing-institute/python-cmethods/tree/e2c176a0e19e7179f699d6e438e560b875f11537; original: https://github.com/btschwertfeger/python-cmethods
• License of Submodule: GNU General Public License version 3 (GPLv3)
• License of Repository: MIT License

License Conflict

The GNU General Public License version 3 (GPLv3) requires that any derivative work based on GPLv3 licensed software must also be licensed under the GPLv3. This means that if a project includes or incorporates GPLv3 licensed components, the entire project must be distributed under the GPLv3. The current licensing of the repository under the MIT license does not comply with this requirement.

Requirements for Compliance

To ensure compliance with the GPLv3 license terms, the following actions should be taken:

• Re-license the Entire Repository: Change the license of the entire repository to GPLv3.
• Include License Notices: Add the GPLv3 license text to the repository and ensure all files retain the necessary copyright notices and disclaimers of warranty.
• Provide Attribution: Properly attribute the authors of the GPLv3 licensed submodule in all relevant project documentations (docs, README, pyproject.toml, etc.) as well as in all derived works.

Conclusion

Ensuring that the project complies with the GPLv3 license terms is crucial to maintaining open-source license integrity and avoiding potential legal issues. Thank you for your attention to this matter and for your contributions to the open-source community.

If you need any assistance in making these adjustments, I am more than willing to help.

Best regards,

The author of python-cmethods

[griff-rees]

Thanks very much @btschwertfeger for this detailed ticket. It is my understanding that this difference was not intended. I have flagged this with my colleague and we aim to respond in more depth next week.

Best wishes.

[andrewphilipsmith]

@btschwertfeger

Thank you for bringing this important matter to our attention. We apologise for this inadvertent mistake.

At present, we are not using python-cmethods, as our focus has been on other aspects of our research. Therefore, we view the simplest resolution is to remove the relevant submodule from the repo.

We have taken the following actions to resolve this matter:

• We have removed the relevant submodule from this repository
• Added an acknowledgement and citation in the main README.md.
• Added a note to the `python/README.md` file.

These changes are made in PR #164. We would welcome your comments on this PR.

I hope this is a satisfactory resolution. Please do let us know if you have any ongoing concerns. Many thanks

[btschwertfeger]

Hello @andrewphilipsmith, any updates on this?

[andrewphilipsmith]

We have merged #164, which removes the python-cmethods submodule.

We are also removing all of the debiasing features from this repo, which will remove many of the other mentions of methods. This work is in progress here #182.