Regarding reachability: contact attempts should also include the relevant project's issue tracker if attempts at private contact have failed.
This step is important as it allows a project's *user* community to respond, even if the person that actually pushes the buttons to upload new releases to PyPI is out of contact for some reason. On 14 January 2017 at 05:13, M.-A. Lemburg <m...@egenix.com> wrote: > Likewise, a trademark owner should be able to reserve project > names with the trademark to avoid any such issues to begin with, > e.g. https://pypi.python.org/pypi/Python is such a project :-) We also have at least one case where we've reserved a name indefinitely because it's shipped as part of another popular project. Specifically, Donald is the owner of pkg_resources so we can ensure that "pip install pkg_resources" is an error, rather than silently installing the wrong thing. The only projects we'd release that name for are either setuptools splitting out pkg_resources as a separately installable component, or else a shim endorsed by Jason as the lead setuptools maintainer that installed setuptools as a dependency (see https://github.com/ncoghlan/pkg_resources_shim/issues/1 for discussion). >From a policy perspective, I think the kind of phrasing I'd be looking for would be to say that the PyPI maintainers may pre-emptively declare particular project names invalid for security reasons. That would not only cover pkg_resources specifically, but also things like the name normalisation scheme that prevents the use of names that are deemed "the same as" (as defined by the regex in PEP 508), or "confusable with" (as defined by the Unicode Consortium), existing registered names. >> * 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]_. > > It would also be good to add some wording which makes it clear > that the PSF Board has the final say in any disputes and can > have a project removed/reassigned after careful consideration > even when not meeting all the requirements listed in the PEP. > > As an example, the last two bullets you mention above will > often be subject to additional judgement. The board would then have > to decide these on a case-by-case basis. Right, explicitly mentioning the role of the PSF in the process was going to be my suggestion as well. I think there are a few key aspects of that which should be mentioned: - the Python Software Foundation is the legal entity ultimately responsible for providing the Python Packaging Index as a community service - the PyPI maintainers can always escalate name retention and transfer questions to the PSF Board for discussion and resolution if they're not clear on an appropriate course of action - third parties may escalate name retention and transfer concerns to the PSF Board if they have a sincere belief that an issue's resolution is contrary to the documented policy - issues involving legal claims (copyright disputes, trademark disputes, patent claims, unauthorized disclosure claims) MUST be escalated to the Board for review by the PSF's General Counsel And as with any other changes to the PyPI terms of service, changes to the project name retention and transfer policy must be approved by the Foundation (whether that's through the General Counsel's sign-off, or through a Board resolution would be for the Board to determine, it doesn't need to be part of the policy) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
