常见开源协议综合介绍与对比

前言

在当今数字化浪潮的推动下，软件开发已成为全球创新的重要引擎，而开源软件则如同璀璨星辰，照亮了这一领域的前行之路。开源协议，作为开源软件的基石，宛如一把把精巧的钥匙，打开了代码共享、技术协作的大门，让无数开发者能够站在巨人的肩膀上，加速技术的迭代与创新。这些协议不仅仅是一行行法律文本，更是开发者之间达成的默契共识，它们承载着代码传播、使用的规则，平衡着自由与权益、开放与商业的微妙关系。
从诞生之初，开源协议便肩负着推动技术普惠的使命。它们让优质代码得以跨越地域、组织的界限，在全球范围内自由流动。无论是个人开发者还是大型企业团队，都能从开源代码宝库中汲取养分，避免重复造轮，将精力聚焦于核心创新。试想，没有开源协议的保障，Linux 操作系统或许难以构筑起庞大的开源生态，为全球互联网基础设施奠定根基；无数基于开源框架搭建的软件项目，也可能因代码使用的不确定性而举步维艰。
然而，开源协议的家族庞大而多样，GPL、BSD、MIT、MPL、Apache 2.0、LGPL 等众多成员各有千秋。它们如同风格迥异的向导，为开发者在开源世界领航。有的强调代码自由的极致传承，要求衍生作品必须延续开源之光；有的则以宽松姿态，给予使用者充分的商业化自由，助力代码在商业浪潮中畅游。不同的协议背后，是开发者对于软件传播路径、项目发展目标、权益保护边界的深度思考。对于技术团队而言，选择一款契合项目的开源协议，无异于为软件铺就一条精准适配的发展轨道；而对于代码使用者，明晰协议内涵，则是在合法合规前提下，尽情挖掘开源宝藏的必备指南。
本篇文章宛如一座桥梁，一端连接开源协议的复杂知识体系，一端通向开发者群体的迫切需求。它将全面剖析这些主流开源协议的精髓，从定义溯源到特点提炼，从适用场景描绘到许可权限与限制条件的精细解读，层层递进。通过深入浅出的文字，让读者能够精准把握每个协议的独特个性。同时，精心打造的对比分析板块，将各协议的关键要素置于同一维度，直观呈现它们的异同，为读者在实际项目选型时提供清晰有力的决策依据。这既是对开源协议知识体系的系统梳理，也是助力开发者在开源征程中扬帆远航的实用指南，旨在推动开源精神在更广阔的天地里生根发芽、茁壮成长，持续绽放推动技术进步的耀眼光芒。

一、GPL（GNU General Public License）

定义

GPL 是由自由软件基金会（FSF）公布的自由软件许可证，旨在确保软件的自由使用和修改，同时保护原作者的知识产权。其核心思想是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。只要在一个软件中使用（“使用”指类库引用，修改后的代码或者衍生代码）GPL 协议的产品，则该软件产品必须也采用 GPL 协议，即必须也是开源和免费，这体现了其“传染性”。

特点

1. 传染性强：一旦使用了 GPL 许可的代码，整个软件都必须开源，具有很强的“传染性”。例如，如果一个项目调用了 GPL 许可的某个库，那么这个项目整体都要遵循 GPL 协议开源。
2. 保障软件自由：确保软件的完全开源和自由使用，防止闭源商业软件对代码的不当使用和修改，鼓励社区协作，保证了用户和开发者的自由。
3. 限制商业化：商业公司可能不愿意使用 GPL 协议的代码，因为它要求必须将修改版的源代码公开，这可能涉及到商业秘密的泄露。

使用场景

广泛应用于操作系统（如 Linux 内核）、工具（如 GCC 编译器）等，适用于希望确保衍生作品保持开源的项目，尤其是在社区驱动和需要长期保护自由软件的场景下。

适用范围

适用于几乎所有软件，特别是在开源社区中广泛使用，但商业软件或者对代码有保密要求的部门不太适合集成使用 GPL 协议的软件作为类库和二次开发的基础。

许可权限

1. 复制自由：允许把软件复制到任何人的电脑中，并且不限制复制的数量。
2. 传播自由：允许软件以各种形式进行传播，也允许在各种媒介上出售该软件，但必须提前让买家知道这个软件是可以免费获得的。
3. 修改自由：允许开发人员增加或删除软件的功能，但软件修改后必须依然基于 GPL 许可协议授权。

限制条件

1. 必须公开源码：所有基于 GPL 许可软件的衍生作品都必须公开源代码。
2. 禁止闭源商业使用：不允许将修改后和衍生的代码做为闭源的商业软件发布和销售。

相关图片

二、BSD（Berkeley Software Distribution）

定义

BSD 协议最初用于加州大学伯克利分校发布的各个 4.4BSD 版本，后来逐渐沿用下来，是一系列类似的许可证，如 BSD 2 - Clause License 和 BSD 3 - Clause License 等。它是一种较为宽松的开源协议，给予使用者很大自由。

特点

1. 宽松自由：基本上允许用户“为所欲为”，可以自由地使用、修改和重新发布遵循该许可的软件，并且可以将软件作为商业软件发布和销售。
2. 商业友好：对商业集成很友好，很多公司在选用开源产品的时候都首选 BSD 协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

使用场景

适合希望让代码尽可能多地传播并被广泛使用的项目，尤其是那些对商业使用没有太多顾虑的项目，如操作系统（FreeBSD、NetBSD、OpenBSD 等）和基础架构软件开发。

适用范围

适用于各种软件和文档。

许可权限

1. 使用、修改和分发自由：用户可以自由使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
2. 商业使用自由：允许将软件用于商业目的。

限制条件

1. 保留版权声明：如果再发布的软件中包含源代码，则源代码必须继续遵循 BSD 许可协议；如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的 BSD 协议。
2. 禁止商业推广限制：不允许用原始开源代码软件的名称、作者名字或机构名称进行市场推广（BSD 3 - Clause License 有此限制，BSD 2 - Clause License 无此限制）。

相关图片

三、MIT（Massachusetts Institute of Technology License）

定义

MIT 许可证是一种非常宽松的开源许可证，源自美国麻省理工学院，允许用户几乎完全自由地使用、复制、修改和分发软件。

特点

1. 极度宽松：是最宽松的开源协议之一，赋予使用者几乎无限的自由，包括使用、复制、修改、合并、发布、分发、再许可和销售软件的副本。
2. 简单易懂：协议条款简洁，只有少量的条款，易于理解，非法律专业人士也能轻松明白。

使用场景

适合任何类型的项目，尤其是那些希望代码能够被广泛使用，并且不希望对使用方式有过多限制的开发者和组织，如前端框架（React、Vue.js 等）、库和工具等项目。

适用范围

适用于几乎所有类型的开源和商业软件。

许可权限

1. 自由使用：可以在个人或商业项目中自由使用该软件。
2. 修改与分发：用户可以对软件进行修改并将其作为自己的产品分发。

限制条件

使用者必须保留原始的版权声明和许可协议文本。

相关图片

四、MPL（Mozilla Public License）

定义

MPL 是由 Mozilla 基金会发布的开源许可证，旨在平衡开源软件的自由与商业应用的需求，是一种中间型许可证。

特点

1. 灵活性高：允许修改、使用和分发软件，但修改代码的部分必须开源，比 GPL 更宽松，不要求整个程序都必须开源，尤其适合那些希望使用开源代码但又不希望全部开源的商业项目。
2. 专利保护：包含了对专利的保护条款，贡献者必须保证他们的代码在贡献时不会通过专利诉讼限制代码的自由使用。

使用场景

适合需要部分闭源、部分开源的混合开发项目，如 Mozilla Firefox、LibreOffice 等项目，也非常适合用作库或模块级的许可证。

适用范围

适用于各种软件和文档，特别是与 Mozilla 相关的项目。

许可权限

1. 使用和修改自由：允许免费重发布、免费修改软件。
2. 部分闭源许可：允许将 MPL 授权下的源代码与开发者个人文件进行混合闭源商用，但在 MPL 授权下的代码文件必须遵守 MPL 许可证，并且保持开源。

限制条件

1. 修改部分开源：对 MPL 覆盖的代码部分进行修改后，必须以 MPL 许可证的方式再许可出来，确保其他人可以在 MPL 的条款下共享源代码。
2. 专利相关限制：源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

相关图片

五、Apache 2.0

定义

Apache 2.0 许可证是由 Apache 软件基金会发布的开源协议，旨在鼓励开源软件的使用和贡献，是一种商业友好的开源协议。

特点

1. 商业友好：明确授予用户使用、复制和分发软件的权利，并且包含了专利授权条款，保护了贡献者的专利权，适合吸引大型企业和商业用户采用。
2. 灵活性高：不要求衍生作品必须开源，使用了 Apache 许可代码的项目，其衍生作品可以选择不同的许可证。

使用场景

适合需要明确专利保护的项目，以及希望吸引大型企业和商业用户采用的开源项目，如 Apache HTTP Server、Android、Kubernetes、Kafka 和 Hadoop 等项目。

适用范围

适用于几乎所有类型的软件，特别是与网络相关的项目。

许可权限

1. 使用、修改和分发自由：允许用户自由地使用、修改和分发代码，包括商业用途。
2. 专利使用许可：如果源代码中包含专利，许可证会授予用户使用这些专利的权利。

限制条件

1. 保留版权声明：需要保留版权声明、许可协议和免责声明。
2. 标注修改信息：任何重要的修改都需要进行标注。如果修改了代码，需要在被修改的文件中说明；在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。
3. Notice 文件要求：如果再发布的产品中包含一个 Notice 文件，则在 Notice 文件中需要带有 Apache Licence，可以在 Notice 中增加自己的许可，但不可以表现为对 Apache Licence 构成更改。

相关图片

六、LGPL（GNU Lesser General Public License）

定义

LGPL 是 GPL 的一个为主要为类库使用设计的开源协议，也被称为 GPL V2，是 GNU 通用公共许可证（GPL）的一个简化版本，旨在允许使用者在不强制开源的前提下，能够在闭源软件中使用开源代码。

特点

1. 商业软件兼容性好：允许商业软件通过类库引用（link）方式使用 LGPL 类库而不需要开源商业软件的代码，为商业软件提供了灵活性，促进了软件的自由发展和创新。
2. 部分传染性：如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。

使用场景

主要用于库和框架（如 Glibc, GTK widget toolkit），适合开发那些希望被广泛应用于各种项目中，包括商业和闭源项目的库类项目。

适用范围

适用于软件库等开源项目。

许可权限

1. 类库引用自由：商业软件可以通过类库引用方式使用 LGPL 类库而无需开源商业软件的代码。
2. 使用和修改自由：可以在遵循协议的前提下，自由使用、修改和分发代码。

限制条件

1. 修改代码开源：如果修改 LGPL 协议的代码或者其衍生代码，则所有修改的部分都必须采用 LGPL 协议开源。
2. 提供源码信息：当以可执行形式分发包含 LGPL 代码的软件时，必须以源代码形式提供 LGPL 代码部分，并且必须通知可执行形式的接收者如何通过合理的方式及时获得此类源代码格式的副本。

相关图片

各开源协议关键信息对比

各开源协议之间的联系与差异

联系

• 开源基础：这些协议都是开源协议，都允许用户在一定程度上自由使用、修改和分发软件，促进了开源软件的发展和共享。
• 版权保护：都要求保留原作者的版权声明，尊重原作者的知识产权。

差异

• 传染性：GPL 传染性强，使用其代码的软件必须整体开源；LGPL 有部分传染性，修改代码时相关部分需采用 LGPL 协议；而 BSD、MIT、MPL、Apache 2.0 没有这种严格的传染性。
• 商业使用限制：GPL 限制商业化，商业公司使用可能涉及商业秘密泄露；BSD、MIT、Apache 2.0 商业友好，对商业使用限制较少；MPL 允许部分闭源商用，但修改部分需开源。
• 开源要求：GPL 要求整个软件开源；MPL 只要求修改部分开源；Apache 2.0 不要求衍生作品必须开源。
• 专利保护：MPL 和 Apache 2.0 包含专利保护条款，保障了代码在专利方面的使用和贡献。