First complete draft of content.

pep-0541.txt

@@ -25,19 +25,194 @@ Rationale
 =========
 
 Given that package names on the Index are sharing a single flat
-namespace, a unique name is a finite resource.
+namespace, a unique name is a finite resource.  The growing age of
+the Package Index causes a constant rise of situations of conflict
+between the current use of the name and a different suggested use of
+the same name.
+
+This document aims to provide general guidelines for solving the
+most typical cases of such conflicts.
 
 
 Specification
 =============
 
-TBD.
+The main idea behind this document is that the Package Index serves the
+community.  Every user is invited to upload content to the Package Index
+under the Terms of Use, understanding that it is at the sole risk of
+the user.
+
+While the Package Index is not a backup service, the maintainers of the
+Package Index do their best to keep that content accessible indefinitely
+in its published form. However, in certain edge cases the greater
+community's needs might overweigh the individual's expectation of
+ownership of a package name.
+
+The use cases covered by this document are:
+
+* Abandoned projects:
+
+    * continued maintenance by a different set of users; or
+    * removal from the Index for use with a different project.
+
+* Active projects:
+
+    * resolving disputes over a name.
+
+* Invalid projects.
 
 
 Implementation
 ==============
 
-TBD.
+Reachability
+------------
+
+The user of the Package Index is solely responsible for being reachable
+by the Package Index maintainers for matters concerning projects that
+the user owns.  In every case where contacting the user is necessary,
+the maintainers will try to do so at least three times, using the
+following 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 project
+  uploaded to the Index; and
+* any e-mail addresses found in the given project's documentation
+  on the Index or on the listed Home Page.
+
+The maintainers stop trying to reach the user after six weeks.
+
+
+Abandoned projects
+------------------
+
+A project is considered *abandoned* 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 no
+  home page listed).
+
+All other projects are considered *active*.
+
+
+Continued maintenance of an abandoned project
+---------------------------------------------
+
+If a candidate appears willing to continue maintenance on an *abandoned*
+project, ownership of the name is transferred when ALL of the following
+are met:
+
+* the project has been determined *abandoned* by the rules described
+  above;
+* the candidate is able to prove failed attempts to contact the
+  existing owner;
+* the candidate is able to prove skin in the game (improvements made
+  on the candidate's own fork of the project);
+* the candidate is able to prove why a fork under a different name is
+  not an acceptable workaround; and
+* the maintainers of the Package Index don't have any additional
+  reservations.
+
+
+Removal of an abandoned project
+-------------------------------
+
+Projects are never removed from the Package Index solely on the basis
+of abandonment.  Artifacts uploaded to the Package Index hold inherent
+historical value.
+
+An *abandoned* project can be transferred to a new owner for purposes
+of reusing the name when ALL of the following are met:
+
+* the project has been determined *abandoned* by the rules described
+  above;
+* the candidate is able to prove failed attempts to contact the
+  existing owner;
+* the candidate is able to prove skin in the game (the other project
+  suggested to reuse the name already exists and meets notability
+  requirements);
+* the candidate is able to prove why a fork under a different name is
+  not an acceptable workaround;
+* download statistics on the Package Index for the existing package
+  indicate project is not being used; and
+* the maintainers of the Package Index don't have any additional
+  reservations.
+
+
+Name conflict resolution for active projects
+--------------------------------------------
+
+The maintainers of the Package Index are not arbiters in disputes
+around *active* projects.  There are many possible scenarios here,
+a non-exclusive list describing some real-world examples is presented
+below. None of the following qualify for package name ownership
+transfer:
+
+1. User A and User B share project X. After some time they part ways
+   and each of them wants to continue the project under name X.
+2. User A owns a project X outside the Package Index.  User B creates
+   a package under the name X on the Index.  After some time, User A
+   wants 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 the
+   User B's project X is not notable.
+3. User A publishes project X to the Package Index.  After some time
+   User B proposes bug fixes to the project but no new release is
+   published by User A.  This is true even if User A agrees to publish
+   a new version and later doesn't, even if User B's changes are merged
+   to the source code repository for project X.
+
+Again, the list above is not exclusive.  The maintainers of the Package
+Index recommend users to get in touch with each other and solve the
+issue by respectful communication (see the PSF Code of Conduct [6]_).
+
+
+Invalid projects
+----------------
+
+A project published on the Package Index meeting ANY of the following
+is 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);
+* project contains illegal content;
+* project violates copyright or licenses;
+* project is name squatting (package has no functionality or is
+  empty);
+* project name, description, or content violates the Code of Conduct;
+  or
+* project is abusing the Package Index for purposes it was not
+  intended.
+
+If you find a project that might be considered invalid, create
+a support request [7]_.
+
+
+Prior art
+=========
+
+NPM contains a separate section linked from the front page called
+`Package Name Disputes <https://www.npmjs.com/policies/disputes>`_.
+It is described as a "living document", as of January 2017 its
+contents might be summarized as follows:
+
+* package name squatting is prohibited;
+* users wanting to reuse a project name are required to contact the
+  existing author, with cc to support@npmjs.com;
+* all contact must conform to the NPM Code of Conduct;
+* in case of no resolution after a few weeks, npm inc. holds the right
+  to the final decision in the matter.
+
+CPAN lets any user upload modules with the same name. PAUSE, a related
+index, only lists modules uploaded by the primary maintainer or listed
+co-maintainers.  CPAN documentation doesn't address disputes otherwise.
+
+GitHub's terms of service contain an exhaustive list of behavior
+not meeting general conditions of use.  While not codified anywhere,
+GitHub does agree for users to reclaim abandoned account names by
+archiving the abandoned account and letting the other user or
+organization rename their account.  This is done on a case-by-case
+basis.
 
 
 Rejected Proposals
@@ -52,8 +227,6 @@ guidelines may appear arbitrary.  From the perspective of the Package
 Index maintainers, solving name conflicts is a stressful task due to
 risk of unintentional harm due to lack of defined policy.
 
-TBD.
-
 
 References
 ==========
@@ -73,6 +246,12 @@ References
 .. [5] GitHub
    (https://github.com/)
 
+.. [6] Python Community Code of Conduct
+   (https://www.python.org/psf/codeofconduct/)
+
+.. [7] PyPI Support Requests
+   (https://sourceforge.net/p/pypi/support-requests/)
+
 
 Copyright
 =========