商业开源项目「公开而不开放」的许可证是怎么回事？ [译]

自从加入 GitHub 政策团队以来的最近九个月，我一再被问到开源生态系统近两年的发展趋势：单一公司主导的开源项目抛弃由 Open Source Initiative（开放源代码促进会）认可的开放源代码许可证，转而采用「公开源代码」许可证。随着基于云的基础架构改变了开发人员与其技术栈中依赖项目的交互方式，这种趋势正在不断发展。

现状如何形成？

“单一来源”（single source）开源项目的发展方向和维护由商业公司主导，并由商业公司以此作为其“开源”或“双许可证”（dual-licensing）模式下的主要收入来源。在「核心开源」（open-core）这一开源生态系统模式中，软件供应商借由商业许可证售卖自由和开源软件（Free and Open Source Software）项目的附加组件或服务（译者注：例如数据库软件 Redis 以 BSD 许可证发布其核心项目，但其另以商业许可证发布包含更多功能的企业版）。在双许可证模式（译者注：例如，此前由 Oracle 主导的数据库软件 MySQL 以 GNU GPL 许可证发布其社区版本，并另外以专有许可证提供企业版本）中，软件供应商以FOSS许可证发布软件且附加某些使得其它企业难以利用的限制——这通常是要求满足特定义务（译者注：例如 Copyleft 式许可证强制被授权者以同样的许可证发布其衍生作品），并另行在商业许可证下提供相同的软件。这两种模式都利用开源以实现指数级增长。今天抢到免费且开放的产品的开发者就会是明天的付费客户（或为后者工作）。

随着云的增长，这两种模式都面临挑战。从服务器机房到数据中心的转变使云服务商得以凭借开源许可证利用基于「核心开源」或「双许可证」模式的开源项目，这通常是应客户期望——客户想从一家公司买到所有服务。这使基于「核心开源」或「双许可证」模式的业务面临风险：云服务商突然与用户建立了更近关系，从而使这些依赖特定开源生态模式的软件供应商更难与其潜在客户建立销售关系。

为了应对这种压力，许多依赖「核心开源」或「双许可证」业务的公司，包括 Confluent、MongoDB、Cockroach Labs、Redis Labs、Timescale 和 Graylog，从 OSI 批准的开源许可证离开，转而采用不「开放」源代码的许可证。这些新的“源代码公开”（而非「开放」）许可证包含进一步限制，以防止云基础架构提供商利用其代码构建服务（而不付费）。诸如 Commons Clause 许可证之类的初期尝试广泛地限制了“商业用途”，并且用户发现许可证中的文字“造成了一些混乱和不确定性。” Elastic 等公司最近的努力则更直接（more surgical）。他们简单地试图限制用户单独将软件作为服务。这些新许可证的目标是继续利用该软件及其源代码的广泛可用性（译者注：即公开而不开放）来获得未来的客户，同时遏制利用公开代码的盈利的 SaaS （软件即服务，Software as a Service）服务竞争者。

这对开发人员意味着什么？

那么，开发人员该怎样选择技术栈？了解项目所有权状况和贡献者群体的多样性很重要。由非营利组织管理、商标所有权中立且主要贡献者有多方的开源项目不太可能面临更改许可证的压力。由营利性公司主导的作为其主要收入来源的开源项目则可能走向与此不同的方向。任何营利性公司都需要营利。如果你依赖此类项目，那你就可能会面临以营利为目的的公司出于保护其业务的目的而更改项目许可证的可能性。

在 Twitter 关注 GitHub 政策以获取有关影响开发人员的法律和规定的消息。

本文是一篇译文，原文是 GitHub 博客中的「What’s up with these new not-open source licenses? 」，原文作者是 GitHub 政策团队的 Justin Colannino。标题或正文的部分细节内容可能因不便直接直译而略有改动。若有疏失，烦请通过后文所注明的邮箱告知。

封面图片转载自 Unplash，摄影者是 Richard Balog。