Skip to content

Commit 5f7e35c

Browse files
user-docs: import PEP 541 policy as a page (#18793)
Signed-off-by: William Woodruff <[email protected]> Co-authored-by: Mike Fiedler <[email protected]>
1 parent 894713e commit 5f7e35c

File tree

2 files changed

+221
-0
lines changed

2 files changed

+221
-0
lines changed

docs/mkdocs-user-docs.yml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -73,6 +73,7 @@ nav:
7373
- "Project Management":
7474
- "project-management/storage-limits.md"
7575
- "project-management/yanking.md"
76+
- "project-management/name-retention.md"
7677
- "Organization Accounts":
7778
- "organization-accounts/index.md"
7879
- "organization-accounts/org-acc-faq.md"
Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
1+
---
2+
source: https://peps.python.org/pep-0541/
3+
title: Name Retention
4+
---
5+
6+
# Name Retention
7+
8+
!!! note
9+
10+
This page contains the policy components [PEP 541]. The procedural
11+
components of the PEP (Abstract, Rationale, etc.) have been omitted
12+
from this page, but can be found in the PEP itself.
13+
14+
[PEP 541]: https://peps.python.org/pep-0541/
15+
16+
## Specification
17+
18+
The main idea behind this document is that the Package Index serves the
19+
community. Every user is invited to upload content to the Package Index under
20+
the Terms of Use, understanding that it is at the sole risk of the user.
21+
22+
While the Package Index is not a backup service, the maintainers of the Package
23+
Index do their best to keep that content accessible indefinitely in its
24+
published form. However, in certain edge cases the greater community’s needs
25+
might overweigh the individual’s expectation of ownership of a package name.
26+
27+
The use cases covered by this document are:
28+
29+
- Abandoned projects:
30+
- continued maintenance by a different set of users; or
31+
- removal from the Index for use with a different project.
32+
- Active projects:
33+
- resolving disputes over a name.
34+
- Invalid projects:
35+
- projects subject to a claim of intellectual property infringement.
36+
- The proposed extension to the Terms of Use, as expressed in the
37+
Implementation section, will be published as a separate document on the
38+
Package Index, linked next to existing Terms of Use in the front page
39+
footer.
40+
41+
## Implementation
42+
43+
### Reachability
44+
45+
The user of the Package Index is solely responsible for being reachable by the
46+
Package Index maintainers for matters concerning projects that the user owns. In
47+
every case where contacting the user is necessary, the maintainers will try to
48+
do so at least three times, using the following means of contact:
49+
50+
- the e-mail address on file in the user’s profile on the Package Index;
51+
- the e-mail address listed in the Author field for a given project uploaded to
52+
the Index; and
53+
- any e-mail addresses found in the given project’s documentation on the Index
54+
or on the listed Home Page.
55+
56+
The maintainers stop trying to reach the user after six weeks.
57+
58+
### Abandoned projects
59+
60+
A project is considered _abandoned_ when ALL of the following are met:
61+
62+
- owner not reachable (see Reachability above);
63+
- no releases within the past twelve months; and
64+
- no activity from the owner on the project’s home page (or no home page
65+
listed).
66+
67+
All other projects are considered active.
68+
69+
### Continued maintenance of an abandoned project
70+
71+
If a candidate appears willing to continue maintenance on an _abandoned_
72+
project, ownership of the name is transferred when ALL of the following are met:
73+
74+
- the project has been determined _abandoned_ by the rules described above;
75+
- the candidate is able to demonstrate their own failed attempts to contact the
76+
existing owner;
77+
- the candidate is able to demonstrate improvements made on the candidate’s own
78+
fork of the project;
79+
- the candidate is able to demonstrate why a fork under a different name is not
80+
an acceptable workaround; and
81+
- the maintainers of the Package Index don’t have any additional reservations.
82+
83+
Under no circumstances will a name be reassigned against the wishes of a
84+
reachable owner.
85+
86+
### Removal of an abandoned project
87+
88+
Projects are never removed from the Package Index solely on the basis of
89+
abandonment. Artifacts uploaded to the Package Index hold inherent historical
90+
value.
91+
92+
An _abandoned_ project can be transferred to a new owner for purposes of reusing
93+
the name when ALL of the following are met:
94+
95+
- the project has been determined abandoned by the rules described above;
96+
- the candidate is able to demonstrate their own failed attempts to contact the
97+
existing owner;
98+
- the candidate is able to demonstrate that the project suggested to reuse the
99+
name already exists and meets notability requirements;
100+
- the candidate is able to demonstrate why a fork under a different name is not
101+
an acceptable workaround; download statistics on the Package Index for the
102+
existing package indicate project is not being used; and
103+
- the maintainers of the Package Index don’t have any additional reservations.
104+
105+
### Name conflict resolution for active projects
106+
107+
The maintainers of the Package Index are not arbiters in disputes around
108+
_active_ projects. There are many possible scenarios here, a non-exclusive list
109+
describing some real-world examples is presented below. None of the following
110+
qualify for package name ownership transfer:
111+
112+
- User A and User B share project X. After some time they part ways and each of
113+
them wants to continue the project under name X.
114+
- User A owns a project X outside the Package Index. User B creates a package
115+
under the name X on the Index. After some time, User A wants to publish
116+
project X on the Index but realizes name is taken. This is true even if User
117+
A’s project X gains notability and the User B’s project X is not notable.
118+
- User A publishes project X to the Package Index. After some time User B
119+
proposes bug fixes to the project but no new release is published by User A.
120+
This is true even if User A agrees to publish a new version and later doesn’t,
121+
even if User B’s changes are merged to the source code repository for project
122+
X.
123+
124+
Again, the list above is not exclusive. The maintainers of the Package Index
125+
recommend users to get in touch with each other and solve the issue by
126+
respectful communication (see the [PSF Code of Conduct]).
127+
128+
[PSF Code of Conduct]: ../python.org/code-of-conduct/index.md
129+
130+
### Invalid projects
131+
132+
A project published on the Package Index meeting ANY of the following is
133+
considered invalid and will be removed from the Index:
134+
135+
- project does not conform to Terms of Use;
136+
- project is malware (designed to exploit or harm systems or users directly, to
137+
facilitate command-and-control attacks, or perform data exfiltration);
138+
- project is spam (designed to advertise or solicit goods or services);
139+
- project contains illegal content;
140+
- project violates copyright, trademarks, patents, or licenses;
141+
- project is name squatting (package has no functionality or is empty);
142+
- project name, description, or content violates the Code of Conduct;
143+
- project uses obfuscation to hide or mask functionality; or
144+
- project is abusing the Package Index for purposes it was not intended.
145+
146+
The Package Index maintainers pre-emptively declare certain package names as
147+
unavailable for security reasons.
148+
149+
### Intellectual property policy
150+
151+
It is the policy of Python Software Foundation and the Package Index maintainers
152+
to be appropriately responsive to claims of intellectual property infringement
153+
by third parties. It is not the policy of the Python Software Foundation nor the
154+
Package Index maintainers to pre-screen uploaded packages for any type of
155+
intellectual property infringement.
156+
157+
Possibly-infringing packages should be reported to [[email protected]] and
158+
counsel to the Python Software Foundation will determine an appropriate
159+
response. A package can be removed or transferred to a new owner at the sole
160+
discretion of the Python Software Foundation to address a claim of infringement.
161+
162+
163+
164+
A project published on the Package Index meeting ANY of the following may be
165+
considered infringing and subject to removal from the Index or transferral to a
166+
new owner:
167+
168+
- project contains unlicensed copyrighted material from a third party, and is
169+
subject to a properly made claim under the DMCA;
170+
- project uses a third party’s trademark in a way not covered by nominal or fair
171+
use guidelines;
172+
- project clearly implicates a patented system or process, and is the subject of
173+
a complaint; or
174+
- project is subject to an active lawsuit.
175+
176+
In the event of a complaint for intellectual property infringement, a copy of
177+
the complaint will be sent to the package owner. In some cases, action may be
178+
taken by the Package Index maintainers before the owner responds.
179+
180+
### The role of the Python Software Foundation
181+
182+
The [Python Software Foundation] is the non-profit legal entity that provides
183+
the Package Index as a community service.
184+
185+
[Python Software Foundation]: https://www.python.org/psf/
186+
187+
The Package Index maintainers can escalate issues covered by this document for
188+
resolution by the Packaging Workgroup if the matter is not clear enough. Some
189+
decisions require additional judgement by the Board, especially in cases of Code
190+
of Conduct violations or legal claims. Recommendations made by the Board are
191+
sent to the [Packaging Workgroup] for review.
192+
193+
[Packaging Workgroup]: https://wiki.python.org/psf/PackagingWG/
194+
195+
The Packaging Workgroup has the final say in any disputes covered by this
196+
document and can decide to reassign or remove a project from the Package Index
197+
after careful consideration even when not all requirements listed here are met.
198+
199+
### How to request a name transfer
200+
201+
If you want to take over an existing project name on PyPI, these are the steps
202+
to follow:
203+
204+
- Try to contact the current owner(s) directly: email them and open an issue if
205+
you can find a related repository. The processes described here are meant as a
206+
last resort if the owner cannot be contacted.
207+
- Check the criteria above to see when a transfer is allowed. In particular, the
208+
criteria for [reusing a name for a different project] are more stringent than
209+
for [continuing maintenance of the same project] - although it’s not easy to
210+
get a name transferred in either case.
211+
- Search the [PyPI Support issues] to see if anyone else is already requesting
212+
the same name.
213+
- If all the criteria are met to transfer ownership of the name,
214+
[open a new issue] to request it, detailing why you believe each relevant
215+
criterion is satisfied.
216+
217+
[reusing a name for a different project]: #removal-of-an-abandoned-project
218+
[continuing maintenance of the same project]: #continued-maintenance-of-an-abandoned-project
219+
[PyPI Support issues]: https://github.com/pypa/pypi-support/issues
220+
[open a new issue]: https://github.com/pypa/pypi-support/issues/new?labels=PEP+541&template=pep541-request.yml&title=PEP+541+Request%3A+PROJECT_NAME

0 commit comments

Comments
 (0)