New `python` organization repository policy

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

4 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.

Aha, that’s an interesting information :wink:

GitHub’s announcement:

2 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 :slight_smile:

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” ?

1 Like

“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 ?