无论你是通过使用、贡献还是创建等方式参与开源项目，您都应该关心开源许可证。创建者设定的许可证，影响了该项目使用、商业化、发行版和其他项目属性等内容，对尊重创建者以及贡献者社区的意向起到至关重要的作用。

基于此，本终极指南（译者注：原文标题为“How Do Open Source Licenses Work? The Ultimate Guide”，即“开源许可证如何运作？终极指南奉上”。）无意作为法律建议，也无意用作商业计划或开源使用意向者的法律指导。本文旨在描述开源许可证以及其对创作者和用户的意义，并延伸到企业家、爱好者、研究人员或任何其他想要单独参与这一开源运动的用户。

开源许可证用于提供尊重创建者意图的条款，并确定在许可证下允许和限制开源代码的使用范围。对用户来说，开源许可证有助于指导他们如何在尊重许可证的前提下使用、开发或共享代码。

开源倡议(OSI,Open Source Initiative) 规定项目必须拥有符合 OSI 定义的特定许可证才能被视为开源。符合OSI开源定义的许可证“允许自由使用、修改和共享软件”，OSI 的清单包括超过100种不同的许可证。

可以通过OSI 的许可证审查流程，获取项目采用特定许可证的相关信息。正如 OSI 在其文档中所述，该流程旨在确保批准的许可证遵守开源定义并保证软件自由。OSI 表示，其目的是阻止“重复”和不完善的许可证以及那些具有意外要求的许可证的扩散。

当前最流行的许可证分属不同类别。属于 OSI 流行许可证类别的许可证包括：Apache 许可证、通用开发和发布许可证、Eclipse 公共许可证、各种版本的 GNU 通用公共许可证、Mozilla 许可证、BSD 许可证，当然还有流行且特别宽容的 MIT 许可证。

本文将介绍 OSI 许可证。然而，除了 OSI 之外，还有其他专家组提供属于开源、免费或免费和开源的软件许可证的列表和描述。Debian 项目就是这样的一个实体，它是由 Debian 项目开发的 Linux 发行版。它既提供自由和开源软件（自由软件，Free Software，表示那些赋予用户运行、复制、分发、学习、修改并改进软件等自由的软件），也提供非自由软件。

另一个值得一提的项目是 Fedora 项目，该项目为开发由 Red Hat 维护的 Fedora Linux 做出了贡献。该项目倡导一种由热情开放、支持现有文档的社区构建，具有世界意识的、开放源代码的、促进了一个具有世界意识的、开源的、自由的和开源软件的环境。

项目创建者选择何种许可证应由法律顾问决定，因为进入版权法领域需要与项目创建者的意图保持一致。只有合格的法律顾问才能提供许可类型，许可类型应与项目创建者想要实现的目标相一致。

同时，在流行的许可证中，MIT许可证相对宽松。它允许用户自由地分叉或复制代码，为用户提供了使用代码的灵活性。这与 GNU 通用公共许可证等所谓的“受版权保护”许可证形成鲜明对比，后者施加了更多规定。根据OSI 对 GNU GPL 的定义，通过以下两个步骤可以保护权利：

(1) 主张软件的版权；

(2) 向您提供本许可证，授予您复制、分发和/或修改该软件的合法许可。

为了保护开发者和作者，GPL 明确说明不为该自由软件做任何担保。为了用户和作者的利益，GPL 要求修改后的版本被标记为已更改，这样就不会将其问题错误地归咎于先前版本的作者。

“开源软件的优点之一是，经开源计划批准符合开源定义的许可证实现了标准化。这意味着许多对开源许可证有基本了解的人不需要向法律顾问寻求建议，而通常可以信赖许可证条款的既定含义。” OpenUK首席执行官 Amanda Brock 在 外媒The New Stack 的采访中回答道，“这种可靠性和标准化是开源软件自由流动的重要组成部分。”

然而，Brock说，只有当你了解许可证时才能做到这一点，“了解 Copyleft 和许可协议的含义是核心所在。”虽然大约有 80 个已批准的许可证，但最常用的只有少数几种，一般来说，了解这些许可证以及人们使用它们的原因通常就足够了。

开源可以等同于自由软件，但在某些情况下不符合某些定义。两者的定义都是代码是开放且可自由使用的，但要遵守特定许可证的条款。

自由软件基金会（Free Software Foundation）的列表提供了自己的开放源代码和自由软件许可证，基金会将自由软件定义为：

尊重用户自由和社区的软件。粗略地说，这意味着用户可以自由地运行、复制、分发、研究、更改和改进软件。因此，“自由软件”的“Free”意为自由而非免费。要理解这个概念，你应该将“Free”视为“言论自由（free speech）”，而不是“免费啤酒（free beer）”。

然而，OSI 开源软件许可证下的某些组件或列表，在FSF（自由软件基金会）看来，并不是自由的。自由和开源软件都属于所谓的 FOSS（Free and Open Source Software，自由和开源软件）范畴。

更改许可证的过程可能既复杂又具有挑战性，这就突出了最初选择正确许可证的重要性。更改开源项目的许可证时，新许可证通常必须符合或兼容原始许可证，具体取决于其条款。

确保变更与版权所有者在项目中的利益一致相当重要，这一复杂过程需要专业法律顾问的指导。建议从项目一开始就建立适当的许可，以避免以后出现复杂性。

2023 年 8 月，HashiCorp 透露正在更改其领先的基础设施即代码平台 Terraform 的许可条款。它用商业源代码许可证 (BSL) v1.1 取代了开源 Mozilla 公共许可证 v2.0 (MPL 2.0)，前者限制在生产中使用代码。

这一决定引发了争议，一个开源分叉项目应运而生：在 Linux 基金会的支持下，Terraform 代码OpenTofu 的 MPL 许可分叉版本——开源等效的OpenTofu 1.6于 1 月份全面上市，与之前的版本相比，与最初的 Terraform 相比增加了一些功能并得到社区的大力支持。

值得注意的是，Grafana Labs 也曾调整过开源项目的许可证。这一举措发生在 2022 年，当时 Grafana 决定放弃对 Cortex 的支持，并推出替代方案，在时间序列数据库上可视化 Prometheus 的指标。

于是，Mimir 采用了 AGPLv3 许可，而不是 Cortex 的 Apache2 许可。许可方案的改变也是为了鼓励更多的贡献，或 Mimir 用户以比 Cortex 用户更稳健的方式做出贡献。Grafana Labs 表示，Grafana、Tempo 和 Loki 也使用 AGPLv3 许可证。

HashiCorp 和 Grafana 决定提供更严格的许可证，这是继 2018 年 Redis Labs 和 MongoDB 选择修改开放许可，限制其开源产品代码用于生产以获取商业利益之后开始出现的趋势。同样改变了开源项目许可条款、变得不那么放任的企业还有 Confluent 和 Cockroach Labs。它们改用了 BSL，这意味着代码可开放自由地被用于非商业目的，而不能被用于生产。

答案是否定的。事实上，许可证有助于定义和确定你的开源项目。虽然代码可以在 GitHub 或 GitLab 上共享或长期共享，但代码的创建者拥有代码所有权，该权利不属于微软的 GitHub 或GitLab。

正如GitHub 指出的那样，当其他创作者做出贡献，创作者将面临进一步的危险：“当你制作创意作品（包括代码）时，该作品默认享有专有版权。除非您包含另有指定的许可证，否则任何人都不能复制、分发或修改您的作品，而不会面临被下架、勒索或诉讼的风险。一旦作品有了其他贡献者（每个人都是版权所有者），“没有人”开始包括你。”

正如 GitHub 所言，当其他创作者贡献了代码，而自己却无法再使用代码时，创作者将面临进一步的危险：“当你制作创意作品（其中包括代码）时，该作品默认拥有独家版权。除非你在许可证中另有规定，否则任何人都不能复制、传播或修改你的作品，否则就会面临被盗用、下架、勒索或诉讼的风险。一旦作品有了其他贡献者（每个贡献者都是版权持有者），‘任何人’的范畴就开始包括你。”

不同的许可证提供不同程度的保护和自由，用户应仔细查看其规定，这些规定通常可以在 LICENSE.txt、LICENSE.md 或 LICENSE.rst 文件或 GitHub 上的 README 文件中找到。了解许可证有助于确定如何根据指定限制使用、分发、使用、复制或修改代码。

在 GitLab 上激活开源项目的许可证时，该平台会提供一个用户界面。与 GitHub 不同，创建者必须以 GitLab 管理员身份登录。在界面上，用户通过复选框选择要添加的许可证类型。

如果版本库中没有包含许可证，则如上所述，代码默认属于用户。然而，分叉项目并不会改变许可证模式；许可规定仍然保留在 GitHub 等平台上。您对分叉代码的选择取决于原始许可证模型。严格的许可证可能会限制您的使用或分发，但允许您通过建议的更改或拉取请求将更改贡献回父存储库。

借助像 MIT 这样的宽松许可证，您可以使用分叉中的代码创建完全不同的开源项目，甚至可以使用不同的名称和限制性更强的许可证。根据许可证的不同，可用的选择也会不同。

这是一个百万美元级别——实际上是十亿美元级别——的问题。以开源为中心的商业策略各不相同，并且没有一个模板来说明怎样才能使一个可行的开源项目取得商业成功。例如，将开源项目作为业务的核心，然后在此基础上提供企业功能，这一方案已被证明具有挑战性，尤其是考虑到风险投资资金有限，且如今建立可行业务的跑道较短。所以，简短的回答是，需要视情况而定。

正如 Kubernetes 专家Kelsey Hightower经常强调的那样，通过创始公司和社区的巨大努力和投资，已经出现许多出色而强大的开源项目。然而，企业版的成功货币化仍然是一座难以跨越的桥梁。

在大型开源项目领域，许多成功的项目最初并不是为了形成商业模式的基础而创建的。相反，它们间接地为商业模式做出了贡献，或者被用来解决技术问题，吸引了额外的资源和投入。例如，由共享出行公司 Lyft发起的服务代理Envoy成为Kubernetes 最成功的开源项目之一。尽管谷歌最初并不是云提供商，但由谷歌推出的 Kubernetes 本身为云原生运动奠定了基础。

然而，无论项目创建者对开源项目的目标如何，成功的结果都取决于从一开始就获得正确的许可模型。

几年前，亚马逊网络服务公司（Amazon Web Services）的实践出现了一个重大问题。亚马逊一直在寻求将MongoDB等成功的开源项目商业化，提供一个版本作为其云产品的一部分，并收取商业支持费用，从而将开源创建者转变为 AWS 客户的竞争对手，导致纠纷和紧张关系。另一个例子是Elasticsearch，该公司将其代码专有化。作为回应，亚马逊分叉了该项目，使其成为专有项目并提供付费服务，此举引发了 Elasticsearch 的批评。

然而，一些观察人士表示，AWS 此举是必要的，以对抗 Elasticsearch 使用这些开源项目的商业模式。

AWS 当然可以合法地获取多年来致力于开源项目的奉献和辛勤工作所构建的代码，同时重新命名开源工具和平台，并提供付费服务来帮助使用和管理代码（取决于许可证）。然而，一些观察人士表示，这家云巨头面临着被视为背叛客户和项目贡献者的风险。

如上所述，AWS 在 2019 年开始在其云产品中提供 MongoDB 并为 MongoDB 提供商业支持服务时，在开源社区引起了争议。与此同时，MongoDB 现在提供基于其开源堆栈的商业服务。Elastic 选择放弃 Elasticsearch 和 Kibana 的 Apache 2.0 许可证，代之以“Elastic 许可证”和服务器端公共许可证 (SSPL) ，从而启动了更加商业化的商业模式。

Elastic 在电子邮件声明中写道：

“Elastic License v2（ELv2）的推出结合了自身经验和其他面临类似决定的公司的经验，为市场提供了亟需的澄清。此后，我们扩大产品范围，如 Elastic Cloud 和 Elastic 堆栈中的其他工具，并允许客户在他们喜欢的公共云或多云环境中部署 Elastic 产品。这种战略调整反过来又促进了Elastic与亚马逊网络服务（Amazon Web Services）、微软Azure和谷歌云平台（Google Cloud Platform）等云提供商之间更牢固的合作关系，使我们的共同客户能够从我们共同的技术创新投资中获益更多。”