什么是开源许可证，它们如何运作？以下指南适用于创作者、用户以及其他想要参与这场精彩的开源运动的人士。
译自How Do Open Source Licenses Work? The Ultimate Guide，作者 B Cameron Gain。
我为什么要关心开源许可证？
无论您是通过使用、贡献还是创建来参与开源代码，您都应该关心开源许可证。创建者设置的许可证对于尊重创建者和贡献者社区的意图至关重要，它影响着诸如使用、商业化、分发和其他项目属性等方面。
也就是说，本终极指南无意作为法律建议或用作开源业务计划或使用希望的法律指南。我们在这里的目的是描述开源许可证以及它们对创建者和用户意味着什么，扩展到企业家、爱好者、研究人员或任何其他希望单独参与这一开源运动的人。
什么是开源许可证？
开源许可证用于提供条款来尊重创建者或创建者的意图，并确定在某些方面允许和限制的许可证下的开源代码的使用。对于用户而言，它有助于提供有关如何在尊重许可证的情况下使用、利用或共享代码的指导。
开源倡议组织(OSI) 规定，一个项目必须拥有符合 OSI 定义的特定许可证才能被视为开源。符合OSI 定义的开源许可证"允许软件被自由使用、修改和共享"。OSI 列出了 100 多种不同的许可证。
当一个项目正在考虑获得特定许可证时，它可以经历OSI 的许可证审查流程。正如 OSI 在其文档中所描述的，该流程旨在确保已批准的许可证遵守开源定义并保证软件自由。OSI 表示，其目的是阻止"重复"和制定不当的许可证以及那些具有意外要求的许可证的扩散。
最流行的许可证属于不同的类别。属于 OSI 流行许可证类别且拥有 OSI 认为拥有强大社区的许可证包括：Apache 许可证、通用开发和分发许可证、Eclipse 公共许可证、GNU 通用公共许可证的各种版本、Mozilla 许可证、BSD 许可证以及当然还有流行且特别宽松的MIT 许可证。
出于本解释性文章的目的，我们将介绍 OSI 许可证。但是，除了 OSI 之外，还有其他专家组提供属于开源、免费或免费和开源的软件许可证的清单和说明。其中一个实体是 Debian 项目，这是一个由 Debian 项目开发的 Linux 发行版。它提供免费和开源软件以及非免费软件。
另一个值得一提的项目是 Fedora 项目，它为 Fedora Linux 的开发做出了贡献，由Red Hat维护。它提倡一个具有世界意识、开源、免费和开源软件环境，由一群欢迎、思想开放的人员构建，他们支持当今的文档。
项目创建者选择的许可证类型应由法律顾问确定，因为进入版权法领域需要与项目创建者的意图保持一致。只有合格的法律顾问才能提供与项目创建者想要实现的目标相对应的许可证类型。
同时，在流行许可证中，MIT 许可证相对宽松。它允许用户自由地分叉或复制代码，从而在如何使用代码方面提供了灵活性。这与所谓的"copyleft"许可证（如 GNU 通用公共许可证）形成对比，后者施加了更多规定。根据OSI 对 GNU GPL 的定义，权利受到两步保护：
(1) 对软件主张版权，以及 (2) 向您提供此许可证，授予您复制、分发和/或修改软件的合法许可。
为了保护开发者和作者，GPL 明确解释说，此免费软件不提供任何保证。为了用户和作者的利益，GPL 要求将修改版本标记为已更改，以便不会错误地将问题归咎于以前版本的作者。
"开源软件的一大优点是，开放源代码促进会批准的许可证已标准化，符合开放源代码定义。这意味着，许多对开源许可证有基本了解的人无需向法律顾问寻求建议，而通常可以依赖许可证条款既定的含义，"Amanda Brock，OpenUK的首席执行官告诉 The New Stack。"这种可靠性和标准化是开源软件自由流动的重要组成部分。"
然而，布洛克说，只有在您理解许可证的情况下才会出现这种情况。"了解 copyleft 和宽松许可证的含义是此问题的核心，"Brock 说。虽然大约有 80 个已批准的许可证，但只有少数几个最常用，而且了解这些许可证以及人们使用它们的原因通常就足够了。
开源许可证与自由软件许可证相比如何？
开源可以等同于自由软件，但在某些情况下不符合某些定义。两者都定义为代码开放且自由使用，但受特定许可证条款的约束。
在自由软件基金会的清单中，它提供了自己的开源和自由软件许可证。FSF 将自由软件定义为：
尊重用户自由和社区的软件。粗略地说，这意味着用户有权运行、复制、分发、研究、更改和改进软件。因此，"自由软件"是自由的问题，而不是价格问题。要理解这个概念，您应该将"free"视为"言论自由"，而不是"免费啤酒"。
然而，OSI 的开源软件许可证下有一些组件或清单，FSF（自由软件基金会）不认为是免费的。免费软件和开源软件都属于所谓的 FOSS（免费和开源软件）范畴。
是否可以更改许可证？
更改许可证的过程可能复杂且具有挑战性，这强调了最初选择正确许可证的重要性。更改开源项目的许可证时，新许可证通常必须遵守或与原始许可证兼容，具体取决于其条款。
确保更改与版权持有人在项目中的权益保持一致至关重要。这个复杂的过程需要合格法律顾问的指导。建议从项目的开始就建立适当的许可，以避免以后出现复杂情况。
有哪些值得注意的许可证更改示例？
2023 年 8 月，HashiCorp 透露它正在更改其领先的 Infrastructure as Code 平台Terraform的许可条款。它用商业源代码许可证 (BSL) v1.1 替换了其开源 Mozilla 公共许可证 v2.0 (MPL 2.0)，该许可证限制了在生产中使用代码。
这一决定引发了争议，并出现了一个开源分支项目作为回应：开源等效项 OpenTofu，一个 MPL 许可的分支版本 Terraform 代码OpenTofu在 Linux 基金会支持下，OpenTofu 1.6 与原始 Terraform 相比增加了功能，并获得了社区的大力支持，于 1 月份普遍可用。
值得注意的是，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 上共享或通常经常共享，但代码的创建者拥有该代码。它也不属于Microsoft的 GitHub 或GitLab。
正如GitHub 所述，当其他创建者做出贡献且他们不再能够使用该代码时，创建者会面临进一步的危险："当你创作作品（包括代码）时，该作品默认受到独家版权保护。除非你包含指定其他情况的许可证，否则任何人都不能在不冒被撤除、勒索或诉讼风险的情况下复制、分发或修改你的作品。一旦作品有其他贡献者（每个人都是版权持有人），'任何人'就包括你在内。"
不同的许可证提供不同程度的保护和自由，用户应仔细查看通常在 LICENSE.txt、LICENSE.md 或 LICENSE.rst 文件中或在 GitHub 上的 README 文件中找到的规定。了解许可证有助于确定你可以根据指定限制如何使用、分发、使用、复制或修改代码。
在 GitLab 上为开源项目激活许可证时，该平台提供了一个用户界面。与 GitHub 不同，创建者必须以 GitLab 管理员身份登录。在界面中，用户可以选择他们希望添加的许可证类型，并在此过程中选中一个复选框进行选择。
当存储库被分叉（Fork）时，许可证会发生什么？
如果存储库中未包含许可证，则根据上述内容，代码默认属于用户。但是，Fork 一个项目不会改变许可证模型；许可证规定仍然保留在 GitHub 等平台上。你对 Fork 代码拥有的选项由原始许可证模型决定。严格的许可证可能会限制你的使用或分发，但允许你通过建议的更改或拉取请求将更改回馈给父存储库。
使用像 MIT 这样的宽松许可证，你可以使用 Fork 中的代码来创建完全不同的开源项目，即使名称不同，甚至可能使用更具限制性的许可证。可用的选项会根据现有的许可证而有所不同。
在哪个许可证上构建业务是最佳选择？
这是一个价值百万美元或实际上价值数十亿美元的问题。围绕开源的业务策略各不相同，并且没有模板可以说明什么构成了商业上成功的开源项目。例如，将开源项目作为业务的核心，然后在其之上提供企业功能已被证明具有挑战性，特别是考虑到有限的风险投资资金和当今建立可行业务的更短跑道。因此，简短的答案是这取决于具体情况。
作为 Kubernetes 专家Kelsey Hightower经常强调，由于创始公司和社区的大量努力和投资，已经产生了出色而强大的开源项目。然而，成功实现企业版本的盈利仍然是一道难以跨越的鸿沟。
在大型开源项目领域，许多成功的项目最初并不是为了形成商业模式的基础而创建的。相反，它们间接地促进了商业模式或用于解决技术问题，吸引了额外的资源和投入。例如，Envoy是拼车公司 Lyft启动的服务代理，已成为 Kubernetes 最成功的开源项目之一。Kubernetes 本身由谷歌推出，形成了云原生运动的基础，尽管谷歌最初并不是云提供商。
然而，无论项目创建者对开源项目的目标是什么，成功都取决于从一开始就获得正确的许可证模型。
围绕项目分叉的一些争议是什么？
几年前，亚马逊网络服务的做法引发了一个重大问题。亚马逊试图将 MongoDB 等成功的开源项目商业化，将其作为其云服务的一部分提供版本并收取商业支持费用，从而将开源创建者变成了 AWS 客户的竞争对手。这导致了争端和紧张局势。另一个例子涉及 Elasticsearch，它选择使其代码专有。作为回应，亚马逊分叉了该项目，将其变为专有并提供付费服务，从而引发了 Elasticsearch 的批评。
然而，一些观察人士表示，AWS 此举对于对抗 Elasticsearch 使用这些开源项目的商业模式是必要的。
AWS 当然有权在重新标记开源工具和平台并提供付费服务以帮助使用和管理代码（取决于许可证）的同时，获取多年来致力于开源项目的奉献和辛勤工作所构建的代码。然而，一些观察人士表示，这家云计算巨头冒着被认为背叛了其客户和那些帮助创建这些项目的人的风险。
如上所述，AWS 在 2019 年开始将其云服务的一部分提供 MongoDB 并为 MongoDB 提供商业支持服务时，在开源社区引起了争议。与此同时，MongoDB 目前提供基于其开源堆栈的商业服务，如上所述。Elastic 选择放弃 Elasticsearch 和 Kibana 的 Apache 2.0 许可证，并用"Elastic 许可证"和服务器端公共许可证 (SSPL) 取代它们，从而为 Elasticsearch 发起了更商业化的商业模式。
Elastic 在一封电子邮件声明中写道：
"通过整合我们从经验中获得的所有经验教训以及面临类似决策的其他公司，Elastic License v2 (ELv2) 的推出为市场提供了急需的澄清。此后，我们扩展了我们的产品，例如 Elastic Cloud 和 Elastic 堆栈中的其他工具，并允许客户在其最喜欢的公共云或多云环境中部署 Elastic 产品。这种战略调整反过来又促进了 Elastic 与云提供商（如亚马逊网络服务、Microsoft Azure 和 Google Cloud Platform）之间更牢固的合作伙伴关系，使我们的联合客户能够更多地受益于我们在技术创新方面的共同投资。"
本文在云云众生（yylives.cc/）首发，欢迎大家访问。