许可证审查流程

所有许可证都必须经过下述的公开审查流程。

OSI 理事会 乐于提前与实体协商，以帮助他们了解流程并改进其许可证，但正式批准需要经过许可证审查流程。

流程的目的

1. 确保批准的许可证符合开源定义，并提供软件自由
2. 阻止重复和编写不佳的许可证以及具有意外要求的许可证
3. 确保彻底、透明和及时的审查（例如在 60 天内）

流程概述

将许可证提交到 license-review 邮件列表

希望其许可证获得 OSI 审查和批准的人员将许可证提交到 license-review 邮件列表。任何人都可以加入 license-review 邮件列表并参与许可证审查流程。还有一个 license-discuss 邮件列表；这是用于讨论一般开源的，我们也鼓励许可证提交者在正式将许可证提交给 license-review 之前，先在 license-discuss 列表上寻求建议。

为了了解流程，许可证提交者应牢记，许可证批准是一个共识流程。这意味着，包括理事会成员在内的任何人都无权批准或拒绝许可证，也无权要求更改，无论他们多么强烈地表达自己的立场。

加入邮件列表并关注审查

许可证提交者必须加入 license-review 邮件列表。当许可证提交审查时，通常会向许可证提交者提出问题。许可证提交者应注意并回应这些问题。如果他们不这样做，我们将认为他们对参与该流程不感兴趣，并且该许可证将面临很高的拒绝风险。一旦许可证被提交，任何希望对其进行评论的人都将在 license-review 列表上评论。

在许可证审查过程中，可能会出现各种不同的评论。一些评论可能会影响许可证是否获得批准，而另一些则可能不会。可能会有一些与批准无关的意见；对许可证中的写作风格或政策选择的赞扬或批评；关于许可证或 OSI 的批准政策的意识形态声明；或者解释为什么许可证未能满足批准要求。一些讨论可能会变得相当冗长。

OSI 的理事会成员和员工可以以个人身份参与许可证审查。当以个人身份参与时，他们应使用非 OSI 电子邮件地址。

对评论做出反应，发布新的许可证版本

通常会有人提出修改许可证的建议。建议仅仅是建议；许可证提交者不应感到有义务更改许可证，但如果评论指出了许可证不太可能获得批准的原因，那么这样做可能是明智的。但是，在审议过程中，许可证不能更改。

如果许可证提交者想更改许可证的语言，则应撤回当前版本的许可证以进行审查，并提交更新后的版本。我们建议，如果要进行更改，许可证提交者应等待并收集所有所需的更改到一个新的提交中，而不是多次撤回并重新提交相同的许可证。

达成共识以做出决定

许可证的“决定日期”通常是指 (a) 许可证最初提交到 license-review 列表进行审查后的 60 天，或 (b) 先前提交审查的许可证的修订版本提交后的 30 天，前提是该日期不早于原始许可证提交后的 60 天。虽然我们将尽力遵守此 60/30 天决定日期定义，但情况可能需要我们进一步延长决定日期。

许可证委员会观察正在进行的讨论，以确定是否已达成结论，以及是否就批准或拒绝许可证达成共识。如果尚未达成共识，许可证委员会将要求进一步讨论，以努力达成共识。此过程可能需要进一步延长决定日。

发布最终决定

在达成共识后，许可证委员会主席将向 OSI 理事会提供批准或拒绝的建议，并抄送许可证审查列表。

然后，理事会将投票决定是否采纳许可证委员会的建议。许可证委员会主席将向列表报告理事会的决定。如果许可证获得批准，OSI 网站将进行相应的更新。

如何提交请求

提交的许可证将是“旧版”许可证或“新”许可证。

“旧版”许可证是指已被不同的不相关实体维护的超过 20 个项目使用至少五年的许可证。

“新”许可证是指任何不是旧版许可证的许可证。如果是许可证系列，则每个许可证必须单独提交。如果许可证使用英语以外的语言，则许可证提交者必须提供经认证的英语翻译。

旧版许可证的批准请求

谁可以提交请求：任何人

许可证提交者必须

• 以纯文本格式的附件形式提交许可证副本。
• 明确声明该许可证符合开源定义，包括特别确认其符合 OSD 3、5、6 和 9。
• 确定哪些项目已经在使用该许可证。
• 提供许可证管理者（如果已知）以及提交者的身份和联系方式。如果许可证提交者不是管理者，OSI 将尝试与许可证管理者联系。
• 提供提交者认为对许可证审查有帮助的任何其他信息。例如，Debian、FSF 或 Fedora 项目批准该许可证将与审查过程相关。
• 为许可证提供一个唯一的名称，最好包括版本号。
• 如果存在，请提供其他项目（如 SPDX 或 ScanCode）的唯一标识符。
• 确定许可证的任何拟议标签（如果可用；请参阅下文关于标签的说明）。

新许可证的批准请求

谁可以提交请求：任何人，但最好是许可证管理者。提交者必须是自然人，理想情况下代表许可证管理者（如果后者是组织）。

除了旧版许可证所需的信息外，许可证提交者还必须

• 描述现有许可证未填补的空白，新许可证将填补该空白。
• 将其与最相似的 OSI 批准的许可证进行比较和对比。
• 描述许可证经历的任何法律审查，包括是否由律师起草。

许可证批准标准

不可能全面列出许可证可能或可能不被批准的所有原因。软件会发生变化，许可证在其中扮演的角色也可能会发生变化。有时，许可证会提出以前从未考虑过的问题。license-review 列表的成员都是技术精湛、经验丰富且深入参与开源软件的人员。在某些情况下，即使他们无法确定不符合 OSD 或以下批准指南的特定方面，他们关于许可证不能确保软件自由的共识也可能成为拒绝许可证的理由。

过去批准具有相同或相似条款的许可证并不约束 OSI 批准新提交的许可证。

旧版许可证的标准

许可证必须符合开源定义。将不考虑对旧版许可证文本的更改建议。许可证将按原样批准或不批准。在决定是否可以批准许可证时，将考虑许可证的历史背景及其含义的普遍理解。

新许可证的标准

除了符合开源定义外，以下标准适用于新许可证

1. 许可证必须是可重用的，这意味着任何许可方都可以使用它，而无需更改条款或使条款对不同的许可方产生不同的结果。
2. 许可证的条款在结构上不会使许可方比任何被许可方处于更有利的位置。
3. 如果任何条款存在歧义，则歧义不得对许可证的适用产生实质性影响。
4. 许可证的语言在语法和句法上必须对该语言的说话者清晰易懂。
5. 许可证的每种可能的应用变体都必须符合 OSD。
6. 在提交时必须可以遵守许可证。例如，鉴于 服务器端公共许可证 (SSPL) 中 copyleft 的范围，它不是任何人目前都能够遵守的许可证。
7. 许可证必须填补当前现有许可证未填补的空白。
8. 文本必须是完整的许可证；诸如 Commons Clause 之类的覆盖和诸如 ClassPath 之类的例外情况将不会与它们修改的许可证隔离批准。

阅读未获批准的常见限制，以及它们未获批准的原因。

许可证标签

OSI 计划使用标签系统来识别当前现有许可证和正在提交的许可证的属性。此类标签的列表尚不可用。