软件开发的本质是协作，而开源许可证决定了这种协作的法律边界——选错许可证，轻则影响项目生态，重则引发法律风险。

一、引言：开源时代，每个开发者都面临的选择题

「这个项目用什么许可证好？」

这个问题，几乎每个开源维护者都遇到过。当你把自己写的代码发布到 GitHub 上，却在 LICENSE 文件里随手写了个 MIT——你可能没有意识到，这个选择可能影响成千上万人的使用方式，甚至决定你的项目能否真正「开源」下去。

开源许可证（Open Source License），就是一套法律契约，规定了其他人可以对你的代码做什么、不能做什么。听起来简单，但现实远比想象复杂：

你是否遇到过这样的困惑？写了一个工具库，想让更多人用，但不知道该允许商业公司闭源使用，还是要求他们必须开源？用了一个 GPL 的库，想集成到自己的产品里，却发现整个产品都被「传染」必须开源？选了一个许可证，后来才发现它跟另一个专利许可冲突，导致用户收到律师函？

本文系统梳理当前最主流的六种开源许可证——MIT、BSD、Apache、LGPL、MPL、GPL——从法律条款、技术限制、商业适用场景三个维度，一次性讲清楚。

二、许可证的两大门派：Permissive 与 Copyleft

在具体聊每个许可证之前，首先要理解开源世界的两种基本哲学。

宽松型许可证（Permissive License），核心理念是「最大化自由使用」。只要你保留原作者版权声明，你可以任意使用、修改、闭源分发，几乎没有任何限制。这类许可证的代表是 MIT、BSD 和 Apache。

著佐权许可证（Copyleft License），核心理念是「开源精神必须传承」。如果你基于这类代码进行了修改或衍生，你必须以相同的许可证开源——换句话说，开源代码的「病毒」会传染给你，你必须把这份「病毒」继续传下去。GPL 就是最典型的代表。

▲ 图1：开源许可证分类体系

两者最大的差别在于：当你的代码被修改并再次发布时，Permissive 不要求你公开源代码（可以闭源），而 Copyleft 要求你必须开源。

理解了这个本质区别，我们就有了选型的基本框架。接下来，我们逐一拆解六种最常见的许可证。

三、主流许可证详解：从MIT到GPL

3.1 MIT许可证：最简洁、最宽松的「入门款」

MIT 许可证源自麻省理工学院，是目前世界上使用最广泛的开源许可证之一。JQuery、Ruby on Rails、Pelican 静态博客引擎都采用了 MIT。

核心条款只有两条：

一，你可以在任何目的下使用、复制、修改、合并、分发、再授权、销售这个软件的副本；二，你必须在你的软件副本中保留原作者的版权声明和许可证声明。

优势：

• 极简清晰，全文通常只有几段话，法律团队容易审核
• 对商业使用几乎没有任何限制，企业最爱
• 不要求衍生软件开源，可以闭源

劣势：

• 没有任何专利授权条款，如果原作者持有软件相关专利，用户可能面临专利诉讼风险
• 名称不能用于背书（不能声称「采用MIT许可的XXX推荐」）

典型场景： 个人开发者开源的工具库、快速原型、API-SaaS 的后端引擎。中小型商业项目闭源使用也完全合规，是绝大多数项目的「安全起步」选择。

3.2 BSD许可证：MIT的「加强版」

BSD（Berkeley Software Distribution）许可证同样源自大学（加州大学伯克利分校），与 MIT 非常相似，核心条款几乎相同，最大的区别在于禁止使用原作者名称进行营销推广。

BSD 存在多个变体，最常用的是「双条款 BSD」（2-Clause BSD）和「三条款 BSD」（3-Clause BSD）。三条款版本额外增加了一条：禁止使用BSD代码的贡献者姓名用于衍生产品的推广。这条约束比 MIT 更严格，能有效防止企业拿学术机构名称「背书」自己的商业产品。

优势：

• 与 MIT 一样宽松简洁
• 额外约束了名称滥用问题，更适合学术机构

劣势：

• 同样没有专利授权保护
• 对闭源商业使用完全开放，可能被不喜欢的人用于恶意目的

典型场景： 学术机构发布的项目、操作系统内核（FreeBSD、NetBSD）、网络协议栈。

3.3 Apache 2.0许可证：商业友好型的「全能选手」

Apache 许可证由 Apache 软件基金会（ASF）发布，是目前企业采用率最高的开源许可证之一。Apache HTTP Server、Hadoop、Kafka、Spring Framework 等顶级项目都采用了 Apache 2.0。

与 MIT/BSD 相比，Apache 多了两个重要机制：

专利授权条款： 明确授予用户使用与本软件相关的专利权利，且贡献者同时授权了自身的专利。这意味着如果你的代码贡献者手里握有相关专利，他自动授予了你使用权限，减少了后续专利纠纷。

衍生作品须明确声明： 在每个修改过的文件中，必须记录你做了哪些修改（虽然不需要逐行注释，但必须在文件头部注明「Modifications:」）。

优势：

• 完整的专利保护，对商业公司最有吸引力
• 允许闭源，商业集成友好
• 已有专利授权，避免「贡献代码后被诉专利侵权」的尴尬

劣势：

• 条款比 MIT/BSD 稍复杂，部分小型项目觉得「太重了」
• 要求保留所有 LICENSE 和 NOTICE 文件

典型场景： 企业主导的大型开源项目、微服务基础设施、中间件框架。商业公司首选。

3.4 LGPL许可证：类库专用的「弱传染」方案

LGPL（Lesser General Public License，字面意思是「较宽松通用公共许可证」）是 GPL 的「削弱版」，由自由软件基金会（FSF）发布。

LGPL 的设计初衷是：让程序可以链接到 LGPL 类库，而不需要整个程序都变成开源代码。 只有当你修改了 LGPL 类库本身时，才需要以 LGPL 开源；如果你只是使用这个类库（通过动态链接），你的商业程序无需开源。

举一个典型场景：你的商业闭源软件用到了 OpenSSL（采用 BSD-like + SSLeay 条款，但很多类库用 LGPL），你动态链接了 LGPL 动态库，理论上你的主程序代码不需要开源——只需要遵守 LGPL 的要求（提供类库源代码、允许用户获取修改版本）。

优势：

• 允许商业程序闭源使用类库，是 LGPL 最大的价值
• 保持了 Copyleft 精神——类库本身必须保持开源

劣势：

• 动态链接 vs 静态链接的边界有时模糊，法律上有争议空间
• 条款理解成本高，滥用有法律风险

典型场景： 编程语言标准库、通用工具类库（GLib、Iconv）、数据库客户端 SDK（MySQL Connector）。如果你是一个类库作者，希望代码被广泛使用但又要求类库本身保持开源，LGPL 是标准选择。

3.5 MPL 2.0：文件级别的精细化著佐权

MPL（Mozilla Public License）2.0 是本文中最「年轻」的主流许可证，由 Mozilla 基金会发布。Firefox 浏览器和 Thunderbird 邮件客户端就采用了 MPL。

MPL 最大的创新在于它的精细化 Copyleft：只有在你修改了 MPL 许可证覆盖的文件本身时，才需要以 MPL 开源。如果你只是在项目中使用了 MPL 组件，而没有修改这些文件，你的其他代码不受任何传染性约束。

这意味着：你的商业程序可以引用 MPL 许可的组件，只要你不修改那些组件的源代码，你的业务逻辑代码可以保持完全闭源——这一点比 LGPL 更加商业友好。

优势：

• 文件级别的著佐权，传染范围最小化
• 自带专利授权条款
• 允许在 MPL 代码与其他许可证代码之间「选择」，灵活性高

劣势：

• 条款理解复杂，需要仔细阅读才能正确合规
• 使用不如 MIT/GPL 广泛，部分公司法律团队不熟悉

典型场景： 需要商业集成的复杂产品、混合开源的商业软件套件。如果你既想使用开源组件，又不想让自己的核心代码被开源传染，MPL 是 LGPL 之外的有力候选。

3.6 GPL许可证：最强的开源「传染」协议

GPL（General Public License）由理查德·斯托曼（Richard Stallman）起草，是 Copyleft 运动的奠基之作。Linux 内核、Git、MySQL（早期）、WordPress 都采用 GPL。

GPL 有两个关键版本：GPL v2（目前仍被 Linux 使用）和 GPL v3（增加了专利保护和反唐尼条款）。我们通常说的 GPL 默认指 GPL v3。

GPL 的核心原则是：「你来我往」的公平契约。 你获得了使用GPL代码的权利，但作为交换，你基于它创作的衍生作品也必须开源，并且必须以 GPL 为许可证。哪怕你只是写了一层薄薄的包装代码，也会被 GPL「传染」，整个程序必须开源。

优势：

• 最彻底地保护开源精神，防止代码被闭源产品「收割」
• 要求衍生作品必须回馈社区，推动整个开源生态健康发展

劣势：

• 强传染性让商业公司望而却步——使用GPL代码意味着自己的产品也必须开源
• GPL v3 增加了专利条款，与部分旧项目不兼容

典型场景： 操作系统内核（Linux）、编译器（GCC）、完整应用软件（WordPress）、开源数据库（PostgreSQL）。当你希望自己的作品永远保持开源、不被商业闭源化时，GPL 是最强法律武器。

四、一图看懂宽松度对比

▲ 图2：主流开源许可证宽松度对比

关于宽松度排序，业界有一个相对共识（从宽松到严格）：

MIT ≈ BSD > Apache > LGPL > MPL > GPL

其中，MIT 和 BSD 是最宽松的「入门级」，GPL 是最严格的「守护级」。

这里要特别说明一点：宽松不等于好，严格不等于差。 选什么许可证，取决于你希望达成什么目标——是想让代码被尽可能多的人使用（选MIT/BSD），还是希望确保开源精神传承下去（选GPL），抑或是在商业友好和开源保护之间找到平衡（选Apache/LGPL/MPL）。

五、实战选型指南：不同场景怎么选？

场景一：个人开发者开源一个小工具库

推荐：MIT

理由：门槛最低，用户最多，商业集成零障碍。如果你的目标是让更多人用上你的工具，就不要用 GPL 给他们添堵。

场景二：企业主导的大型基础设施项目

推荐：Apache 2.0

理由：自带专利保护，条款清晰，企业法律团队容易接受。同时允许商业闭源使用，最大化吸引企业用户和贡献者。

场景三：编程语言类库 / SDK

推荐：LGPL 或 MPL

理由：类库被广泛引用是好事，但你也不想自己的代码被直接 fork 走改个名就闭源了。LGPL 允许商业程序链接类库而不要求整个程序开源；MPL 更进一步，只在修改了库文件本身时才触发开源要求。

场景四：完整应用程序 / CMS / 操作系统

推荐：GPL

理由：应用程序不同于类库，使用 GPL 可以确保你的作品永远不会被其他公司直接闭源化——任何基于你作品的衍生也必须开源，形成健康的开源生态循环。

场景五：混合多种许可证的项目

推荐：仔细检查许可证兼容性

这是最容易踩坑的地方。GPL v3 与 GPL v2 不兼容（是的，同一个协议的不同版本互相不兼容！）。LGPL 可以与 GPL 共存（因为 LGPL 就是专门为这种场景设计的）。MPL 的文件级别机制让它可以和几乎任何许可证混合使用。

如果你在使用多个开源库，一定要检查各许可证之间的兼容性，避免让你的用户陷入「我到底该怎么合规」的困境。

六、常见误区：开源许可证的几个坑

误区一：「我把代码公开就是开源了」

代码公开 ≠ 开源。没有明确许可证的代码，在大多数国家/地区默认是「保留所有权利」的状态——别人反而不能随意使用，否则面临侵权风险。开源第一步，必须选许可证。

误区二：「我用GPL代码，整个产品就必须开源」

这句话只说对了一半。GPL 的传染发生在分发（distribution）环节。如果你不分发软件（比如只在公司内部使用），GPL 不强制你开源。真正触发 GPL 传染的是：向外部用户提供编译好的可执行程序或源代码。

误区三：「所有许可证都允许免费商用」

大多数开源许可证确实允许商业使用，但「允许商用」不等于「免除所有责任」。部分许可证（如原始 BSD）没有专利授权条款，如果你的产品涉及专利敏感领域，商业使用可能面临专利风险。

误区四：「我把许可证从MIT改成GPL，我的项目历史就自动变成GPL了」

许可证变更需要所有版权持有者同意。如果你是唯一作者，更改许可证相对简单；但如果项目有大量贡献者，每个人都拥有自己贡献部分的版权——你不能单方面把别人的代码从MIT改成GPL，必须逐一获得同意。

七、给开源新手的行动建议

第一步，选定许可证。 如果你不知道该选什么，MIT 是最安全、最通用的起步选择。如果你在企业环境，Apache 2.0 通常是最容易被法务接受的选择。

第二步，在项目根目录创建 LICENSE 文件。 GitHub 创建新仓库时会提示你选择许可证，一键生成。选完后，确保每年维护更新版权年份（如有要求）。

第三步，在每个源文件头部添加许可证头部注释。 格式通常为：

// Copyright (c) 2025 Your Name
// SPDX-License-Identifier: MIT

SPDX-License-Identifier 是行业标准标识符，能让工具自动识别文件所属许可证，减少法律审查成本。

第四步，了解你依赖的其他开源组件的许可证。 使用 npm ls、pip list、cargo tree 等工具审计依赖链，确保整体许可证组合符合你的预期。

八、相关资源

• 开源倡议组织（OSI）许可证列表：https://opensource.org/licenses
• SPDX 许可证标识符官方列表：https://spdx.org/licenses
• GitHub 官方许可证选择指南：https://docs.github.com/en/repositories/managing-our-repository-settings-and-features/customizing-your-repository/about-licenses
• Choosealicense.com（GitHub 出品的许可证选择助手）：https://choosealicense.com

---