是否应该修订开源定义？

图片来源：

Beth Cortez-Neavel 在 Flickr 上发布。公共领域。Opensource.com 修改。

开源定义 (OSD) 由开源倡议组织 (OSI) 维护，是开源运动的基石。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，而且还提供软件自由。这是由于有人试图通过利用文本中的覆盖范围差距或模糊性来“玩弄”许可证审查过程而引起的。关注软件自由问题提供了一种纠正此问题的方法，而无需偏离 OSI 对 OSD 的实际解释。修订 OSD 以填补这些空白或消除 OSD 文本的歧义是一种替代方案——也是更可取的——解决同一问题的方法。以澄清为导向的 OSD 修订似乎最有可能被 OSI 接受。

需要考虑的事项

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

1. 专利

鉴于其 1990 年代的起源，OSD 对专利只字未提，这并不奇怪。某些与 OSD 解释相关的争议集中在开源许可与专利许可之间的关系上。例如，2012 年 CC0 的提交引发了关于开源许可证是否可以明确排除授予专利许可证的辩论。

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

2. Copyleft 和不相关的软件

最近提交的一些许可证引发了这样的问题：在不违反 OSD 的情况下，copyleft 许可证条件可以有多广泛。License Zero Reciprocal Public License (L0-R) 有效地要求由 L0-R 许可的工具创建或执行的软件，但与这些工具无关的软件，必须在开源许可证下发布。与此类似，服务器端公共许可证 (SSPL) 要求在 SSPL 下发布用于将 MongoDB 作为服务实施的整个堆栈的源代码。（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 似乎希望并且可能相对直接地将 FSD 中自由 0 的简单语言改编为 OSD 中的新的明确标准。