开源协议选型指南：详解GPL、MIT、Apache等六大许可证，规避商业风险

May 31, 2026

开源并不意味着完全免费！在日常开发中，我们常常会借助开源软件和源码来提升效率。然而，为了规避潜在的商业风险，我们必须深入了解第三方软件的使用条款，包括其协议类型、版本以及已知的CVE安全漏洞等信息。本文将从开源软件再发布时的权限角度出发，系统梳理各类常见开源许可证的异同，帮助您快速建立起清晰的认知。

绝大多数开发者都乐于将自己的作品公开分享，让更多人查阅和使用。这不仅能够提升个人在业界的影响力，也能为需要的人提供帮助，践行开源精神。然而，一旦将代码公开，任何人都可以任意查看和获取，后续的使用行为便完全脱离了作者的控制。

许可证（License）就是软件的权利说明书，其中详细规定了使用者获得代码后所拥有的权限，明确界定了可以对他人作品进行的操作以及被禁止的行为。

从性质上，软件协议可分为商业协议与开源协议两大类别。

商业协议：也称为法律声明或许可协议，通常由软件作者或专业律师精心撰写。由于涉及到未来可能发生的侵权诉讼等法律问题，这类条款的措辞极为严谨考究，因此读起来往往晦涩难懂。
开源协议：需要明确的是，开源既不代表免费，也不代表毫无约束。虽然相较于商业协议，开源协议的条款更加简明扼要，但对不少初次接触者而言，理解起来仍像在翻阅“天书”。

主流开源协议概览

目前业界最主流的六种开源许可证分别是 GPL、BSD、MIT、Mozilla（MPL）、Apache 和 LGPL。乌克兰程序员 Paul Bagwell 绘制了一张清晰的选择分析图，帮助开发者快速理清它们之间的核心差异。以下是阮一峰翻译的中文版：

一、Apache 许可证：永久、无国界的权利授予

Apache 许可证（Apache License）是由 Apache 软件基金会发布的一款自由软件许可证，最初专为 Apache HTTP 服务器项目撰写。该许可证要求被授权者保留版权和免责声明，但它本身并非反版权的许可证。

目前最新的版本是 2004 年 1 月推出的“2.0 版”。Apache 许可证在 Apache 社区内外均得到了广泛应用：Apache 基金会旗下的所有项目均采用此许可证，此外，许多非 Apache 项目也选择了它。据统计，截至 2008 年 4 月，SourceForge 上已有超过 3000 个项目使用 Apache 许可证。

Apache 2.0 版为用户赋予了非常广泛的权利，这些权利不仅适用于著作版权，还覆盖了专利权。由于许多许可证仅能约束版权，而对专利权无能为力，这一灵活性为拥有专利的开发者提供了重要的选择依据。

Apache 许可证赋予的主要权利包括：

权利永久有效：一旦获得授权，这些权利便永久存在，不会失效。
无地域限制：在一个国家获得的授权，效力等同于在所有国家获得授权。例如，即使授权最初在印度签发，你在美国同样可以使用该程序。
无需付费：在使用前无需支付任何费用，使用过程中也无需支付任何形式的报酬。
非排他性：使用该许可证下的软件，并不妨碍你使用其他软件。
权利不可撤销：权利一经授予便不能剥夺。也就是说，你无需担心在自己基于该授权软件开发出优秀的衍生产品后，突然被禁止继续使用原程序。（协议中存在一个例外条款：如果你对许可协议下的产品提起专利权侵权诉讼，你的授权将自动终止。但这仅涉及专利作品，只要你不发起相关诉讼，就永远无需担心。）
再分发时的署名要求：对于再分发的作品，Apache 协议特别要求必须给予原始程序的作者和许可证的维护者适当的署名与致谢。

二、MIT 许可证：最简短、最宽松的协议

MIT 协议可以说是最流行、最短小精悍的开源许可证之一。其条款极其宽松，与其他协议相比自由度最高，被广泛认为是对使用者限制最少的协议。

基本上，只要认可该协议，任何人都可以对 MIT 协议下的软件做任何事情。协议中最重要的声明（即不提供担保的声明）位于结尾段落：

特此授权，任何人可免费获取本软件及相关文档的副本，并无限制地使用本软件，包括无限制的权利去使用、复制、修改、合并、发布、附加从属协议，以及/或销售软件副本。为了保证软件提供者能够授予这些权利，必须遵守以下条件：

这实际上意味着：

你可以自由使用、复制、修改该软件。没有人能阻止你在任何项目中使用它，你可以无限次复制、以任意形式传播，或按你的意愿进行修改。
你可以免费分发，也可以用于商业销售。分发行为没有任何限制。
唯一的约束就是必须接受协议条款。

三、BSD 许可证：自由与署名的平衡

BSD 协议拥有多个变种，但它们共同代表了一种宽松的自由软件许可模式。与 GPL 之类的协议相比，BSD 对软件再传播的限制要少得多。

在这些版本中，有两个尤为重要：新 BSD 协议（修订版 BSD）和简化 BSD 协议（FreeBSD 协议）。这两种版本均是与 GPL 兼容的自由软件许可，并且都被开源促进会（Open Source Initiative）认可为正式的开源软件协议。

BSD 开源协议赋予使用者极大的自由。基本上使用者可以“为所欲为”，自由地使用、修改源代码，甚至将修改后的代码作为开源或专有软件重新发布。

但“为所欲为”的前提是，当你再发布采用 BSD 许可的代码，或基于 BSD 代码进行二次开发自己的产品时，需要满足以下条件：

如果再发布的产品中包含源代码，则源代码中必须保留原有的 BSD 协议声明。
如果再发布的仅为二进制类库或软件，则必须在类库/软件的文档和版权声明中包含原有的 BSD 协议声明。
不得使用开源代码的作者/机构名称以及原产品的名称进行市场推广。
BSD 协议鼓励代码共享，但需要尊重代码作者的著作权。由于允许使用者修改和重新发布代码，也允许使用 BSD 代码或在 BSD 代码基础上开发商业软件并进行销售，BSD 协议对商业集成十分友好。因此，众多公司在选择开源产品时都倾向于 BSD 协议，因为可以完全掌控这些第三方代码，在必要时进行修改或二次开发。

四、GPL 许可证：开源的“传染性”

我们熟知的 Linux 内核便是采用 GPL 协议发布。GPL 与 BSD、Apache 等鼓励代码重用的许可理念截然不同。GPL 的出发点在于：代码本身的开源/免费使用，以及引用、修改和衍生代码的开源/免费使用，但它不允许将修改后的代码或衍生代码作为闭源商业软件发布和销售。

这也就解释了为何我们能免费使用各种 Linux 发行版，包括商业公司发布的 Linux，以及由个人、组织和商业软件公司在 Linux 上开发的琳琅满目的免费软件。

GPL 协议的核心内容在于其“传染性”：只要你的软件中使用了（这里的“使用”包括类库引用、修改过的代码或衍生代码）任何采用 GPL 协议的产品，那么你的整个软件产品也必须采用 GPL 协议，即必须开源且免费。如果只是将 GPL 协议的产品作为一个独立的作品直接使用，则没有任何问题，并且还能享受免费的便利。

由于 GPL 严格要求使用了 GPL 类库的软件产品也必须采用 GPL 协议，因此对于那些有代码保密需求的商业软件或部门而言，将 GPL 协议的代码集成或作为类库及二次开发的基础并不合适。

其他细节，例如再发布时需要随附 GPL 协议文本等，则与 BSD、Apache 等协议类似。

五、LGPL 许可证：专为类库设计的宽松版 GPL

LGPL 是衍生自 GPL、主要为类库使用场景设计的一个开源协议。与 GPL 要求任何使用、修改或衍生于 GPL 类库的软件都必须采用 GPL 协议不同，LGPL 允许商业软件通过类库引用（link）的方式使用 LGPL 类库，而不需要开源商业软件自身的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用，并自由发布和销售。

但是，如果直接修改了 LGPL 协议的代码，或者基于它进行衍生开发，那么所有修改过的代码、涉及修改部分的额外代码，以及衍生的代码，都必须继续采用 LGPL 协议。因此，LGPL 协议的开源代码非常适合作为第三方类库被商业软件引用，但不太适合希望以其为基础，通过修改和衍生方式进行二次开发的商业软件采用。

无论是 GPL 还是 LGPL，它们都致力于保障原作者的知识产权，防止有人利用开源代码进行简单复制，开发出类似的产品。

六、MPL 许可证：Mozilla 的平衡之道

MPL 是 The Mozilla Public License 的缩写，由 Netscape 旗下的 Mozilla 小组于 1998 年初为其开源软件项目设计。MPL 许可证问世的最重要原因，在于 Netscape 公司认为 GPL 许可证没有很好地平衡开发者对源代码的需求以及他们利用源代码所获取的利益。

与著名的 GPL 和 BSD 许可证相比，MPL 在许多权利与义务的约定上与它们大致相同（因为它们都符合 OSIA 认定的开源软件许可标准），但 MPL 存在以下几个显著的不同之处：

MPL 要求对以 MPL 许可证发布的源代码所做的修改，也必须以 MPL 许可证的方式再次许可，以保证其他人能在 MPL 的条款下共享源代码。然而，MPL 中对“发布”的定义是“以源代码方式发布的文件”，这意味着企业可以在自己已有的源代码库上加一个接口，只需将接口程序的源代码以 MPL 许可对外公开，而源代码库中的其他源代码则不必强制以 MPL 许可对外公开。这一点，为借鉴他人源代码用于自身商业软件开发的行为留出了一道豁口。
MPL 许可证第三条第 7 款允许被许可人将以 MPL 许可证获得的源代码与自己的其他类型代码混合，从而得到自己的软件程序。
在对待软件专利的态度上，MPL 不像 GPL 那样明确反对软件专利，但它明确规定源代码的提供者不得提供已受专利保护的源代码（除非提供者本人是专利权人，并书面承诺向公众免费许可这些源代码），也不能在将这些源代码以开源许可证形式许可出去后，再去申请与这些源代码相关的专利。

在对“源代码”的定义上，MPL 同样有独特之处：

在 MPL 1.1 版本中，源代码被定义为：“对作品进行修改时最优先选取的形式，它包括所有模块的全部源程序，相关的接口定义，以及控制可执行作品安装和编译的‘原本’（Script），或者与初始源代码没有显著差异的、由源代码贡献者从公共领域获得的程序代码。”
MPL 许可证第 3 条有一款专门规定：所有的再发布者都必须准备一个专门的文件，用于描述对源代码程序进行修改的时间以及修改的方式。

协议对比与总结：GPL、LGPL 与 BSD 的法律差异

简单来说，GPL 是一个典型的开放源代码协议。当软件的原始开发者采用 GPL 并公开源程序后，任何后续基于该源程序进行开发的软件作者，也都必须依据 GPL 协议公开自己编写的源程序。GPL 的关键在于强制开放源程序，但并未禁止软件作者向用户收费。

尽管如此，许多大公司对 GPL 协议依然是又爱又恨。爱的是该协议下的软件历经无数程序员千锤百炼的修改，已经非常成熟和完善；恨的是，他们不得不公开自己后续开发的源程序，导致竞争对手同样可以根据这些修改后的源程序，开发出竞争性产品。

正因大公司在商业层面对 GPL 存在顾虑，另外两种协议被更频繁地采用。第一种是 LGPL（有时也被宽泛地称为 GPL V2），可以理解为更加宽松的 GPL 协议。它与 GPL 的关键区别在于：如果用户仅仅是对 LGPL 软件的程序库进行调用，而不是将其源代码包含进自己的产品中，那么其自身的源程序无需开源。调用与包含的区别，可以类比为在网页上引用他人的内容：如果把他人网页的全部或部分内容复制到自己网页上，就属于包含；如果只是贴一个他人网页的网址链接而不直接引用内容，就类似于调用。借助这个协议，很多大公司就能将自己大量后续开发的核心源代码隐藏起来，不予公开。

第二种就是 BSD 协议（MIT 协议也与此类似）。BSD 鼓励软件作者公开自己后续开发的源代码，但并不强制。在 BSD 协议下开发的软件，原始的源程序是开放出来的，但使用者进行修改后，可以自行选择是发布源程序，还是只发布编译后的二进制程序（目标程序）。当然，使用者有义务将软件发布时，一并附上自己原来使用的源程序以及 BSD 协议文本。由于这种灵活性，BSD 深受大公司的欢迎。