RFC: PEP 541 - Package Index Name Retention
Hello distutils-sig, I'd like to get some comments on this. I was asked by Donald to work on it. It removes ambiguity from some of the situations that crop up increasingly often with regards to package names on the PyPI. Looking forward to hearing what you have to say! - Ł PEP: 541 Title: Package Index Name Retention Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa <lukasz@langa.pl> Status: Draft Type: Process Content-Type: text/x-rst Created: 12-January-2017 Abstract ======== This PEP proposes an extension to the Terms of Use [1]_ of the Package Index [2]_, clarifying expectations of package owners regarding ownership of a package name on the Package Index, specifically with regards to conflict resolution. Existing package repositories such as CPAN [3]_, NPM [4]_, and GitHub [5]_ will be investigated as prior art in this field. Rationale ========= Given that package names on the Index are sharing a single flat 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 ============= 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 ============== 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 demonstrate own failed attempts to contact the existing owner; * the candidate is able to demonstrate skin in the game (improvements made on the candidate's own fork of the project); * the candidate is able to demonstrate 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. Under no circumstances will a name be reassigned against the wishes of a reachable owner. 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 demonstrate own failed attempts to contact the existing owner; * the candidate is able to demonstrate skin in the game (the other project suggested to reuse the name already exists and meets notability requirements); * the candidate is able to demonstrate 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 ================== The original approach was to hope for the best and solve issues as they arise without written policy. This is not sustainable. The lack of generally available guidelines in writing on package name conflict resolution is causing unnecessary tensions. From the perspective of users, decisions made by the Package Index maintainers without written 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. References ========== .. [1] Terms of Use of the Python Package Index (https://pypi.org/policy/terms-of-use/) .. [2] The Python Package Index (https://pypi.python.org/) .. [3] The Comprehensive Perl Archive Network (http://www.cpan.org/) .. [4] Node Package Manager (https://www.npmjs.com/package/left-pad) .. [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 ========= This document has been placed in the public domain. Acknowledgements ================ The many participants of the Distutils and Catalog SIGs for their ideas over the years. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:
+1 on the proposal. I would suggest to state where it is posted (somewhere obvious) on pypi, and possibly some kind of automated notification to pypi uploaders be provided about the new policy. On Fri, Jan 13, 2017 at 10:08 AM, Lukasz Langa <lukasz@langa.pl> wrote:
Hello distutils-sig, I'd like to get some comments on this. I was asked by Donald to work on it. It removes ambiguity from some of the situations that crop up increasingly often with regards to package names on the PyPI. Looking forward to hearing what you have to say! - Ł
PEP: 541 Title: Package Index Name Retention Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa <lukasz@langa.pl> Status: Draft Type: Process Content-Type: text/x-rst Created: 12-January-2017
Abstract ========
This PEP proposes an extension to the Terms of Use [1]_ of the Package Index [2]_, clarifying expectations of package owners regarding ownership of a package name on the Package Index, specifically with regards to conflict resolution.
Existing package repositories such as CPAN [3]_, NPM [4]_, and GitHub [5]_ will be investigated as prior art in this field.
Rationale =========
Given that package names on the Index are sharing a single flat 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 =============
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 ==============
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 demonstrate own failed attempts to contact the existing owner; * the candidate is able to demonstrate skin in the game (improvements made on the candidate's own fork of the project); * the candidate is able to demonstrate 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.
Under no circumstances will a name be reassigned against the wishes of a reachable owner.
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 demonstrate own failed attempts to contact the existing owner; * the candidate is able to demonstrate skin in the game (the other project suggested to reuse the name already exists and meets notability requirements); * the candidate is able to demonstrate 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 ==================
The original approach was to hope for the best and solve issues as they arise without written policy. This is not sustainable. The lack of generally available guidelines in writing on package name conflict resolution is causing unnecessary tensions. From the perspective of users, decisions made by the Package Index maintainers without written 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.
References ==========
.. [1] Terms of Use of the Python Package Index (https://pypi.org/policy/terms-of-use/)
.. [2] The Python Package Index (https://pypi.python.org/)
.. [3] The Comprehensive Perl Archive Network (http://www.cpan.org/)
.. [4] Node Package Manager (https://www.npmjs.com/package/left-pad)
.. [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 =========
This document has been placed in the public domain.
Acknowledgements ================
The many participants of the Distutils and Catalog SIGs for their ideas over the years.
.. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- cordially, Anna
On 01/13/2017 10:08 AM, Lukasz Langa wrote:
I'd like to get some comments on this. I was asked by Donald to work on it. It removes ambiguity from some of the situations that crop up increasingly often with regards to package names on the PyPI. Looking forward to hearing what you have to say!
Overall looks great. I would suggest removing slang, such as "skin in the game". Thanks for working on this! -- ~Ethan~
Looks great to me. Just a few comments that may help reduce the burden on the index maintainers. On 13Jan2017 1008, Lukasz Langa wrote:
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.
I don't see any reason to expect the index maintainers to trawl through a project's documentation or home page to find contact details. There are more than enough ways to provide it on the index, and as far as I'm concerned, no reason for uploaders to not provide one.
An *abandoned* project can be transferred to a new owner for purposes of reusing the name when ALL of the following are met: ...
The list here is nearly identical to the previous section, apart from the added data point of download count (which is good!), and it's not clear on reading why we need to list these twice.
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 is name squatting (package has no functionality or is empty); ... If you find a project that might be considered invalid, create a support request [7]_.
I would actually like to be able to name-squat for a period between a project being started and being released (particularly in my own context, I often need to keep a project private until it has been internally tested/reviewed/scanned and the lawyers have signed off, at which point it may require a new review if the name has to change). Presumably for a reachable uploader who can give an explanation, this won't result in the immediate loss of the name. But suggesting a time limit may help reduce support requests ("project is name squatting for at least 6 months" feels okay to me, but not wedded to it). (As a semi-related aside, I'm currently squatting on the 'microsoft' and 'windows' packages for trademark protection reasons. They may never get any functionality, but that's better than someone else having the name. This sort of squatting doesn't necessarily need to be explicitly called out in policy, but maybe it's worth a mention?) Cheers, Steve
Thanks for review, Steve!
On Jan 13, 2017, at 10:35 AM, Steve Dower <steve.dower@python.org> wrote:
I don't see any reason to expect the index maintainers to trawl through a project's documentation or home page to find contact details. There are more than enough ways to provide it on the index, and as far as I'm concerned, no reason for uploaders to not provide one.
The reason of this is courtesy towards existing package owners who might not have conformed to the Author e-mail requirement because it wasn't explicitly formulated. I think the maintainers would try their best to reach the owner anyway, just to be sure there won't be any harm caused by changes.
An *abandoned* project can be transferred to a new owner for purposes of reusing the name when ALL of the following are met: ...
The list here is nearly identical to the previous section
The "skin in the game" behavior is different.
it's not clear on reading why we need to list these twice.
It's a different case and I want to limit back-and-forth required by the readers (which is already necessary to parse the rules for abandoned projects).
I would actually like to be able to name-squat for a period between a project being started and being released (particularly in my own context, I often need to keep a project private until it has been internally tested/reviewed/scanned and the lawyers have signed off, at which point it may require a new review if the name has to change).
Presumably for a reachable uploader who can give an explanation, this won't result in the immediate loss of the name. But suggesting a time limit may help reduce support requests ("project is name squatting for at least 6 months" feels okay to me, but not wedded to it).
I don't want to suggest arbitrary limits on acceptable name squatting because this can be abused. As long as you squat and nobody calls you out on it before your first functional release, that's okay. If you squat on a great name and somebody comes along with an existing notable project wanting that name, the case it rather clear though.
(As a semi-related aside, I'm currently squatting on the 'microsoft' and 'windows' packages for trademark protection reasons. They may never get any functionality, but that's better than someone else having the name. This sort of squatting doesn't necessarily need to be explicitly called out in policy, but maybe it's worth a mention?)
I wanted to avoid touching on trademark issues because IANAL. - Ł
On 13Jan2017 1050, Lukasz Langa wrote:
Thanks for review, Steve!
On Jan 13, 2017, at 10:35 AM, Steve Dower <steve.dower@python.org> wrote:
An *abandoned* project can be transferred to a new owner for purposes of reusing the name when ALL of the following are met: ...
The list here is nearly identical to the previous section
The "skin in the game" behavior is different.
Fair enough. Perhaps we should avoid using the idiom though (as suggested earlier) to avoid any potential loss in translation.
I would actually like to be able to name-squat for a period between a project being started and being released (particularly in my own context, I often need to keep a project private until it has been internally tested/reviewed/scanned and the lawyers have signed off, at which point it may require a new review if the name has to change).
Presumably for a reachable uploader who can give an explanation, this won't result in the immediate loss of the name. But suggesting a time limit may help reduce support requests ("project is name squatting for at least 6 months" feels okay to me, but not wedded to it).
I don't want to suggest arbitrary limits on acceptable name squatting because this can be abused. As long as you squat and nobody calls you out on it before your first functional release, that's okay. If you squat on a great name and somebody comes along with an existing notable project wanting that name, the case it rather clear though.
So perhaps name-squatting belongs in the "this project is abandoned and I want the name" section rather than the "this project is invalid and I'm flagging it via support channels" section? (Or maybe I misunderstood the intent of the separate sections, which I'm sure is also useful feedback :) )
(As a semi-related aside, I'm currently squatting on the 'microsoft' and 'windows' packages for trademark protection reasons. They may never get any functionality, but that's better than someone else having the name. This sort of squatting doesn't necessarily need to be explicitly called out in policy, but maybe it's worth a mention?)
I wanted to avoid touching on trademark issues because IANAL.
Very good point. Since nobody directly involved in this policy is a lawyer, it might be worth clearly stating what the index maintainers are responsible for in the case of a potential legal dispute with an unreachable package owner, or one who is deliberately/maliciously making themselves unreachable. Or maybe it's a rare enough case that it doesn't matter? We certainly resolved our last issue easily enough, though it did require the index maintainers to put us in direct contact with the package owner. Maybe stating that "the index maintainers are not responsible for evaluating the legal status of intellectual property, and may only establish direct contact between the complainant and a reachable package owner with mutual consent" is the way to go? (And get VanL to sign off on the wording, just in case there's some oddity here I'm not aware of.) Cheers, Steve
On 13.01.2017 19:08, Lukasz Langa wrote:
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;
This probably also needs to list "trademarks" and "patents", as we've already had some cases where packages were violating trademarks/patents and had to be removed (not only regarding the name of the package but also regarding contents of the package or functionality). This is already mentioned in the current terms, but better make it more explicit here as well. 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 :-)
* 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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 13 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
This is a great PEP, glad to see an official policy being worked on! The "reachability" criteria I think should define how promptly the responses are expected and to what email(s) they will be sent (if there are multiple maintainers, owners, authors, etc.). For example, "the first contact will be sent to the email on record for all owners, maintainers, and the most-recent release author, in order to notify the user(s) that another party has requested classification of a PyPI project owned or maintained by the user as abandoned, and that if no response is received by (date of email + 6 weeks), it will be deemed abandoned. Reminder emails will be sent 2 and 4 weeks later." Maybe outside the scope of the PEP, but where will the tracker for these things reside? How would I, for example, start the process of flagging a project as abandoned? On Fri, Jan 13, 2017 at 1:13 PM, M.-A. Lemburg <mal@egenix.com> wrote:
On 13.01.2017 19:08, Lukasz Langa wrote:
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;
This probably also needs to list "trademarks" and "patents", as we've already had some cases where packages were violating trademarks/patents and had to be removed (not only regarding the name of the package but also regarding contents of the package or functionality). This is already mentioned in the current terms, but better make it more explicit here as well.
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 :-)
* 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.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jan 13 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Regarding name-squatting (I also see htc, ios, apple, android, angular, debian and more registered on PyPI), would a better solution be a way to "salt" names on PyPI making them unable to be registered unless someone files an issue to claim such hot-button trademarks? On Fri, Jan 13, 2017 at 2:34 PM, Nick Timkovich <prometheus235@gmail.com> wrote:
This is a great PEP, glad to see an official policy being worked on!
The "reachability" criteria I think should define how promptly the responses are expected and to what email(s) they will be sent (if there are multiple maintainers, owners, authors, etc.). For example, "the first contact will be sent to the email on record for all owners, maintainers, and the most-recent release author, in order to notify the user(s) that another party has requested classification of a PyPI project owned or maintained by the user as abandoned, and that if no response is received by (date of email + 6 weeks), it will be deemed abandoned. Reminder emails will be sent 2 and 4 weeks later."
Maybe outside the scope of the PEP, but where will the tracker for these things reside? How would I, for example, start the process of flagging a project as abandoned?
On Fri, Jan 13, 2017 at 1:13 PM, M.-A. Lemburg <mal@egenix.com> wrote:
On 13.01.2017 19:08, Lukasz Langa wrote:
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;
This probably also needs to list "trademarks" and "patents", as we've already had some cases where packages were violating trademarks/patents and had to be removed (not only regarding the name of the package but also regarding contents of the package or functionality). This is already mentioned in the current terms, but better make it more explicit here as well.
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 :-)
* 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.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jan 13 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 <mal@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 | ncoghlan@gmail.com | Brisbane, Australia
On Jan 13, 2017, at 10:08 AM, Lukasz Langa wrote:
PEP: 541 Title: Package Index Name Retention
Overall, +1 I agree with Steve that some short term name squatting may be appropriate. I'm not sure how you would word that in the PEP, but it will probably effectively work itself out anyway. When I come up with a name for a new project, one of the first things I do is check PyPI and reserve it before the first upload. But that first upload will usually happen pretty quickly.
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:
This is another opportunity to encourage cooperation among the parties to resolve naming conflicts. I think that's what's called for by the CoC, and the hope is that the vast majority of disputes (in practice which I think are pretty rare anyway) can be amicably resolved. It does bring to mind the ability or lack thereof for renaming projects. IIRC that's not possible in current PyPI software but it may be possible in Warehouse. As for trademark owners having priority over names, I suppose there's no way to prevent that, I'm mostly glad that this PEP doesn't speak to that. I'm always edgy about the imbalance of power inherent in the issue, allowing a trademark owner to abuse their power to take over long-established names. OTOH, trademark owners do often have legitimate concerns against squatters. So, I say leave all that out of the PEP. Cheers, -Barry
On 13/01/17 19:08, Lukasz Langa wrote:
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 is name squatting (package has no functionality or is empty);
[...] Greetings, I'd like to clarify a certain aspect that I reckon is not covered by the PEP yet. There are several packages on PyPI in the 'zato' namespace, such as: https://pypi.python.org/pypi/zato https://pypi.python.org/pypi/zato-enclog https://pypi.python.org/pypi/zato-apitest Naturally, this is a namespace by convention only and on top of that, one will note that the first link is a 404. The PyPI package 'zato' does exist but it does not have any release. This is on purpose. The reason is that although Zato is written mostly in Python, we are not planning to make it available on PyPI instead opting to provide binary system packages, including installers for Docker or AWS Elastic Beanstalk, simply because the installers perform a lot of tasks that are outside of pip's scope: https://zato.io/docs/admin/guide/install/index.html However, there was a case when a third party registered the 'zato' package in PyPI simply because they thought it a cool idea. This caused confusion among prospective Zato users who expected to find software that had never been uploaded to PyPI by its developers. In the end the third party handed the PyPI package off and everything was resolved amicably but I'm now worried this can happen again. In particular, I worry that an eager contributor will eventually author a script that will find all the packages considered invalid per PEP 541, they will be deleted and someone else will register 'zato' again and unfortunately this will cause commotion on our end again. It happened before thus it's not a hypothetical scenario. And perhaps this time the third party will be less inclined to cooperate so even more time will be wasted until the situation is resolved. Short of adding namespaces to PyPI/Warehouse, I'm wondering how this can be prevented. Can there be added a clause to the PEP that only packages whose existence cannot be explain away in email by their maintainers be considered invalid in case of packages with no functionality nor contents? I realize that this adds to the PyPI's maintainers workload which was to be lessened thanks to this PEP but I'm honestly worried that as it stands now, the PEP does not cover this particular use-case that I'm concerned about. Essentially, this is preventive squatting for the greater good, so to speak, by people who are actually entitled to do it and who would be doing it anyway if namespaces were available. kind regards, -- Dariusz Suchojad https://zato.io ESB, SOA, REST, APIs and Cloud Integrations in Python
If you have a non-release release with some description text and a home-page that points to where active development is going on (that could constitute "functionality" in a non-code way), I think that should preempt a reasonable person (which is hopefully a superset of maintainers) from deleting it. On Mon, Jan 16, 2017 at 3:02 PM, Dariusz Suchojad <dsuch@zato.io> wrote:
On 13/01/17 19:08, Lukasz Langa wrote:
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 is name squatting (package has no functionality or is empty);
[...]
Greetings,
I'd like to clarify a certain aspect that I reckon is not covered by the PEP yet.
There are several packages on PyPI in the 'zato' namespace, such as:
https://pypi.python.org/pypi/zato https://pypi.python.org/pypi/zato-enclog https://pypi.python.org/pypi/zato-apitest
Naturally, this is a namespace by convention only and on top of that, one will note that the first link is a 404. The PyPI package 'zato' does exist but it does not have any release. This is on purpose.
The reason is that although Zato is written mostly in Python, we are not planning to make it available on PyPI instead opting to provide binary system packages, including installers for Docker or AWS Elastic Beanstalk, simply because the installers perform a lot of tasks that are outside of pip's scope:
https://zato.io/docs/admin/guide/install/index.html
However, there was a case when a third party registered the 'zato' package in PyPI simply because they thought it a cool idea. This caused confusion among prospective Zato users who expected to find software that had never been uploaded to PyPI by its developers. In the end the third party handed the PyPI package off and everything was resolved amicably but I'm now worried this can happen again.
In particular, I worry that an eager contributor will eventually author a script that will find all the packages considered invalid per PEP 541, they will be deleted and someone else will register 'zato' again and unfortunately this will cause commotion on our end again. It happened before thus it's not a hypothetical scenario. And perhaps this time the third party will be less inclined to cooperate so even more time will be wasted until the situation is resolved.
Short of adding namespaces to PyPI/Warehouse, I'm wondering how this can be prevented. Can there be added a clause to the PEP that only packages whose existence cannot be explain away in email by their maintainers be considered invalid in case of packages with no functionality nor contents? I realize that this adds to the PyPI's maintainers workload which was to be lessened thanks to this PEP but I'm honestly worried that as it stands now, the PEP does not cover this particular use-case that I'm concerned about.
Essentially, this is preventive squatting for the greater good, so to speak, by people who are actually entitled to do it and who would be doing it anyway if namespaces were available.
kind regards,
-- Dariusz Suchojad
https://zato.io ESB, SOA, REST, APIs and Cloud Integrations in Python
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 16/01/17 22:19, Nick Timkovich wrote:
If you have a non-release release with some description text and a home-page that points to where active development is going on (that could constitute "functionality" in a non-code way), I think that should preempt a reasonable person (which is hopefully a superset of maintainers) from deleting it.
Yes, indeed, this is what I'd like to clarify. Someone is simply bound to clean up all the packages at one point and this PEP likely will be the basis for deciding what to delete or not so I'd very much like to ensure ours will not be removed. regards, -- Dariusz Suchojad https://zato.io ESB, SOA, REST, APIs and Cloud Integrations in Python
So, this proposition didn't really make sense to me. Folk like Linux distros will want the source, and you don't need to upload wheels :- setup.py could quite reasonably limit itself to software installation, vs configuration. Plenty of pip installable packages are not entirely ready to use after pip installation. -Rob On 17 Jan 2017 08:29, "Dariusz Suchojad" <dsuch@zato.io> wrote:
If you have a non-release release with some description text and a home-page that points to where active development is going on (that could constitute "functionality" in a non-code way), I think that should
On 16/01/17 22:19, Nick Timkovich wrote: preempt
a reasonable person (which is hopefully a superset of maintainers) from deleting it.
Yes, indeed, this is what I'd like to clarify. Someone is simply bound to clean up all the packages at one point and this PEP likely will be the basis for deciding what to delete or not so I'd very much like to ensure ours will not be removed.
regards,
-- Dariusz Suchojad
https://zato.io ESB, SOA, REST, APIs and Cloud Integrations in Python
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 16/01/17 23:10, Robert Collins wrote:
So, this proposition didn't really make sense to me. Folk like Linux distros will want the source, and you don't need to upload wheels :- setup.py could quite reasonably limit itself to software installation, vs configuration. Plenty of pip installable packages are not entirely ready to use after pip installation.
Hi Robert, I'm not clear if this was meant in reply to my email? I'm genuinely perplexed. I just don't know how to relate it to the suggestion I made in this message: https://mail.python.org/pipermail/distutils-sig/2017-January/030015.html There are several sub-threads in this discussion and I'm not quite sure what you mean. regards, -- Dariusz Suchojad https://zato.io ESB, SOA, REST, APIs and Cloud Integrations in Python
Yep, this is what I chose to do for our packages like https://pypi.org/project/microsoft/ (updated since I first posted about it). The intent of this PEP is to be able to clean up *unmaintained* packages, so if you have an "invalid" package but also a justification and you are reachable, I expect there should be no issues. Top-posted from my Windows Phone -----Original Message----- From: "Dariusz Suchojad" <dsuch@zato.io> Sent: 1/16/2017 13:29 To: "Distutils-Sig@Python.Org" <Distutils-Sig@Python.Org> Subject: Re: [Distutils] RFC: PEP 541 - Package Index Name Retention On 16/01/17 22:19, Nick Timkovich wrote:
If you have a non-release release with some description text and a home-page that points to where active development is going on (that could constitute "functionality" in a non-code way), I think that should preempt a reasonable person (which is hopefully a superset of maintainers) from deleting it.
Yes, indeed, this is what I'd like to clarify. Someone is simply bound to clean up all the packages at one point and this PEP likely will be the basis for deciding what to delete or not so I'd very much like to ensure ours will not be removed. regards, -- Dariusz Suchojad https://zato.io ESB, SOA, REST, APIs and Cloud Integrations in Python _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
participants (10)
-
Anna Ravenscroft -
Barry Warsaw -
Dariusz Suchojad -
Ethan Furman -
Lukasz Langa -
M.-A. Lemburg -
Nick Coghlan -
Nick Timkovich -
Robert Collins -
Steve Dower