This is correct.
This seems reasonable - perhaps move mypy out to its own org, and get CLA coverage for typeshed.
4 Likes
As a typeshed maintainer, I believe that CLA coverage for typeshed would be detrimental. Currently, the bar for contributions is very low and requiring contributors signing the CLA would hinder us significantly. The contributions to typeshed are often quite small. Also, I have my doubts that a typical stub contribution is even copyrightable, as they are usually completely constrained by the stubbed interface and other technical limitations. There is no room for creativity.
The current consensus among typeshed maintainers seems to be to move typeshed outside the python organization if the CLA requirement would be enforced: CLA requirement · Issue #8305 · python/typeshed · GitHub
6 Likes
This is my personal opinion, not any kind of a SC reply:
Are the stdlib stubs in typeshed intended to be (partially) merged into CPython (in some possible future when that becomes acceptable)?
If yes, the CLA is needed.
If not, then Iâd argue that typeshed shouldnât go in the python org if it was created today. The question then is whether it can be kept in, or if it should be moved out. I donât have a strong opinion on that, but IMOâs GHâs move mechanism is good at leaving redirects in place, so itâs not that big a deal technically, and the autonomy of its own GH organization might actually be better for the project.
One possibility is that if stubs themselves are not an independently-copyrightable expression, given they are essentially a highly austere, purely technical description of fact that is nearly entirely dictated by the existing code and offers fairly minimal room for any variance, then theoretically if the CLA bot could check for whether a contribution to typeshed only touched stub files and if so, donât run the CLA check, which could potentially alleviate most of the maintainer concerns. However, this would of course be something a qualified and licensed copyright attorney would need to conduct legal research to determine, and is certainly non-trivial.
1 Like
A few years ago, /psf/ was seen as the place for âblessedâ projects. For example, the requests project moved to https://github.com/psf/requests/. Honestly, I donât recall the discussions, but thatâs somehow how the pyperf project landed at https://github.com/psf/pyperf. Should projects like requests and pyperf be moved from /psf/ to /python/?
I donât understand well the difference between /psf/ and /python/.
The pyperformance project home is in the /python/ organization. This project uses pyperf.
Iâm asking asking because it would be nice to get 2FA security for the pyperf project, but it doesnât seem planned to enable it in the /psf/ organization.
Iâm one of the 3 maintainers of the https://github.com/python/pythoncapi-compat/ project but I donât see how I can check if the other members have 2FA configured. Members are this team: https://github.com/orgs/python/teams/pythoncapi_compat/members. The UI doesnât say if other people have 2FA enabled or not. Is it a public information? Should I ask other members in private?
The pythoncapi-compat project is distributed under the Zero Clause BSD (0BSD) license on purpose: to allow copying the pythoncapi_compat.h file in most projects without causing licensing issues. For example, copying a file distributed under the MIT license requires to mention the MIT license somewhere in the project, I wanted to prevent that.
Does it mean that CLA will not be needed in this case?
Itâs not public info, but the GitHub admins are able to see it. As thereâs only two other members in your team, you could ask them privately.
Requests should definitely not be moved. The Python core devs are not going to maintain requests.
2FA is going to be required for all GitHub accounts by the end of next year, so you will end up with it eventually.
1 Like
Aha, thatâs an interesting information 
GitHubâs announcement:
3 Likes
This is similar to the PEPs repo. The original code/text is already
licensed under a very liberal license, so there should be no need to
sign a CLA for such repos.
The CLA process is only needed for software which the PSF wants to
redistribute under a single license, with the choice of the (open
source compatible) license being with the PSF, regardless of what
the original code is licensed under by the contributor.
The CLA grants the PSF this relicensing possibility, in addition to
creating a licensing relationship between the author and the PSF
under the Apache license (or whichever license is selected in
the CLA process).
The original post by @encukou describes it in more detail, and @VanL explains the legal side of things, but it seems the basic distinction is that the python org is for things that will be shipped with Python or directly support the development of CPython and the language itself (docs, PEPs, infra, translations, tooling, etc) while the psf repo is for everything else, particularly a home for key projects of high importance to the community.
Unless my understanding of the legal situation and @VanL 's statements on the matter is incorrect, the permissiveness of the intended source license does not have direct bearing on the need for a CLA, and the fact that the content is not being licensed under the PSF license in particular only affects some but not all of the reasons for the CLA. Per Vanâs post on the matter:
Only reason 1 is directly concerned with the relicenseing to the PSF license, whereas the second reason is essentially a DCO (applicable to any project) and the third item provides protection against a contributorâs employer later claiming they didnât have the right to do, and thus claiming copyright and patent rights on (e.g.) a published and implemented PEP. Additionally, also requiring Apache-2.0 on ingest may be especially important for PEPs, since they could be vulnerable to patent trolling (including ambushes) and the CC0 explicitly disclaims granting any patent license to the contents, whereas Apache-2.0 includes an explicit patent grant.
Of course, that is my personal interpretation; I am not a lawyer and this is not legal advice. @VanL , could you confirm here?
Perhaps adding some history helps 
The CLA we have for Python was created to simplify the process of
contributing to CPython, with the intent that the PSF gets the needed
rights to distribute copies of the code under a single license
(the PSF License 2).
The copyright to the contribution remains with the contributor - unlike
with many other CLAs. This was a novel idea by Larry Rosen, who
authored the Python CLAs back in 2004. He was also the author of the
Academic Free License, which is why it was (and apparently still is on the
non-Github-CLA-Bot forms) one of the available licenses which which
the contributor can license the code to the PSF.
The reason for choosing the AFL or the Apache license and not e.g.
the BSD license or the PSF license was that these two include
provisions for dealing with patents.
This solved many of the issues we had with the license stack building
up and more and more 3rd party licenses becoming part of the Python
license.
The CLAs were specifically meant to enable distributions of
CPython by the PSF, not for any other code or text.
Of course, the CLAs can be used for other purposes as well, including
the ones that Van mentioned.
Vanâs comment âThis gives us the right to use the code absent them
putting a licensing declaration in each file or PR.â does not appear
to be 100% correct, though, since the CLA explicitly requires âContributor
shall identify each Contribution by placing the following notice in
its source code adjacent to Contributorâs valid copyright notice:
âLicensed to PSF under a Contributor Agreement.ââ
In the past, we only required this for larger contributions
of new code, e.g. new modules or subsystems. I guess we could
clarify the CLA a bit to also state that any PR submitted to a
PSF repo under CLA control implicitly fulfills this requirement.
That said, whether CLAs are needed or not for a particular repo, is
a separate discussion. The CLA was so far only meant for and needed
for the GitHub - python/cpython: The Python programming language repo.
As a result, I believe that enabling 2FA for repos under the python
org is fine, but enabling the CLA bot needs to be discussed with
the maintainers of the other org repos individually.
PS: Could you explain what you mean with âDCOâ ?
2 Likes
âDCOâ is a common abbrev for Developer Certificate of Origin,
popularized by LF and used for contributions to the Linux kernel,
among other projects:
Thank you for the link.
The DCO includes an interesting section, which we currently donât cover
in the CLA:
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
With respect to the GDPR, this explicit consent to the use of personal
information (PII) is necessary - probably under other privacy
regulations as well.
The CLA process currently does include an explicit consent. At best,
itâs implicit, but thatâs not enough to fulfill the GDPR
requirements.
The Apache License also includes an interesting twist with respect
to how âContributionâ is defined. Unlike our CLA, which requires
explicitly marking what constitutes the âContributionâ, the
Apache License regards all submissions as part of a âContributionâ
and requires the contributor to explicitly mark parts which are
not part of the âContributionâ to be marked as such. This approach
simplifies the process somewhat and avoids repeated copyright
and license notices in contributions.
Perhaps itâs time to start working on a new version of the CLA and
the associated process to get CPython prepared for the future ?!
Should we start a new topic on this ?
1 Like
Definitely start a new Discuss topic if there is anyone actually interested in working with PSF legal council on determining if an updated Contributor License Agreement is necessary, and if so, what it should be. This is not something the Steering Council decides. 
My take is that a lot of what you have said cannot be presumed true. Even if some of it might actually wind up true. As the only person in this thread with the ability to give legal advice is the legal council representing the PSF, when specifically engaged to do so.
I have opinions. But as they are on legal matters, I have no authority to claim their veracity, so I wonât write them down lest someone choose to misinterpret my statements as intent. (Iâve taken that corporate training too many times) 
Iâll start a new topic, since this is getting off-topic, but I do want to emphasize that the Steering Council is indeed the body who decides the list of requirements we have for the CLA.
We have lawyers to guide through the process, advise on implications, highlight risks and help put those requirements into legal text, but not to define those requirements.
1 Like
Hereâs the new topic for anyone who wants to continue the discussion: Modernizing the Contributor License Agreement (CLA)
2FA will soon be required for Python · GitHub org members, please enable it if you havenât already:
2 Likes