开源许可证的思考：理想主义与现实主义的 battle - 文章 - 开发者社区

文章内容仅代表个人观点，不构成任何法律意见，如有法律相关问题，请咨询律师或者公司法务。

文章来源｜字节跳动基础架构团队

在当今数字时代，开源软件的普及和影响力日益增长，使得选择适当的开源许可证成为软件开发领域的一个关键决策。开源许可证的思考不仅仅是技术层面的问题，更是对 知识产权 、 社区合作 和 创新模式 的深刻思考。而源码公开的许可包括开源、Source Avaibale 以及介于两者之间的许可模式。

本文将探讨基于 copyright（版权）的 Copyleft（版权左转） 和 Non-copyleft（Permissive） 两类主要的开源许可方式，以及商业源码许可（ Source Available ，也被称为 半开源或变种开源许可 ），剖析它们的优势与劣势，以及在不同场景下的适用性。

通过深入了解这些许可证的工作原理和影响，我们将能够更好地理解如何在开源项目中平衡创作者权益和社区自由，为开源社区的可持续发展和开源许可证的选型提供有益的参考，在 理想主义 与 实用主义 之间做一个选择或者妥协。

picture.image

0 1

Copyright

在软件和开源领域，Copyright（版权）是一个非常重要的概念，它与软件的创作、分发和使用密切相关。

而开源许可证的目的是保护开源软件的知识产权，同时促进软件的自由使用、修改和分发，是一种法律许可。开源许可证的种类很多，通常来说，我们会把其分为宽松型 / 声明型许可证和（弱 / 强）限制性许可证，在这篇文章里面，我希望用更专业一点的术语来表达，Permissive 和 Copyleft。此外，为了更好地保护了软件专有功能和知识产权，同时鼓励付费订阅以获得额外的增值服务，近些年来出现了半开源或变种开源许可，在业界形成了一定的争议，有人认为其限制了开源软件的自由使用，违背了开源精神。

Permissive Licenses

Permissive Licenses 是指宽松型许可证，也称为非传染性许可证。这类许可证允许用户自由使用、修改、共享和分发软件，并且不强制要求用户将修改后的软件开源。

优点：

自由度高：允许用户自由使用、修改、共享和分发软件，并且不强制要求用户将修改后的软件开源。
商业友好：这些许可证对商业使用也非常友好，用户可以将软件用于商业目的，并且不需要公开源代码。
简单易懂：这类许可证通常比较简单易懂，不需要用户过多地了解法律术语和细节。
促进创新：由于这类许可证允许用户自由修改和分发软件，因此可以促进软件的创新和发展。

缺点：

知识产权问题：如果用户修改了使用 Permissive Software Licenses 的软件，并将其分发出去，那么可能会涉及到知识产权问题。以 MIT 为例，如果修改后的软件中没有正确保留原始的 MIT 许可证和版权声明，这可能构成违反许可证的行为。需要详细审查许可证要求，确保对原始软件的修改和分发都遵循了原始许可证的规定。
不利于知识自由传播：由于这类许可证不强制要求用户将修改后的软件开源，因此可能会导致一些商业公司基于开源项目的修改和优化封闭在公司内部，不往上游贡献，限制了知识的自由传播和开源项目的发展，衍生软件可变为专有软件。这也对应了为什么会有 “Upstream First” 这一呼吁，因为这类协议本身没有强制。

例子：

Apache License 2.0 ，宽松许可证，常见于 Apache 软件基金会的项目，也用于 TiDB、CloudWeGo 等项目。

注：虽然 Apache License 2.0 是一种相对宽松的许可证，但它仍然基于版权法，同时也基于专利法，并规定了在遵循一些条件的情况下允许使用、修改和分发软件的条款。Apache License 2.0 允许用户在遵循一些基本的条件和限制的情况下使用和分发软件，包括用于商业用途，但与一些更严格的版权保护不同，它不强制对衍生作品采用相同的许可证。因此，Apache License 2.0 在一定程度上属于“Permissive（宽松）”类别的开源许可证。 2. MIT License，宽松许可证，用于许多小型和大型开源项目，如 Node.js、Ruby on Rails 等。

BSD-2-Clause License & BSD-3-Clause License，宽松许可证，允许自由使用、修改和分发，如 PostgreSQL。

Copyleft Licenses

Copyleft 是一种使用版权法的方法，旨在确保作品及其派生作品的源码自由使用、修改和分发。Copyleft 强制要求将基于受保护作品创建的衍生作品在对外分发时，也使用相同或类似的许可证对接收者提供源码 ，从而保持自由性。Copyleft 通常与开源软件关联，确保源码的自由流通，并防止将其变成专有软件。

优点：

自由传播：通过强制要求使用相同或类似开放许可证，促进了信息和知识的自由传播，保护了用户的使用权利。
社区合作：鼓励开源社区合作，因为每个人都可以查看、修改和共享源代码。
避免封闭性商业模式：防止将开源项目私有化，避免了封闭性商业模式的出现。

缺点：

许可限制：有时可能对商业利用设置一些限制，使得一些商业用途受到限制。
可能引起法律问题：由于 Copyleft 要求派生作品使用相同或类似的许可证，可能导致与某些专有软件或其他许可证不兼容，引发法律纠纷。
限制创作者权益：某些创作者可能认为 Copyleft 限制了他们对作品的控制权，阻碍了他们从作品中获得经济利益的可能性。

例子：

GPL（GNU 通用公共许可证），Copyleft 许可证，要求派生作品也采用相同的 GPL 或兼容许可证，确保源代码的开放性。Linux 内核、GNU 工具集、Git、MySQL 均采用 GPL 协议。
LGPL（GNU 宽通用公共许可证），Copyleft 许可证，相对于 GPL，LGPL 对于一些库和组件的使用更为灵活，允许链接到非 LGPL 软件中而不要求整个作品都使用 LGPL。
MPL（Mozilla 公共许可证），也是一种开源软件许可证，类似于 LGPL，但对于一些作品的链接和组合更加灵活。

Source Available

在某些条件下，软件对外发布并提供了开源的部分（Source Available），但在另一些条件下，对于商业使用可能有一些限制。这使得它与传统的开源 Permissive（如 MIT、Apache）和 Copyleft（如 GPL、MPL）许可证有所不同，被称为 半开源或变种开源许可证 。

最典型的例子 - Business Source License（商业源代码许可证，BuSL），以下是其关键特征：

目标：在“开源”软件的 用户利益 （免费并提供对所有产品代码的修改、分发等的开放访问）和软件开发人员 继续交付 产品创新和 维护的可持续性 需求之间提供互利的平衡。
阶段性开源：商业源代码许可证通常将软件的源代码在一开始或某个特定的时间节点开源，这意味着在一定时间内，软件的源代码对一般公众来说是不完全开放的。在一定时间段过后， 商业源代码许可证可能会过渡到一个开源许可证（Copyleft or Permissive） ，使得软件在后续的时间里成为真正的开源项目。
商业使用的限制：在软件尚未完全开源之前，商业源代码许可证可能对商业用途施加一些限制，例如， 对于商业用户可能会有付费 或特殊许可条件。
不同版本：商业源代码许可证的确切条件可能因许可证版本而异，因此具体的条款可能会有所不同。

典型案例 1：MariaDB Community Server （BuSL 的诞生之地）

MariaDB Community Server 根据 GNU Public License v2 发布。纵观其历史，MariaDB 一直表明其对开源和开源社区的承诺。MariaDB Community Server 保证永远开源。
商业开发的组件，例如 MariaDB 的 MaxScale，是根据商业源代码许可证（BuSL）发布的。源代码始终可见，经过一段时间后，许可证转换为 GPL，确保软件永远可供社区使用。
可以在生产环境使用，但是单个应用不能部署超过三个节点。
限制了大规模集群的场景，允许个人用户和小企业用起来，做产品反馈和帮助传播。对于需要维护大集群的用户，通常也是更有实力付费的用户，限制其使用，促使他们谈判商业合同付费购买使用许可。

典型案例 2：HarshCorp 将整个产品组的未来版本从 Mozilla Public License 切换到 Business Source License

HashiCorp 在 BuSL 里面是这样描述的：“不能把被许可的软件用在向第三方提供和 HashiCorp 产品存在 竞争的服务 上。”其中“跟 HashiCorp 存在竞争”是一个非常模糊的说法，如果你不清楚是否违规，需要联系他们的律师。HashiCorp 选择了四年的“保护期”，到期后，变更到此前它们采用的 Mozilla Public License 2.0 协议。
HashiCorp 并没有在一开始就使用 BuSL 或商业收费的版本，而是在基于 MPL 开源协议和开源社区取得了开源的成功后，再基于商业诉求切换 BuSL，这一行为在市场形成了较大的争议，诸如 “诱捕并切换” 、“欺诈”、“诱导转向的伪开源”。根因在于创始人并没有在开源之初就想好后续的盈利模式以及软件生命周期延续模式。 商业模式需要在项目开源早期完成设计。
近年来，我们看到的趋势是，许多企业（MongoDB、Elastic、HashiCorp）从开放核心模式（Open Core）退回到源码可得模式（Source Available）。在源码可得模式下，你可以查看所有的代码，但在某些情况下你不能修改或使用它。尽管这些向非开源许可的转变惹怒了一些用户和很多开发者，但 这些公司的业绩仍表现相对稳定 。你可能对此感到不满，但事实是，对于这些公司来说，这种转变在一定程度上取得了成功。

许可证与商业化

Copyright 是一种保护知识产权的方法，强调并保护原创作者的权利。

根据《大教堂与集市》的观点，在 开源许可证 授权下的开源项目，更容易获得社区与开发者参与，更容易获得用户和反馈，更容易做大做强。而且从趋势上来说，诸多基础架构和中间件领域的软件必将走向开源，现在看来，越来越多中间件以及一些应用工具确实都开源了，比如各种语言的库、Web 应用框架、图像处理、AI 框架等。从用户落地和项目推广层面来看，开源项目已经取到了举世瞩目的成功，但是从初创团队的商业化视角来看，缺乏典型的成功案例。有一种观点是， 开源就是把蛋糕做大 ，大家一起来分蛋糕，好过于大家都吃不到蛋糕。商业化，从来不是一件容易的事。

Permissive Software Licenses 是宽松型许可，常用于 学术分享、制定标准、技术影响力、没有明确商业化诉求的小型项目以及个人项目等 。当然，他对于商业化是友好的，也有很多云厂商或者初创团队在这个许可证之上构建商业产品或服务，但是竞争对手之间往往 缺乏技术壁垒 ，根据个人观察，初创团队在商业化层面容易吃亏。
Copyleft 是一种通过版权法促进自由分享和修改的方法，鼓励在一定条件下允许他人使用、修改和分享作品，其许可证是互惠性（分为强互惠和弱互惠）的。如果对外分发软件就需要对接受者分发源码，促进了信息和知识的自由传播。有开源布道师认为 Copyleft 是伟大的发明，因为它代表了开源的一种理想主义和自由主义。但也正是由于 该许可证是互惠的（传染的），在商业公司内使用时通常会有很多限制和顾虑 （分发时要求对外开源以及其带来的一系列合规成本与开发工作），这恰恰从一个方面论证了开源不等于免费，使用开源软件需要遵循其开源协议的一系列义务以及其它合规成本。商业化层面，它在避免开源项目私有化的同时，也限制了创作者对作品的控制权。

在 半开源或变种开源许可证（Source Available） 授权下的项目，其源码开放，但对于一定规模商业场景下使用有所限制，需要购买商业授权，从这一点来说对于优质软件的创作者团队是很有利的，这是知识产权的 直接变现 。有得必有失，正因为其明确的利益链条，往往很难吸引社区开发者来参与贡献与共建，项目往往与单一 vendor 强绑定，项目发展也强依赖于创作者团队持续投入。随着云厂商的介入以及大环境的竞争变剧，对基于 “开源”项目的创业公司 以及 考虑商业变现的商业公司 来说，支持服务和托管服务变得更加困难，选择 Source Available 或 开闭源组合模式 成为重要的趋势之一。

致谢：感谢字节跳动 OSPO 开源法务 @孙振华 提供的 review 意见和错误纠正。

【参考资料】

[1] Apache License: https://www.apache.org/licenses/LICENSE-2.0

[2] MIT License: https://opensource.org/license/mit/

[3] BSD-2-Clause License: https://opensource.org/license/bsd-2-clause/

[4] BSD-3-Clause License: https://opensource.org/license/bsd-3-clause/

[5] GPL: https://www.gnu.org/licenses/gpl-3.0.html

[6] LGPL: https://www.gnu.org/licenses/lgpl-3.0.html

[7] MPL: https://opensource.org/license/mpl-2-0/

推荐阅读

字节跳动研发开源合规基础