是否应该修订开源定义？

图片来源：

Beth Cortez-Neavel 在 Flickr 上的作品。公共领域。由 Opensource.com 修改

由开源促进会 (OSI) 维护的开源定义 (OSD) 是开源运动的基础支柱。OSI 的观点是，有效标记为“开源”的软件必须以满足 OSD 中规定的 10 条标准的的方式提供，其中除一条外，所有标准都与许可条款有关。

通过其许可审查流程，OSI 确定提交的许可是否符合 OSD。OSD 被广泛认为是权威性的，通常在合同语言中被引用，并在法规中被提及。 OSD 由 OSI 在 1998 年成立后不久起草和采用。它本质上是 Debian 自由软件指南 (DFSG) 的品牌重塑，只有相对较小的变化。它只被修改过一次，即在 2002 年，增加了一条第十条（“许可证必须是技术中立的”）。

OSD 文本的稳定性反映了开源社区中处理重要法律文本时更为普遍的保守主义。被誉为“社区宪法”的被广泛采用的开源许可证很少被修改，部分原因是实际的和政治的障碍。 OSD 似乎比任何给定的符合 OSD 的许可证更类似于真正的宪法文本，当然，宪法的修改频率低于它们授权的普通法律。修改开源许可证的难度是有问题的——例如，它可能会增加在许可证执行诉讼中不利的司法解释的成本——但 OSD 很少修改似乎没有任何类似的成本。可以合理地评价 OSD：“如果它没坏，就不要修理它。”

但是，最近的发展可能强化了现在是探索改进 OSD 的恰当时机的理由。在许可审批流程和其他地方，试图“玩弄”OSD 的行为有所增加。 OSI 宣称开源含义的权威以及 OSD 的持续相关性受到许多批评者的质疑，包括推广商业模式保护性“源代码可用”许可证的企业家和风险资本家、新兴的“道德来源”运动的倡导者，以及似乎将 OSI 和 OSD 视为与一套名誉扫地的价值观相关的过去时代的产物的一般偶像破坏者。虽然没有修改 OSD 的迫切需要，但 OSI 可能会受益于采取一项战术性修改工作，旨在保持和加强 OSD 作为合法、权威且与当代观点一致的事物的地位。

改版可能是什么样子

假设的 OSD 改版可能会采取几个方向。可以为进行重大的风格上的重新制定辩护。虽然 DFSG 可能已被证明是指导 Debian 打包策略的成功的有机文档，但我认为 OSD 的 DFSG 基础并不适合 OSI 对非项目特定许可证审查的相当不同的政策重点。 OSD 包含一些对 1990 年代 Linux 发行版许可争议的引用，并且其中一些部分显然是考虑到多包发行版的担忧而编写的。（例如，参见 OSD 1、4 和 9。）过去，我一直在想，OSI 是否可以通过放弃当前形式的 OSD，转而采用相对优雅的自由软件定义 (FSD)（由自由软件基金会 (通常被称为“四项自由”)维护）做得更好。但出于主要涉及风格的原因，OSI 似乎不太可能进行如此激烈的改变，甚至相对较小的、零敲碎打的文本修改。

人们还可以想象 OSI 寻求对 OSD 进行实质性的政策变更——允许之前被视为禁止的某些类别的许可证，或拒绝之前被认为允许的某些类别。考虑一个完全不现实但及时的例子：OSI 可以通过修改 OSD 5 和 6 的反歧视条款以专门授权这些许可证中进行的分类来接受道德来源运动或某些“开源公司”所倡导的各种最近的源代码可用许可证。但是，我不相信 OSI 实际上认为 OSD 存在任何值得通过 OSD 修订来解决的实质性政策缺陷，因此这种形式的 OSD 改革似乎也不太可能。

第三种 OSD 修订将涉及努力澄清或更明确地说明 OSI 对开源许可证的要求和限制的现有理解。正如我在之前的文章中指出的那样，2019 年，OSI 澄清了其许可批准流程的目的是确保批准的许可证不仅符合 OSD，还提供软件自由。这样做是出于试图通过利用文本中的覆盖范围差距或模糊性来在许可审查过程中“玩弄”OSD 的目的。关注软件自由问题提供了一种纠正此问题的方法，而不会偏离 OSI 对 OSD 的实际解释。修订 OSD 以填补这些空白或消除 OSD 文本的歧义是一种替代且更可取的解决同一问题的方法。面向澄清形式的 OSD 修订似乎最有可能被 OSI 接受。

需要考虑的事项

以下是 OSI 可能希望考虑的几个具体问题

1. 专利

考虑到它起源于 1990 年代，这并不奇怪，OSD 没有提及任何关于专利的内容。与 OSD 解释相关的某些争议集中在开源许可和专利许可之间的关系上。例如，2012 年 CC0 的提交引发了关于开源许可证是否可以明确排除授予专利许可证的辩论。

最近，在许可批准的背景之外，一些基于 FRAND 许可标准必要专利的商业模式的公司（出于实际上尚不清楚的原因）花费了大量资源来推进有效标记的开源许可证可以是“仅版权”的观点。 OSI 强烈反对这种观点。在许可审查讨论中，OSD 7（“附加到程序的权利必须适用于所有重新分发程序的人，而无需这些方执行额外的许可证”）已被引用为“仅版权”许可证不能被视为开源的依据，但该条款很可能不是考虑到专利而编写的。通过修订 OSD 来令人满意地解决专利问题将具有挑战性，但由此产生的确定性可能非常有益。

2. Copyleft 和不相关的软件

最近的一些许可证提交提出了这样的问题：copyleft 许可证条件可以在多大程度上不违反 OSD。License Zero Reciprocal Public License (L0-R) 有效地要求由 L0-R 许可的工具创建或执行的软件，但与这些工具无关的软件，以开源许可证发布。与此类似，Server Side Public License (SSPL) 要求发布用于将 MongoDB 实现为服务的整个堆栈的源代码在 SSPL 下发布。（L0-R 和 SSPL 都受到了许可审查的强烈批评，但在 OSI 能够对它们做出决定之前被撤回。）

虽然可以争辩说这些类型的许可证违反了 OSD 的反歧视条款，但这不是很令人满意，因为任何重要的 FOSS 许可证都将包含易于被描述为歧视个人或团体或领域的分类。 OSD 9（“许可证不得限制其他软件”）解决了此处讨论的此类问题，但它是以特定于发行版环境的方式编写的。 OSI 可能会概括 OSD 9 的语言，也许可以采用 GPL 的简单聚合条款，以解决未来提交的将 copyleft 扩展到不相关软件的许可证。

3. 自由 0

OSD 中意外覆盖范围差距的一个很好的例子是缺少 FSD 中“自由 0”的任何对应物：“出于任何目的，随心所欲地运行程序的自由。” FSD 随附的评论表明，自由 0 体现了一种隐私权：用户享有“无需与开发者或任何其他特定实体就 [软件] 进行通信”的自由。我怀疑任何认为 OSD 具有权威性的人都会假设 OSD 以某种方式包含自由 0 的等价物，无论是隐含地还是作为涌现属性还是其他方式。目前尚不清楚为什么它从 DFSG 文本中消失了，但 Debian 社区可能认为它太明显了，不值得提及。

近年来，至少有一个提交给 OSI 批准的许可证 L0-R，可以说违反了自由 0。但是，L0-R 的作者 Kyle Mitchell 指出，OSI 早在历史上批准的一个晦涩的许可证（被 FSF 和 Debian 视为非自由）具有相似的特征。 2017 年，McCoy Smith 观察到，认为自由 0 不是 OSD 固有的观点会导致奇怪的结论。对于 OSI 而言，在 OSD 中将 FSD 中自由 0 的简单语言作为新的明确标准进行调整似乎是可取的，并且可能相对简单。