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