许可证审查过程

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

这个OSI委员会很乐意提前咨询实体，帮助他们导航流程并改进许可证，但正式批准需要通过许可证审查流程。

过程的目的

1. 确保批准的许可证符合开放源代码定义并提供软件自由
2. 不鼓励重复和写得不好的许可证以及那些有意外要求的许可证
3. 确保彻底、透明和及时的审查（例如在60天内）

流程概述

将许可提交到许可审查邮件列表

希望OSI审查和批准许可证的人将许可证提交到许可证审查邮件列表。任何人都可以加入许可审查邮件列表并参与许可审查过程。还有一个许可证讨论邮件列表; 这是对开放源码的一般讨论，我们还鼓励许可提交者在正式将许可提交给许可审查之前，就许可讨论列表征求意见。

为了在这个过程中导航，许可证提交者应该记住，许可证审批是一个一致的过程。这意味着任何人，包括董事会成员，都无权批准或拒绝许可证，也无权要求更改，无论他们的立场如何强硬。

加入邮件列表并关注评论

提交许可证的人员必须加入许可证审查邮件列表。当提交许可证进行审查时，许可证提交者通常会遇到问题。许可证提交者应注意并回应这些问题。如果他们没有兴趣，我们将假定他们对参与该过程不感兴趣，许可证将面临被拒绝的高风险。提交许可证后，任何希望对此发表评论的人都将在许可证审查列表上发表评论。

在许可证审查过程中，可能会有各种不同的意见。有些评论可能会影响许可证是否会获得批准，有些则可能不会。可能存在与批准无关的观察结果；对许可证中的写作风格或政策选择的赞扬或批评；关于许可证或OSI批准政策的意识形态声明，更为普遍；或者解释为什么许可证不符合批准要求。一些讨论可能会很长。

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

回应评论，发布新的许可证版本

通常会对许可证的更改提出建议。建议只是这样；许可证提交者不应该觉得有义务更改许可证，尽管如果评论指出了许可证不太可能获得批准的原因，那么这样做可能是明智的。但是，在考虑许可证时不能更改它。

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

达成决策共识

许可证的“决定日期”通常是指（a）许可证最初提交给许可证审查列表审查后60天，或（b）提交之前提交审查的许可证修订版本后30天，前提是该日期不早于原始许可证提交后60天。虽然我们将努力遵守这一60/30天的决定日期定义，但情况可能要求我们进一步延长决定日期。

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

发布最终决定

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

然后，董事会将投票决定是否采纳许可证委员会的建议。许可证委员会主席将向名单报告董事会的决定。如果许可证获得批准，OSI网站将酌情更新。

如何提交请求

提交的许可证要么是“遗留”许可证，要么是“新”许可证。 

“遗留”许可证是指由不同的无关实体维护的20多个项目使用了至少五年的许可证。

“新”许可证是指任何非传统许可证的许可证。如果是一系列许可证，则必须单独提交每个许可证。如果许可证使用英语以外的语言，则许可证提交人必须提供经认证的英语译文。

请求批准遗留许可证

谁可以提交请求：任何人

许可证提交人必须：

• 以简单文本格式提交许可证副本作为附件。
• 肯定地说声明许可证符合使用开放源代码定义，包括特别确认它符合OSD 3、5、6和9。
• 确定项目是什么已在使用许可证。
• 提供执照管理员（如果知道）和提交者。如果许可提交者不是许可管理员，OSI将尝试与许可管理员联系。
• 提供提交人认为有助于许可证审查的任何其他信息。例如，Debian、FSF或Fedora项目对许可证的批准将与审查过程相关。
• 提供一个唯一名称对于许可证，最好包括版本号。
• 如果存在，请通过其他项目（如SPDX或ScanCode）提供唯一标识符。
• 识别任何建议的标签用于许可证（如果可用；请参阅下面关于标记的内容）。

申请批准新许可证

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

除了旧版许可证所需的信息之外，许可证提交人必须：

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

许可证审批标准

不可能全面列出许可证可能被批准或不被批准的所有原因。软件更改以及许可在其中扮演的角色可能会更改。有时，许可证会出现以前从未考虑过的问题。许可证审查列表中的成员都是高度熟练、经验丰富且深入参与开源软件的人员。他们的共识是，许可证不能确保软件自由，在某些情况下，即使他们无法确定OSD的特定方面或不符合下面的批准准则，也可能成为拒绝许可证的理由。

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

传统许可标准

许可证必须符合开放源代码定义。不会考虑对传统许可证文本进行更改的建议。许可证将按书面形式批准或不批准。在决定是否批准许可证时，将考虑许可证的历史背景及其含义的共同理解。 

新许可证标准

除了满足开放源代码定义，以下标准适用于新许可证：

1. 许可证必须是可重用的，这意味着任何许可方都可以使用它，而无需更改条款或使条款对不同的许可方产生不同的结果。
2. 许可证的条款在结构上没有使许可人比任何被许可人处于更有利的地位。
3. 如果任何条款存在歧义，则歧义不得对许可证的应用产生重大影响。 
4. 许可证必须在语法和句法上对许可证语言的使用者清晰可见。 
5. 许可证应用程序的每一种可能变化都必须符合OSD。
6. 提交时必须遵守许可。例如，给定服务器端公共许可（SSPL），这不是目前任何人都可以遵守的许可。
7. 许可证必须填补当前现有许可证无法填补的空白。
8. 文本必须是完整的许可证；Commons Clause和ClassPath等例外情况的覆盖将不会与它们修改的许可证分离开来获得批准。

阅读共同限制尚未批准的，以及未批准的原因。

许可证标记

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