开放源代码促进会如何检查新许可证是否符合开放源代码定义

本月早些时候，我们宣布完成了审查已批准许可证列表的项目。开放源代码社区需要一个资源来自信且轻松地识别 OSI 批准的许可证，并且现在我们有了它。此批准注册表提供了所有许可证的全面且权威的列表，以便组织知道他们为其项目选择的许可证允许其软件按照开放源代码定义的规定被自由使用、修改、共享和货币化。

但是，我们如何检查新许可证是否符合开放源代码定义？许可证审查工作组的成立是为了审查改进许可证审查流程的方法，其明确目的是评估或重新评估

• 批准许可证的标准，可能会为正在使用的许可证和新许可证设定不同的标准
• 考虑批准许可证的流程，包括 OSI 本身是否应提名许可证以供批准
• 当前许可证的类别，包括它们的使用方式及其有用性
• 是否应该有一个撤销许可证认证的流程，以及该流程和标准会是什么

（最初，该小组的范围是审查取消许可证列表的流程，但它将此主题委托给了一个单独的工作组。） 

许可证审查工作组的一项重要成果是定义了传统许可证和新许可证之间的区别。传统许可证现在被定义为已被许多不同的非关联实体广泛使用至少五年的许可证。新许可证根据定义是所有其他许可证。 

更新后的许可证审查流程现已上线，以下是最重要的更改。

许可证提交流程

该小组负责许可证提交流程，重点关注导航审查流程的难度。许可证审查电子邮件列表的作用及其与 OSI 的关系得到了澄清，并对决策过程进行了更多解释，特别是许可证审查列表参与者的作用。

新的提交流程阐明了新许可证和所有许可证之间流程的差异。对于所有许可证，提交流程要求许可证提交者肯定地声明该许可证符合开放源代码定义，包括明确肯定其符合 OSD 3、5、6 和 9（历史上问题较多的要点）。他们必须确定是否有任何项目已经在使用该许可证，如果有，请提供许可证管理者的身份（如果已知）。如果许可证管理者与许可证提交者不同，OSI 将尝试与许可证管理者联系。提交者必须提供他们认为有助于许可证审查的任何其他信息，以及许可证的唯一名称（最好包括版本号）和一个SPDX标识符（如果已存在）。最后，所有许可证提交者必须确定许可证的任何拟议标签。

对于新许可证，还将要求许可证提交者描述当前现有许可证未填补哪些空白，而新许可证将填补这些空白。具体而言，他们必须将其与最相似的 OSI 批准的许可证进行比较。他们必须描述该许可证经历的任何法律审查，包括是否由律师起草，并提供其他人可能使用该许可证的示例，以证明该许可证并非许可证提交者唯一可用的许可证。

对于新许可证和所有许可证这两类许可证，过去批准类似许可证并不约束 OSI 批准新提交的许可证。

批准标准

许可证审查工作组还制定了新许可证和传统许可证的批准标准，并澄清了当前流行的许可证和所有已批准的许可证的分类系统不再需要。OSI 计划采用许可证标签系统，而不是继续当前许可证的分类。这些标签将帮助第三方识别适合其用例的许可证。

为了继续反扩散工作的成功，许可证审查工作组提出了三类许可证：拒绝、批准和首选。 

简而言之，大量的时间和精力投入到对许多问题的仔细审查中，社区的支持和评论对于达成董事会批准的一系列建议非常宝贵。如果您对审议和详细信息感兴趣，可以在许可证审查工作组 wiki上阅读更多内容。

后续步骤

我们计划通过引入新工具来讨论许可证文本，从而进一步改进许可证审查流程。认识到通过电子邮件进行对话对所有参与者来说都不舒服，我们正在设计一个更好的系统。请继续关注更多变化。