New `python` organization repository policy

Core Workflow
1

Hello,

When asked about adding the typing_extensions repository to the Python organization (#126), the Steering Council discussed a general policy for the organization, as the current one seems outdated.

We decided on the guidelines below.
Note that existing repositories can stay under python. However, we will ask that:

  • PSF infrastructure be moved under the psf organization, and
  • all repositories under python will need to require the CLA and have two-factor authentication for all committers, otherwise move elsewhere or be archived.

– Petr, on behalf of the Steering Council

New Organization Repository Policy

Within the GitHub Python organization, repositories are expected to relate to the Python language, the CPython reference implementation, their documentation and their development workflow. This includes, for example:

Before adding a new repository, permission should be sought from the Python steering council. Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate today.

All non-archived repositories must require contributors to sign the PSF Contributor Agreement.

Generally, new repositories should start their life under personal GitHub accounts or other GitHub orgs. It is relatively easy to move a repository to the organization once it is mature. For example, this would now apply to experimental features like asyncio, exceptiongroups or typed_ast and drafts of new guides and other documentation (e.g. redistributor-guide).

General-use tools and libraries (e.g. mypy or black) should also be developed outside the python organization, unless core devs (as represented by the SC) specifically want to “bless” one implementation (as with e.g. typeshed, tzdata, or pythoncapi-compat).

6 Likes
2

I don’t think that this can be configured per repository, only per organization. (I just checked in an org/repository where I am owner.) Supposedly, this wouldn’t affect outside contributors to those repositories, either. What’s the best way to approach this?

3

Correct, 2FA can only be set to required at the org level, however it also applies to outside contributors.

See the warnings in the GitHub docs:

Warnings:

  • When you require use of two-factor authentication for your organization, members, outside collaborators, and billing managers (including bot accounts) who do not use 2FA will be removed from the organization and lose access to its repositories. They will also lose access to their forks of the organization’s private repositories. You can reinstate their access privileges and settings if they enable two-factor authentication for their personal account within three months of their removal from your organization.
  • If an organization owner, member, billing manager, or outside collaborator disables 2FA for their personal account after you’ve enabled required two-factor authentication, they will automatically be removed from the organization.
  • If you’re the sole owner of an organization that requires two-factor authentication, you won’t be able to disable 2FA for your personal account without disabling required two-factor authentication for the organization.

I guess 2FA is not currently required for https://github.com/python?

It’s not necessarily a bad thing to have people without 2FA removed from the org, they can be re-added easily enough, but we should announce it first to give people time to enable 2FA.

2 Likes
4

Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate today.

It looks like they can be moved and old links will continue to work:

1 Like
5

This is a change from current practice; typeshed and mypy (probably the most active repos in the org outside cpython) don’t require the CLA. Is there a legal reason for this change? Note that these repos currently don’t require the CLA, so any change would not cover some of the existing code.

3 Likes
6

Just for clarification: I assume you mean typeshed and mypy.

3 Likes
8

I agree but the decision may require some public discussion before SC decision, given several committers get notifications from these new repositories, sounds like good courtesy.

10

Correct.

Hence this announcement. :slightly_smiling_face: Also note there’s no timeline announced yet, so this isn’t happening tomorrow (the PSF repos would have to move first).

Correct, although we are also not trying to cause massive upheaval by moving a bunch of projects that have existed under the python org for years either.

From the perspective of expectations, yes; I would expect folks assume stuff under the python org is being handled as best as possible from a legal perspective.I also don’t think we want the PSF pulled into any legal issues based on the code being hosted under our org due to the lack of CLA, which isn’t a huge burden IMO.

Or look at it from the perspective of what we are saying the org should be: stuff related to Python. In that case the PSF CLA makes sense to broadly apply as the repos under Python expected to fall under PSF jurisdiction legally anyway. As you point out there are some historical repos which that doesn’t fit, but we also wouldn’t want a slip-up of not having the CLA where it’s expected either.

CPython itself doesn’t have full CLA coverage either. But some coverage is better than no coverage.

3 Likes
11

Maybe we need to distinguish between 2FA and CLA? I’m all for 2FA everywhere ASAP, but CLA has limited benefits IMO, and deserves more discussion.

4 Likes
12

I assume that PyPI and the related repositories for it are still fine to exist outside of the python organization, we just started utilizing and migrating stuff to the pypi organization, which is also controlled by the PSF.

13

Yes, we (python steering council) only speak for the GH /python/ org. Moving PSF infra related things under the psf org is merely a suggestion meant more to imply “somewhere managed by the PSF”.

2 Likes
14

Agreed.

There are repos, such as the PEPs repo, where authors specify the
license on a per document basis (usually public domain) and
the Apache license required by the CLA is not one of those.

Having a CLA wouldn’t give the PSF any benefit, since most of
documents are without copyright anyway. However, it would make
contributing harder.

2 Likes
15

PSC and PSF hats: We’re going to get some clarification from legal council (Van) around which repos the CLA should or shouldn’t be applied and why.

Personal hat: If the PSF CLA isn’t appropriate for a software project, that suggests it doesn’t really fit the purpose of the GitHub /python/ org.

2 Likes
16

The CLA is needed for any software the PSF wants to redistribute under
a PSF open source license.

It’s not strictly needed for software / documentation which we only use
internally (e.g. infrastructure) or manage in a repo for informational
purposes (e.g. PEPs).

The CLA also doesn’t add any security. In its current form, the CLA
process doesn’t even require an email address, only a random Github
account, but that’s being discussed in another topic.

17

Brett replied:

How does a CLA increase security?

(I presume that “threat of being sued for copyright infringements” is considered a legal risk rather than a security issue.)

18

There was some confusion between CLA enforcement and 2FA enforcement. The latter increases security, but the former is what we’re talking about.

19

It doesn’t it. I believe you’re replying to a post that I deleted after I realized I misread “CLA” for “2FA”.

20

Just to be clear for others, It applies to outside collaborators, i.e. people explicitly added with particular permissions to one repository rather than the whole org, not all contributors, which generally makes sense and is much less problematic.

Yup, and so will git interactions, etc.

It seems while these are grandfathered in, the general desire would be to move them to the PSF org or their own org if possible?

In modern times, all PEPs are required to be “licensed” “public domain” (which isn’t really a proper license) and CC0 (which is, more or less), and almost all historical PEPs were at least “PD”, with a few very old exceptions (that are hopefully no longer relevant).

The PEPs repo has required the CLA for as long as I’ve been there (which admittedly, isn’t very long) and it hasn’t caused much of a problem, except for the serious bugs with the new bot that did cause major problems, blocking the work of one of our most active PEP editors, though they seem to be resolved now and hopefully won’t reoccur.

The “CLA” is really more of a DCO rather than assigning copyright interest to the PSF, like most CLAs do. The author still needs to establish copyright ownership and the right to contribute their work before they can add it and release it under the CC-0. Licensing Apache on ingest, I presume, provides some amount of patent protection, though IANAL.

I don’t really follow the argument here. Internal use of software to which one does not have a legitimate license to use is still illegal and incurs liability, if anyone but PSF employees that have a signed contract in place are contributing to them.

And I don’t understand the reasoning about the PEPs; they are no less copyrightable and publicly distributed than software, and arguably more so. If a user were to write a PEP, it get incorporated into the Python docs and formal specs, and then their employee claim ownership of it, or it turned out they got a significant chunk of it from someone else without permission, we’d be in big trouble.

21

The reason for CLAs is threefold:

  1. For anything that is going to be relicensed to the Python license, we need the right to do that. The CLA allows us to relicense to an OSI-approved license that is approved by the board. Currently only the Python license is approved generally, there are minor exceptions.
  2. The CLA specifies the terms of how people license-in their code (under the Apache license, generally). This gives us the right to use the code absent them putting a licensing declaration in each file or PR.
  3. The CLA protects Python/the PSF/all downstream users from a later accusation that an employee contributed to Python and was not allowed to do so. By having a document that should be reviewed by legal within an organization, we make sure that anyone contributing to Python has their org’s ok to do so.

For all of those wondering about CLA vs. DCO, item #3 is the biggest difference between them.

As for mypy and typeshed, IF those are being more formally incorporated into the Python distribution, we should move to a CLA for the reasons identified above.

If we are not incorporating them into Python… I don’t really understand why they are moving under the /python organization.

  • Van
4 Likes
22

Ah, I see—so the key distinction is procedural, as with the DCO, the contributor certifies they “have the right to submit it under the open source license”, but the PSF CLA ensures that is actually formally affirmed by the contributor’s employer, if relevant, so that it remains legally binding if the contributor has a legally enforceable employment contract that would otherwise assign copyright interest in their open source contributors to said employer.

Actually, the situation is in fact the opposite, as I understand it—they are currently under the python organization for historical reasons, whereas at least mypy would not belong in such under the new policy unless grandfathered in. The justification for typeshed staying in such seems to be that it contains the canonical type stubs for the standard library (though also third party libraries as well…). It might be prudent to get CLA coverage for at least the stdlib stubs, in case they are ever considered to be shipped with Python itself, etc.

1 Like