没有，但功能源代码许可证来了，它进一步搅乱了开源许可的水域
观点很久以前，当我们用穿孔卡和磁带加载软件时，所有的程序都是“自由软件”和“开源”。然后，专有软件出现了，一切都变了。但程序员们奋起反抗，开发出了第一个自由开源软件的正式定义。
如今，非开源代码是罕见的例外。但这并没有阻止那些将开源误认为是商业模式而不是开发模式的公司尝试将专有方法与“开源”代码相结合。最新的是Sentry的功能源代码许可证（FSL）。
遵循服务器端公共许可证（SSPL）<Server-Side Public License (SSPL)>、通用条款<Common Clause,>和商业源代码许可证<Business Source License>的传统，FSL<FSL >认可开源的重要性，同时嘲笑其核心，声称其方法是“没有搭便车的自由”
请
Sentry是一个面向开发者的应用程序代码监控服务，最初只是Django的一小段代码，Django是一个开源的高级Python web框架。如今，它仍然是开源代码开发中使用最多的。没有开源，Sentry 就不存在。
现在使用“源代码可用”或其他半开源许可证的公司也没有。他们都是从开源公司开始的，然后为了实现利润最大化，他们从贡献者那里免费重新许可他们获得的代码，以锁定代码。
正如开放源码倡议（OSI）董事会副主席Thierry Carrez告诉我的那样，“一些公司通过利用他们可用的开源代码来构建他们的软件，在他们的依赖关系中使用数百个开源包之前无需征得许可。他们通过公开承诺开源原则来建立自己的声誉。但为了获得更多的价值，他们后来决定放弃最初使他们成功的模式。”正是如此。
Sentry、MariaDB、Redis和HashiCorp，仅举几家前开源公司的例子，由于权利激进的贡献者许可协议（CLA），它们可以逃脱惩罚。这些是法律文件，定义了贡献者为其代码在开源项目中使用而授予的条款。虽然一些CLA，如Apache软件基金会的CLA或Linux的开发者原产地证书，只是用于保护其项目的合法权利，但其他CLA则用于获取您的代码及其版权，如MongoDB的贡献者协议。有了这些CLA，公司就可以以他们喜欢的任何方式使用和重新许可您的代码。
正如SourceHut创始人兼首席执行官德鲁·德沃（Drew Devault）在谈到Elasticsearch及其从开源到代码可用(source available)的转变时所说，“Elasticsearch属于1573位贡献者，他们保留了自己的版权，并授予Elastic不受限制地分发其作品的许可。这就是Elastic在决定Elasticearch不再是开源时利用的漏洞，他们从一开始就有意引入这个漏洞……Elastic向1573位参与者中的每一位贡献者以及所有给予Elastic信任、忠诚和赞助的人吐口水。”
现在，我们来看看Sentry，这是同一个故事，但有不同的许可证。公平地说，Sentry长期以来一直在使用源代码许可证。在该公司创建并采用FSL之前，自2018年以来一直使用BSL。如果有人还在向哨兵捐赠代码，他们必须确切地知道自己在做什么。
那么，为什么要制作新的许可证呢？Sentry开源负责人Chad Whitacre解释道：“BSL有两个主要缺陷。首先，默认的竞业禁止期是四年，这在软件界是一段很长的时间。这可能会让人觉得最终改为开源只是象征性的努力。这几乎可能是100年。对于Sentry，我们选择将其收紧到三年，但即使这样也可能太长了。”
在此期间之后，代码将引用Apache 2.0或MIT许可证。但是，这并不像听起来那么慷慨。根据FSL，您可以将其代码用于“竞争使用以外的任何目的。竞争使用是指自我们提供软件之日起，在与软件或我们使用软件提供的任何其他产品或服务竞争的商业产品或服务中使用软件。”
换句话说，您可以查找但不能运行业务的代码。有关更多信息，您可以查看Apache和MIT的FSLed版本。就我而言，两者都不是开源许可证。
Whitacre补充道，“更严重的缺陷是BSL有太多的参数：更改日期、更改许可证和额外使用授权。额外使用授权是最大的问题。这是一个巨大的空白，实际上意味着每个BSL都是不同的许可证。”
我无法反驳。每家公司的BSL都是独一无二的。这也意味着，当客户与使用BSL的公司签订合同时，他们很难确切地知道自己合法获得了什么。Sentry希望FSL能使其产品和服务对客户更有吸引力。
也许会的。但我同意Carrez的观点，他说：“发布另一个许可证变体，剥夺开发者在技术选择中的自我主权，这并不是什么新鲜事：它仍然是要剥夺整个软件生态系统的基本自由，以明确地维护对其专有软件的所有权，并允许你使用它。”。这不是开源的：它是用敞开的洗过的衣服包裹起来的专有门卫。"
