Reachability

The user of the Package Index is solely responsible for being reachableby the Package Index maintainers for matters concerning projects thatthe user owns. In every case where contacting the user is necessary,the maintainers will try to do so at least three times, using thefollowing means of contact:

• the e-mail address on file in the user’s profile on the Package Index;
• the e-mail address listed in the Author field for a given projectuploaded to the Index; and
• any e-mail addresses found in the given project’s documentationon the Index or on the listed Home Page.

The maintainers stop trying to reach the user after six weeks.

Abandoned projects

A project is consideredabandoned when ALL of the following are met:

• owner not reachable (see Reachability above);
• no releases within the past twelve months; and
• no activity from the owner on the project’s home page (or nohome page listed).

All other projects are consideredactive.

Continued maintenance of an abandoned project

If a candidate appears willing to continue maintenance on anabandonedproject, ownership of the name is transferred when ALL of the followingare met:

• the project has been determinedabandoned by the rules describedabove;
• the candidate is able to demonstrate their own failed attempts to contactthe existing owner;
• the candidate is able to demonstrate improvements made on thecandidate’s own fork of the project;
• the candidate is able to demonstrate why a fork under a different nameis not an acceptable workaround; and
• the maintainers of the Package Index don’t have any additionalreservations.

Under no circumstances will a name be reassigned against the wishes ofa reachable owner.

Removal of an abandoned project

Projects are never removed from the Package Index solely on the basisof abandonment. Artifacts uploaded to the Package Index hold inherenthistorical value.

Anabandoned project can be transferred to a new owner for purposesof reusing the name when ALL of the following are met:

• the project has been determinedabandoned by the rules describedabove;
• the candidate is able to demonstrate their own failed attempts to contactthe existing owner;
• the candidate is able to demonstrate that the project suggested toreuse the name already exists and meets notability requirements;
• the candidate is able to demonstrate why a fork under a different nameis not an acceptable workaround;
• download statistics on the Package Index for the existing packageindicate project is not being used; and
• the maintainers of the Package Index don’t have any additionalreservations.

Name conflict resolution for active projects

The maintainers of the Package Index are not arbiters in disputesaroundactive projects. There are many possible scenarios here,a non-exclusive list describing some real-world examples is presentedbelow. None of the following qualify for package name ownershiptransfer:

1. User A and User B share project X. After some time they part waysand each of them wants to continue the project under name X.
2. User A owns a project X outside the Package Index. User B createsa package under the name X on the Index. After some time, User Awants to publish project X on the Index but realizes name is taken.This is true even if User A’s project X gains notability and theUser B’s project X is not notable.
3. User A publishes project X to the Package Index. After some timeUser B proposes bug fixes to the project but no new release ispublished by User A. This is true even if User A agrees to publisha new version and later doesn’t, even if User B’s changes are mergedto the source code repository for project X.

Again, the list above is not exclusive. The maintainers of the PackageIndex recommend users to get in touch with each other and solve theissue by respectful communication (see the PSF Code of Conduct[6]).

Invalid projects

A project published on the Package Index meeting ANY of the followingis considered invalid and will be removed from the Index:

• project does not conform to Terms of Use;
• project is malware (designed to exploit or harm systems or users directly, tofacilitate command-and-control attacks, or perform data exfiltration);
• project is spam (designed to advertise or solicit goods or services);
• project contains illegal content;
• project violates copyright, trademarks, patents, or licenses;
• project is name squatting (package has no functionality or isempty);
• project name, description, or content violates the Code of Conduct;
• project uses obfuscation to hide or mask functionality;or
• project is abusing the Package Index for purposes it was notintended.

The Package Index maintainers pre-emptively declare certain packagenames as unavailable for security reasons.

Intellectual property policy

It is the policy of Python Software Foundation and the Package Indexmaintainers to be appropriately responsive to claims of intellectualproperty infringement by third parties. It is not the policy ofthe Python Software Foundation nor the Package Index maintainersto pre-screen uploaded packages for any type of intellectual propertyinfringement.

Possibly-infringing packages should be reported tolegal@python.organd counsel to the Python Software Foundation will determine anappropriate response. A package can be removed or transferred to anew owner at the sole discretion of the Python Software Foundation toaddress a claim of infringement.

A project published on the Package Index meeting ANY of the followingmay be considered infringing and subject to removal from the Indexor transferral to a new owner:

• project contains unlicensed copyrighted material from a third party,and is subject to a properly made claim under the DMCA;
• project uses a third party’s trademark in a way not covered bynominal or fair use guidelines;
• project clearly implicates a patented system or process, and isthe subject of a complaint; or
• project is subject to an active lawsuit.

In the event of a complaint for intellectual property infringement,a copy of the complaint will be sent to the package owner. In somecases, action may be taken by the Package Index maintainers beforethe owner responds.

The role of the Python Software Foundation

The Python Software Foundation[7] is the non-profit legal entity thatprovides the Package Index as a community service.

The Package Index maintainers can escalate issues covered by thisdocument for resolution by the Packaging Workgroup if the matter is not clearenough. Some decisionsrequire additional judgement by the Board,especially in cases of Code of Conduct violations or legal claims.Recommendations made by the Board are sent to the Packaging Workgroup[8] for review.

The Packaging Workgroup has the final say in any disputes covered by this document andcan decide to reassign or remove a project from the Package Index aftercareful consideration even when not all requirements listedhere are met.