Following system colour scheme - Python 增强提案 Selected dark colour scheme - Python 增强提案 Selected light colour scheme - Python 增强提案

Python 增强提案

PEP 541 – 包索引名称保留

作者:
Łukasz Langa <lukasz at python.org>
BDFL 委托
Mark Mangoba <mmangoba at python.org>
讨论至:
Distutils-SIG 邮件列表
状态:
最终版
类型:
流程
主题:
打包
创建日期:
2017年1月12日
发布历史:

决议:
Distutils-SIG 消息

目录

摘要

本 PEP 提议扩展包索引 [2] 的使用条款 [1],阐明包所有者对包索引上包名称所有权的期望,特别是关于冲突解决方面。

将调查 CPAN [3]、NPM [4] 和 GitHub [5] 等现有包仓库作为该领域的现有技术。

基本原理

鉴于索引上的包名称共享一个单一的扁平命名空间,唯一名称是有限资源。包索引的年龄增长导致名称当前使用与同一名称不同建议使用之间冲突情况的不断增加。

本文档旨在提供解决此类冲突最典型案例的一般准则。

审批流程

由于此政策的应用可能对 Python 软件基金会产生潜在的法律影响,因此使用的审批流程比大多数 PEP 更正式。

被指派的 BDFL-Delegate 将不直接接受 PEP,而是建议 PSF 的打包工作组接受它。在咨询 PSF 的总法律顾问后,该政策的采纳将由工作组进行正式投票。

此正式审批流程将用于政策的首次采纳和任何未来修订的采纳。

规范

本文档背后的主要思想是包索引为社区服务。鼓励每个用户根据使用条款将内容上传到包索引,并理解这样做的风险由用户自行承担。

虽然包索引不是备份服务,但包索引的维护者会尽力以其发布形式无限期地保持该内容的可访问性。然而,在某些极端情况下,更广泛社区的需求可能超过个人对包名称所有权的期望。

本文档涵盖的用例包括:

  • 废弃项目
    • 由不同的用户集继续维护;或
    • 从索引中删除以用于不同的项目。
  • 活跃项目
    • 解决名称争议。
  • 无效项目
    • 涉及知识产权侵权索赔的项目。

在“实施”部分中表达的对使用条款的拟议扩展将作为一份单独的文档发布在包索引上,并链接到主页页脚中现有的使用条款旁边。

实施

可联系性

包索引的用户全权负责与包索引维护者就用户拥有的项目相关事宜进行联系。在每次需要联系用户时,维护者将尝试至少三次,使用以下联系方式:

  • 用户在包索引上个人资料中存档的电子邮件地址;
  • 为上传到索引的给定项目在“作者”字段中列出的电子邮件地址;以及
  • 在索引上或列出的主页上给定项目的文档中找到的任何电子邮件地址。

维护者在六周后停止尝试联系用户。

废弃项目

当满足以下所有条件时,项目被视为废弃

  • 所有者不可联系(见上文“可联系性”);
  • 过去十二个月内没有发布版本;以及
  • 所有者在项目主页上没有活动(或未列出主页)。

所有其他项目均被视为活跃

废弃项目的持续维护

如果候选人愿意继续维护废弃项目,则当满足以下所有条件时,名称所有权将被转让:

  • 根据上述规则,项目已被确定为废弃
  • 候选人能够证明其自己联系现有所有者失败的尝试;
  • 候选人能够证明其自己在项目的分支上所做的改进;
  • 候选人能够证明为什么使用不同名称的分支不是可接受的变通方案;以及
  • 包索引的维护者没有任何其他保留意见。

在任何情况下,名称都不会违背可联系所有者的意愿重新分配。

废弃项目的删除

项目绝不会仅仅因为废弃而被从包索引中删除。上传到包索引的工件具有固有的历史价值。

当满足以下所有条件时,废弃项目可以转让给新所有者以重新使用该名称:

  • 根据上述规则,项目已被确定为废弃
  • 候选人能够证明其自己联系现有所有者失败的尝试;
  • 候选人能够证明拟议重新使用名称的项目已经存在并符合知名度要求;
  • 候选人能够证明为什么使用不同名称的分支不是可接受的变通方案;
  • 包索引上现有包的下载统计数据显示项目未被使用;以及
  • 包索引的维护者没有任何其他保留意见。

活跃项目的名称冲突解决

包索引的维护者不是围绕活跃项目争议的仲裁者。这里有许多可能的情景,下面列出了描述一些真实世界示例的非排他性列表。以下任何情况都不符合包名称所有权转让的条件:

  1. 用户 A 和用户 B 共享项目 X。一段时间后,他们分道扬镳,每个人都想以名称 X 继续项目。
  2. 用户 A 在包索引之外拥有项目 X。用户 B 在索引上以名称 X 创建了一个包。一段时间后,用户 A 想在索引上发布项目 X,但发现名称已被占用。即使用户 A 的项目 X 获得知名度而用户 B 的项目 X 不知名,这也是事实。
  3. 用户 A 将项目 X 发布到包索引。一段时间后,用户 B 提议对项目进行错误修复,但用户 A 未发布新版本。即使用户 A 同意发布新版本但后来没有发布,即使用户 B 的更改已合并到项目 X 的源代码仓库中,这也是事实。

同样,上述列表并非排他性。包索引的维护者建议用户相互联系,并通过尊重的沟通解决问题(参见 PSF 行为准则 [6])。

无效项目

发布在包索引上的项目满足以下任何条件之一,均被视为无效并将从索引中删除:

  • 项目不符合使用条款;
  • 项目是恶意软件(旨在直接利用或损害系统或用户,促进命令和控制攻击,或执行数据泄露);
  • 项目是垃圾邮件(旨在宣传或招揽商品或服务);
  • 项目包含非法内容;
  • 项目侵犯版权、商标、专利或许可;
  • 项目是名称抢占(包没有功能或为空);
  • 项目名称、描述或内容违反行为准则;
  • 项目使用混淆来隐藏或掩盖功能;或
  • 项目滥用包索引,用于其非预期目的。

包索引维护者出于安全原因会主动声明某些包名称不可用。

知识产权政策

Python 软件基金会和包索引维护者的政策是适当地回应第三方提出的知识产权侵权索赔。Python 软件基金会和包索引维护者均不预先筛选上传的包是否存在任何类型的知识产权侵权。

可能侵权的包应报告给 legal@python.org,Python 软件基金会的法律顾问将确定适当的回应。Python 软件基金会可自行决定删除包或将其转让给新所有者,以解决侵权索赔。

发布在包索引上的项目满足以下任何条件,均可能被视为侵权并可能从索引中删除或转让给新所有者:

  • 项目包含第三方未经许可的受版权保护材料,并受 DMCA 正当索赔的约束;
  • 项目以不属于名义或合理使用准则的方式使用第三方的商标;
  • 项目明确涉及专利系统或流程,并成为投诉的主体;或
  • 项目正处于活跃诉讼中。

如果发生知识产权侵权投诉,投诉副本将发送给包所有者。在某些情况下,包索引维护者可能会在所有者回应之前采取行动。

Python 软件基金会的角色

Python 软件基金会 [7] 是提供包索引作为社区服务的非营利法律实体。

如果事项不够明确,包索引维护者可以升级本文档涵盖的问题,由打包工作组解决。有些决定需要董事会进行额外判断,特别是在违反行为准则或法律索赔的情况下。董事会提出的建议将发送给打包工作组 [8] 进行审查。

打包工作组对本文档涵盖的任何争议拥有最终决定权,并可在仔细考虑后决定重新分配或从包索引中删除项目,即使未满足此处列出的所有要求。

如何请求名称转让

如果您想接管 PyPI 上现有的项目名称,请遵循以下步骤:

  1. 尝试直接联系当前所有者:给他们发电子邮件,如果能找到相关仓库,就开一个问题。此处描述的流程是在无法联系到所有者时的最后手段。
  2. 检查上述标准,查看何时允许转让。特别是,为不同项目重复使用名称的标准比继续维护同一项目的标准更严格——尽管在这两种情况下要获得名称转让都不容易。
  3. 搜索 PyPI 支持问题,查看是否有人已经在请求相同的名称。
  4. 如果满足所有条件以转让名称所有权,打开一个新问题请求,详细说明您认为每个相关条件都得到满足的原因。

现有技术

NPM 包含一个从首页链接的独立部分,名为包名称争议。它被描述为一份“活文档”,截至 2017 年 1 月,其内容可总结如下:

  • 禁止包名称抢占;
  • 希望重复使用项目名称的用户需要联系现有作者,并抄送 support@npmjs.com
  • 所有联系必须符合 NPM 行为准则;
  • 如果在几周后没有解决,npm inc. 保留对此事拥有最终决定的权利。

CPAN 允许任何用户上传同名模块。相关的索引 PAUSE 只列出由主要维护者或列出的共同维护者上传的模块。CPAN 文档没有以其他方式处理争议。

GitHub 的服务条款包含一份不符合一般使用条件的详尽行为列表。虽然没有在任何地方编入法典,但 GitHub 确实同意用户通过存档废弃账户并允许其他用户或组织重命名其账户来收回废弃账户名称。这是根据具体情况进行的。

被拒绝的提案

最初的方法是抱最好的希望,并在没有书面政策的情况下解决出现的问题。这是不可持续的。缺乏关于包名称冲突解决的普遍可用的书面指南正在导致不必要的紧张。从用户的角度来看,包索引维护者在没有书面指南的情况下做出的决定可能显得武断。从包索引维护者的角度来看,由于缺乏明确的政策而可能无意造成损害的风险,解决名称冲突是一项有压力的任务。

参考资料

致谢

多年来 Distutils 和 Catalog SIGs 的许多参与者提供的想法。


来源:https://github.com/python/peps/blob/main/peps/pep-0541.rst

最后修改:2025-02-01 08:59:27 GMT