pyo3
pyo3 copied to clipboard
PyO3
Dual licensing under Apache and MIT
How difficult would it be to dual-license PyO3 under the Apache and MIT licenses, like Rust itself? This would work around the incompatibility between the Apache license and GPL 2. I ask about this because I'm thinking about using PyO3 in an add-on to a GPL 2 program.
A good question. I am by no means an expert in licensing law.
https://opensource.stackexchange.com/a/2032 suggests it could be very difficult. If all previous PyO3 contributors need to grant approval then in practice this may be impossible.
I'm sure that this must be done from time to time with open source projects. If you can find examples of how projects have done this in practice, I would be happy to cast my vote for dual licensing if a process was agreed.
We did this on pyca/cryptography many years ago: https://github.com/pyca/cryptography/issues/1209 is how we did it.
Yeah I think in theory we can do it, though it might take time since we now have 182 contributors.
@alex thanks for sharing that. How did you identify the list of contributors to contact? Was it just everyone who had ever submitted to the repo?
I'm willing to personally donate some money to help pay someone to take care of this. There's a GPL2-licensed Python-based project I care very much about that, I think, could benefit from gradually adopting Rust in some extension modules. It would be unfortunate if the technical implementation of this had to be compromised due to a license incompatibility.
Sorry for running slow on this. I'm not sure a financial incentive is necessary here. It should be straightforward enough to generate a list of contributors and ask for approval.
Presumably that list would include all contributors from rust-cpython before this project was forked? A good first step may be to seek opinions from @dgrunwald and @fafhrd91 on what they think of changing PyO3 to be dual licensed.
I just note that rust-cpython is distributed under MIT license. I hope it won't make the problem more complex.
I'm also interested in this.
@dgrunwald and @fafhrd91: would you agree to such a change?
If yes, I'm willing to handle the task of contacting everyone and updating necessary files.
I am OK with dual-licensing rust-cpython under the Apache and MIT licenses.
As far as I can tell, rust-cpython is already licensed under only the MIT license. That's fine with @DataTriny and me. It's the Apache license that's problematic, since it's incompatible with GPL 2. So the license of PyO3 needs to change, but not the license of rust-cpython.
Thanks @DataTriny! Do you want to start a PR to change the license? On that PR discussion you can maintain a checklist which can be maintained and can chase up all past contributors?
To keep things correct I think we should also request new contributors agree to their changes being relicensed while we are in the transition period.
@davidhewitt Yes, that's exactly my plan. But I've counted around 250 contributors. So making sure I collect accurate information on everyone will take me a couple of days!
Indeed, making sure new contributors agree to the new licensing scheme before their changes get merged here is necessary. I'll keep an eye on this repo, but it would be nice if you could enforce this rule as well.
I just opened #3108. Unfortunately it looks like I can only mention 50 people in a comment, so we'll have to do this gradually...
good luck :) for future you might consider this tiny doc to be useful -> https://github.com/mrl5/private-wiki/blob/master/open-software-licenses.md
Thanks @DataTriny for starting the thread with #3108. It looks like we have most contributors, however not everyone has replied so I guess we'll need to ping or chase them again? Do you have a plan how we can do that?
BTW if only a few are unresponsive, it is worth going through their commit(s) to determine if their contribution is either so small as to not be relevant for copyright, or can be reimplemented, or not even present anymore in the current code base.
Indeed we still haven't heard from 40 people or so. I wanted to wait a bit before contacting contributors directly by email but I think enough time has passed, so I will start doing it.
However, I expect to not receive a reply from everyone, so at some point I plan to go evaluate each contribution. If it's small, we will have to get rid of it and maybe rewrite it.
It would not be safe to ignore someone and relicense with their contribution still in the git history.
@birkenfeld @davidhewitt Mind pinning this issue so people won't miss it? It might be worth referencing in the README as well.
As only a few past contributors haven't given their consent, and since it's becoming very hard to get their attention through emails or social media, I have compiled their commits in the below table.
| Commit | Author | Current status | Possible actions |
|---|---|---|---|
| 384f32a | @cecini | Only a few LOCs remain and have been moved to pyo3-build-config/src/impl_.rs, change log written by @davidhewitt apparently. |
Could be replaced as part of housekeeping for #3204? |
| 51e7d55 | @potocpav | Modified impl block seem to not exist anymore. |
Discard the commit. |
| 2c0a866 | @thanatos | The fixed example have been removed. | Discard the commit. |
| 80502bd | @thanatos | All typos that have been fixed are on lines that have later been modified in one way or another. | Discard the commit. |
What should "Discard the commit" mean? Ideally we would like to have their names out of the git history, but this might be too destructive of an action.
What should "Discard the commit" mean? Ideally we would like to have their names out of the git history, but this might be too destructive of an action.
I think that is certainly too destructive. I think it would be preferable to for example commit this analysis and the verdict for the various commits into the repository as well to have paper trail for the future instead of rewriting history.
One option could be to commit a git revert for each of the commits to discard. Downside - it might be a bit busywork-heavy, as any modifications which conflict with newer changes would need manually fixing up (possibly forcing new implementations to be written instead). Upside - it very clearly actions the removal of those contributions in the git history.
I plan to send a last email probably tomorrow.
I also think revert commits is a good option. I have never done this on that scale, but we don't have many commits and they are all limited in scope. I can start this work during the weekend.
It would probably be better if I commit them before the relicensing update, in separate PRs. What do you think?
I am not a lawyer, you should consult with a lawyer and not take legal advice from software engineers on the internet. (Se
In copyright law, there is the idea that some contributions to works are de minimis, and therefore are not eligible for copyright, because they are too small to truly be a creative work (see https://www.lsd.law/define/de-minimis-test). To my understanding, several of these commits likely fall into this category, and thus permission from the original author isn't required to relicense it, because as a matter of law they do not hold a copyright interest.
I cannot stress enough that I'm not a lawyer, nor do I play one on television. If you'd like to speak to a lawyer with expertise in these issues, Van Lindberg (General Counsel to the Python Software Foundation) may be able to provide real advise.
Thanks - I plan to find time to reach out to Van Lindberg and also to the Rust Foundation next week.
Sorry for not coming back to this earlier, I still have other priorities at the moment. Thanks @alex for the resource. The fact that you are not a lawyer is not an issue, the fact that the link you provided don't seem to reference previous court decisions is more problematic. What we have to find IMO is an instance of a court ruling in the software space that would give us indications. Is fixing a typo important for copyright? Probably not. Is updating a paragraph in the documentation enough? Maybe, maybe not.
I don't plan to reach out to the remaining contributors at this point. They probably won't reply so we have to take care of the 6 commits left.
@davidhewitt Have you found time to reach out to Van Lindberg or the Rust Foundation yet?
I now know of a concrete case where this relicensing effort matters: MathCAT for Python uses PyO3, but includes an add-on for the NVDA screen reader, which is under GPLv2. This add-on might itself introduce a license incompatibility, but I know that the primary developer of MathCAT wants to introduce it into the core of NVDA, and that would definitely raise the issue of the incompatibility between the Apache License and GPLv2. I opened this issue in the first place because I wanted to use PyO3 for a future NVDA add-on project of my own, but that's only hypothetical; the MathCAT add-on is already here.
Afraid not yet. I've blocked out some time on Friday to reach out. (Unfortunately my family were sick when I had attempted to block out time the other week.)