The CLA topic has come up in several recent discussions:
- Using CLA Assistant for Python
- Https://github.com/python/ is now using a new CLA bot
- New `python` organization repository policy
- Update PSF's contribution forms to reflect new CLA process · Issue #1443 · python/pythondotorg · GitHub
- Migrating to CLA Assistant · GitHub
We have been using the current CLA since 2004, when Larry Rosen created it. Since then, the world has progressed and today, we have more or changed requirements compared to those days.
I would like to kick off a process to come up with an updated CLA, which implements our needs for protecting the Python IP, as well as improve the CLA user experience and address new requirements which are not yet covered by the CLA.
Here’s a collection of requirements. This is expected to be adapted throughout the discussion and extended as necessary.
R1. The CLA needs to enable the PSF to defend the IP rights in software/documentation distributed by the PSF, which includes the contribution, in court. 
R2. The person or company signing the CLA should keep the copyright in the contribution, but permit the PSF to use the contribution and relicense the contribution under an open source license. 
R3. The initial license, by which the contributor licenses the contribution to the PSF, needs to include a patent clause, which makes sure, that the PSF can distribute software incorporating the contribution, without limitations imposed by patents owned by the contributor. 
R4. The CLA needs to make a clear distinction between individual contributions and corporate ones. 
R5. The CLA has to include a provision allowing the PSF to store and maintain personal identifiable information (PII) for the purpose of tracking the IP rights of contributions to the PSF. 
R6. The CLA signing process has to be legally sound and allow identifying the contributor for the purpose of tracking IP rights. 
R7. The term contribution should cover any submission made by the contributor to the PSF project, requiring an explicit opt-out statement for submissions which do not fall under the CLA. 
R8: The CLA should be applicable to any PSF software/documentation, which the PSF may want to distribute or make publicly available. 
R9: The CLA should include wording stating that it covers all contributions submitted on or after the date of approval by the contributor and that it supersedes any previously signed PSF CLAs for those contributions. 
Once we have collected all needed requirements, we can then approach the PSF Legal Counsel to draft up a new CLA and the PSF board to have it approved.
Please comment away …
- Current CLA on the PSF website
- Current CLA used by the CLA Gtihub Bot for CPython
- Source code of the CLA Github Bot running for CPython
- Comment by VanL (PSF Legal Counsel) on the CLA Github Bot
- More on the history of the CLA
- Comments on PII and KYC requirements
: Since the PSF is a US non-profit, this mainly refers to US law. However, it would be beneficial to make this sound under international law as well, in order for the PSF to be able to defend IP rights in other parts of the world too.
: The current CLA already covers this requirement.
: The Apache License v2 (AL2) covers this requirement. Inclusion of 3rd party software under other licenses can still be decided upon by the PSF/Steering Council, bypassing the CLAs, including e.g. software which is MIT or BSD licensed (those licenses don’t include a patent license).
: The IP rights of employee contributions are often owned by the company employing them. Accordingly, a CLA signed by such an employee would not be valid.
: In order to track contributions, the PSF has to maintain records on these. Several jurisdictions how require explicit consent to such storage (e.g. the GDPR in the EU), so this new requirement should be addressed as well.
: We are currently using a Github bot for CLA signing. In some circumstances, this does not permit the PSF to keep records which allow contacting the contributor or identifying the person by other means. We need to make sure that the PSF is willing to take the risk of not being able to contact contributors, or change the logic to only have Github users with valid email addresses signing the CLA form.
: The current requirement to mark contributions is also rarely met in practice – this is usually only done for larger contributions of e.g. new modules and subsystems, if at all. This opt-out mechanism will simplify contributing to a PSF project. It’s the standard approach taken by the AL2. By using the AL2 as initial license we are probably inheriting this feature, but the CLA should make this explicit. The wording of having to add notices to all contributions can then be removed from the current CLA.
: The current CLA already appears to cover this requirement, but it would be better to include documentation explicitly as possible contribution (it’s currently limited to software).
: The current CLA does not explicitly mention the effective date or whether it applies to past or only future contributions.
- Changed from inline footnotes to manual ones, so that footnotes stay visible.
- Added additional comment to footnote .
- Added new requirement R9 to clarify the effective date of the CLA and its applicability.
- Added note referring to inclusion of 3rd party software under non-AL2 licenses.
- Added CLA used by the CLA Bot to the resources.