OSI 报告：从历史角度看 DOSP 做法

Open Source Initiative (OSI) 于日前发布了一份名为“Delayed Open Source Publication: A Survey of Historical and Current Practices”的新报告，深入研究了 DOSP 的历史、模式以及发展趋势。

延迟开源发布 (DOSP) 是是首先在专有许可证下分发或公开部署软件，然后以开源许可证有计划地发布该软件源代码的做法；Business Source License (BSL) 就是一种广为人知的 DOSP 许可。

在整个开源软件历史中，软件生产商都一直在实践 DOSP；报告收集了一些示例，并对其进行分类以进行分析。

最早的 DOSP 实例之一是 1998 年左右根据"Aladdin Free Public License"发布的 Aladdin GhostScript，后来过渡到同时采用专有许可和 GPL 的发布模型。KDE 的 Qt 库也是一个鲜明的示例，它将 DOSP 作为防止潜在开发中止的一种保障措施。Qt 的许可历史很复杂，如今其可以在商业和开源 GPL 2.0、GPL 3.0 和 LGPL 3.0 许可下使用。

研究人员发现 DOSP 大致有 3 种类型：

• Unconditional scheduled relicensing。这种直接的方法涉及在过渡到开源许可之前预先定义的时间延迟。
• Event-driven relicensing。在这种情况下，开源发布与特定事件相关联，比如发布新的专有版本，促使其前身开源。虽然这种方式曾经很常见，但现在已经很少使用了。
• Conditional relicensing。这种类型取决于某些条件，例如在转向开源之前获得资金或找到合适的非营利组织。但这个承诺可能会存在不会兑现的风险。

与 DOSP 相关的一个变种是 "visible source"或 "source available"。在这些模型中，源代码通常是可用的，但没有 Open Source Definition (OSD) 所保证的自由。近期比较著名的例子就是 Meta 的 AI 大语言模型 Llama 2 Community License，其代码是可用的，但商业使用受到限制。

OSI 研究人员发现，在 DOSP 早期，DOSP"通常是为了垄断直接的商业收入：许可证将授予开源所需的大部分权限，但关键是不允许商业使用软件"。"这一限制适用于包括用户在内的所有下游被许可方，而不仅仅是开发者。

"然而，最近一些 DOSP 许可证是为了防止任何被许可人在与某些特定类型的软件竞争的产品或服务中使用该软件，而这些软件对许可人来说具有重要的战略意义，与直接收入无关。"

例如，为 MariaDB 编写的 BSL 1.1 不允许在生产中使用许可代码，除非许可人使用"Additional Use Grant (AUG)"机制。但 AUG 因公司而异，也正因如此，每个 BSL 实例实际上都是一个本质上不同的许可证。

如今，BSL 正在兴起。HashiCorp 在去年宣布变更核心产品的开源协议，从 MPL 2.0 迁移到 BSL 1.1，CouchBase、DragonflyDB 和 ArangoDB 等十来个项目都也使用了 BSL 协议。

除了 DOSP 许可证，MongoDB 和 Redis 等几个面向云的软件项目在过去几年中也放弃了开源许可证，转而采用带有非竞争条款的许可证 (如 SSPL)。

研究认为，DOSP 是企业用来保持商业优势，同时试图尽可能多地保留开源的优势的一种方式。但随着延迟的增加，开源的好处也会越来越少。探索这些好处与独占利用期限之间的权衡是未来值得研究的方向。此外，DOSP 的实验和多样性也都比我们所意识到的要多得多--尝试 DOSP 的项目、以及尝试的方式都要远远多出想象。

报告还提出了一些未来值得继续研究的方向，包括：AGPL 与 DOSP 许可对比、对外部贡献的影响、首次发布开源代码后的重新授权等等。

更多详情可查看完整报告。