我们真的需要另一种非开源的源代码可用许可证吗？

并不是，不过 “功能源代码许可证” 却更进一步混淆了开源许可证的界限。

回溯到我们还用打孔卡和磁带载入软件的那时，所有的程序都是 “自由软件” 和 “开源” 的。然而随后专有软件的出现，一切都变了。针对此状况，程序员们反抗并发展出了第一个正式的自由和开源软件的定义。

现如今，不开源的代码甚至成为了罕见的例外。然而，这并未阻止某些误将开源视为一种商业模式，而非开发模式的公司，试图将专有方法和 “开源” 代码相结合。最新的案例就是 Sentry 推出的 “ 功能源代码许可证 Functional Source License ”（FSL）。

沿袭 服务端公共许可证 Server-Side Public License （SSPL）、 公共条款 Common Clause 和 商业源代码许可证 Business Source License 的传统，FSL 表面上似乎重视开源的重要性，却对开源的核心理念进行嘲讽，形容其方式为“享有自由却无需付出努力”。

呵呵。

其实，Sentry 是一个面向开发者的应用代码监控服务，它源于对 Django（一款开源的，高级的 Python 网络框架）的少量代码开发。如今，它仍然主要用开源代码进行开发。不难看出，没有开源，Sentry 啥都不是。

这也同样适用于其他所有使用 “ 源代码可用 source-available ” 或其他半开源许可证的公司。它们都源自于开源公司，然后为了最大化利润，它们将免费获取的代码进行了重新许可，以锁定代码。

正如 开源倡议 Open Source Initiative （OSI）董事会副主席 Thierry Carrez 对我说的，“有些公司通过利用开源代码库作为主体建立了他们的软件，不需要在使用数百个开源软件包作为他们的依赖关系之前就请求许可。他们通过公开承诺遵守开源原则建立了口碑。但在试图追求更大价值的过程中，他们短视地放弃了最初带给他们成功的模式。”说的真对。

例如 Sentry、MariaDB、Redis 和 HashiCorp 这样一些前开源公司，之所以他们能做出这样的举动，可以归功于他们采用了侵犯了权利的 贡献者许可协议 Contributor License Agreements （CLA）。这些协议是一种法律文件，它定义了贡献者为他们的代码在开源项目中被使用所设定的条款。尽管有些 CLA，像 Apache 软件基金会的 CLA 或 Linux 的 开发者原创证书 Developer Certificate of Origin ，只是用来保护他们项目的法律权利。但其他一些，比如 MongoDB 的贡献者协议，却被用来占有你的代码及其版权。通过这样的 CLA，在任何他们喜欢的方式中使用和重新许可你的代码，对于他们来说易如反掌。

SourceHut 的创始人兼首席执行官 Drew Devault 在谈论 Elasticsearch 从开源向“源码可用”转变时表达了他的观点：“Elasticsearch 归其 1,573 名贡献者所有，他们自己保留着版权，并向 Elastic 授予了一个无条件分发他们作品的许可。当 Elastic 决定 Elasticsearch 不再开源时，他们就利用了这个漏洞，这个漏洞实际上一开始就被他们故意安插进去…… Elastic 对 1,573 的贡献者们、以及所有信任、忠诚于他们，给予他们支持的人们翻了脸。”

如今，我们看到企业 Sentry 和之前的案例如出一辙，换汤不换药。公正地讲，Sentry 很长一段时间以来都一直在使用源码可用许可证。在该公司创建并采用 FSL 前，自 2018 年以来就用了 BSL。如果还有人继续向 Sentry 捐献代码，那他们肯定知道自己在做什么。

那么为何还要做一个新许可证呢？Sentry 的开源负责人 Chad Whitacre 这样解释道：“BSL 存在两个显著的弊端。首先，预设的非竞争期为四年，对于软件行业来说，这简直就是个漫长的周期。这可能会让人产生一种感觉，即最后的开源转变只是一种象征性的举措。这几乎可以说是 100 年那么长。对于 Sentry，我们选择将这个期限缩短到三年，但我们也承认，可能连三年都过长了。”

该许可证期满后，这些代码将会使用 Apache 2.0 或者 MIT 许可证。但实际上，这并不像初听起来那么慷慨。根据 FSL，你可以将它的代码用在任何用途 —— “除了竞争性使用的情况下。所谓竞争性使用，指的是利用该软件开发或提供能够与我们的产品或服务竞争的商业产品或服务，不论是该软件本身，还是我们基于该软件提供的任何其他产品或服务，只要我们是在该软件发布之日或之前就已经提供了这类竞争产品或服务。”

换种说法，你可以查看代码，但不能用这些代码运营业务。如需更深入了解，你可以查看该公司的 FSL 版本的 Apache 和 MIT 许可证。就我个人而言，我认为这两个都不算是开源许可证。

Whitacre 进一步说明了，“更严重的缺陷是 BSL 有过多的参数：变更日期、变更许可证，以及额外使用授予。最大的问题在于额外使用授予，它是一项巨大的填空题，意味着每一个 BSL 实质上都是不同的许可证。”

我无法反驳这一观点。每个公司的 BSL 都不一样。同时，这也意味着当客户与使用 BSL 的公司签约时，他们很难确切知道法律上为他们保留了哪些权益。Sentry 希望通过 FSL 让其产品和服务对其客户更具吸引力。

也许这方法行得通。但我赞同 Carrez 所说的：“发布另一种能剥夺开发者在技术选择中的自主权的许可证变体并非新鲜事：他们其实就是要从整个软件生态系统中摧毁开发者的基本自由，从而明确自己对其专有软件及其许可使用权的所有权。这并不是开源：这只是包装在开源幌子下的专有门户。”

（题图：MJ/beb19f23-c230-4a3f-9bb3-210066ad749b）

via: https://www.theregister.com/2023/11/24/opinion_column/

作者：Steven J. Vaughan-Nichols 译者：ChatGPT 校对：wxy