开源项目中的许可证有哪些种类？

wen 开源项目 2026-06-18 8

种类、选择与合规指南

📖 目录导读

开源许可证的核心作用
主流许可证分类体系
- 1 宽松型许可证
- 2 弱保护型许可证
- 3 强保护型许可证
12种常见许可证详细解读
许可证选择决策树
常见问答FAQ
合规使用与风险规避

开源许可证的核心作用

开源许可证（Open Source License）是开源项目的法律基石，它明确规定了用户在使用、修改、分发代码时的权利与义务，截至2024年底，通过开源促进会（OSI）认证的许可证已超过100种，但实际广泛应用的仅约20种，当前GitHub上超过80%的项目采用以下三大类许可：MIT、Apache 2.0和GPL系列。

开源项目中的许可证有哪些种类？

许可证的核心价值在于：

保护原作者的知识产权
明确衍生作品的发布要求
保障商业使用的合法性
维护社区共享精神

📌 注意：未声明许可证的项目默认受著作权法保护，他人无权使用。

主流许可证分类体系

根据对代码使用的限制程度,许可证通常分为三大类：

1 宽松型许可证（Permissive Licenses）

特点：允许他人任意使用、修改、商用，仅需保留版权声明。
代表：MIT、Apache 2.0、BSD系列、Unlicense
适用场景：企业希望代码被广泛采用，或作为底层依赖库。

2 弱保护型许可证（Weak Copyleft Licenses）

特点：修改后的衍生代码需要开源，但链接调用不受限制。
代表：LGPL系列、MPL 2.0、Eclipse Public License
适用场景：需要保护核心代码修改权，但仍允许商业闭源调用。

3 强保护型许可证（Strong Copyleft Licenses）

特点：任何使用了该代码的软件（包括静态链接的动态库）都必须开源。
代表：GPL系列、AGPL
适用场景：希望确保所有衍生作品保持开源，尤其是反对闭源商业化的项目。

12种常见许可证详细解读

1 MIT License

覆盖率：GitHub上约45%的项目采用
限制级别：最低
关键条款：

允许任意修改、发行、商用
必须保留原始版权和许可声明
不承担任何担保责任
典型项目：Node.js、React、jQuery

2 Apache License 2.0

特点：比MIT多出专利授权条款
核心规则：

自动授予专利许可（避免专利陷阱）
修改文件需注明变更
禁止使用贡献者姓名推广
典型项目：Android、Kubernetes、Spring

3 BSD 3-Clause License

与MIT高度相似,额外限制不得使用原作者名义推广，BSD 2-Clause则完全等同于MIT。
适用：大学和科研机构偏爱使用。

4 GPLv3（GNU General Public License）

最强copyleft：任何衍生作品必须完全开源
关键差异：

静态/动态链接均受限制
抗Tivoization条款（禁止硬件限制用户修改）
专利授权反馈条款
典型项目：Linux内核（v2）、Git、WordPress

5 AGPLv3（Affero GPL）

网络服务适用：通过互联网提供服务的软件也需开源
典型项目：MongoDB（旧版本）、Elasticsearch（旧版）

6 LGPLv3（Lesser GPL）

链接豁免：动态链接库可不影响闭源调用
典型项目：FFmpeg、Qt框架

7 MPL 2.0（Mozilla Public License）

文件级copyleft：修改过的文件必须开源，未修改文件可保持闭源
典型项目：Firefox、LibreOffice

8 Eclipse Public License 2.0

特点：与MPL类似，但新增专利条款
典型项目：Eclipse IDE、JUnit

9 Unlicense

公有领域声明：放弃所有版权，任何人可任意使用
风险：不同法域对公有领域认可程度不同，存在争议

10 ISC License

与MIT几乎一致，但文本更简洁
典型项目：OpenBSD部分工具

11 Creative Commons系列

CC0（公有领域）、CC BY 4.0（署名即用）
注意：CC协议不推荐用于代码，更适合文档和设计素材。

12 商业友好许可证

示例：BDS 2-Clause + Patent（如React之前用的附加专利条款），或采用Apache 2.0。

许可证选择决策树

选择流程图（文字版）

是否允许闭源商用？
   ├─ 是 → 宽松型
   │     └─ 需要专利保护？→ Apache 2.0 / 否 → MIT
   └─ 否 → copyleft型
         └─ 是否仅限制代码修改？→ MPL / 否 → GPL
2. 是否希望网络服务也强制开源？
   └─ 是 → AGPL / 否 → GPL

实用建议

项目类型	推荐许可证	原因
公司核心产品开源	MIT 或 Apache 2.0	避免吓退商业用户
教学和科研库	BSD 3-Clause	平衡自由与声誉保护
希望鼓励贡献的社区项目	GPLv3	强制回馈
SaaS创业公司	AGPL	防止竞争对手直接部署

⚠️ 警告：混合使用不同许可证可能导致冲突，例如GPL与Apache 2.0兼容，但MIT与GPL不兼容（GPL要求更严格）。

常见问答FAQ

Q1：未选择许可证的项目能使用吗？

Q2：能否将MIT项目代码用于闭源商业软件？

Q3：GPL项目能否用于商业软件？

A：可以销售，但必须同时提供完整源代码，并允许用户修改。

Q4：Apache 2.0和MIT哪个更适合商业？

A：Apache 2.0提供明确的专利授权，适合涉及专利技术的项目。

Q5：AGPL是否适用于移动应用？

A：如果应用通过网络调用AGPL服务端，则服务端代码需开源，客户端不受影响。

Q6：使用LGPL库需要开源整个应用吗？

A：仅当修改了库本身才需开源，动态链接调用不触发。

Q7：可以同时使用多个许可证吗？

A：可以，称为“双许可”，例如MySQL同时提供GPL和商业许可。

Q8：修改MIT代码需要通知原作者吗？

A：不需要，但需在修改文件中加上变更声明（不是强制要求，但建议）。

Q9：企业如何确保合规？

A：使用SPDX标识符（如SPDX-License-Identifier: MIT）或依赖SCA工具。

Q10：许可证版本更新如何影响项目？

A：建议使用“or later”声明（如GPLv2+），允许用户选择新版。

合规使用与风险规避

1 常见的合规陷阱

误用非代码许可证：CC协议用于代码可能导致版权漏洞
混合冲突许可证：如将MIT代码注入GPL项目
忽略专利条款：使用Apache 2.0但未处理专利回授
未正确署名：在二进制分发时遗漏版权声明

2 企业操作规范

建立许可证清单：使用FOSSA或WhiteSource扫描
明确依赖关系：区分编译时、运行时、链接依赖
审计衍生范围：特别是使用GPL/AGPL时的源码提供路径
制定内部政策：禁止使用AGPL除非获得组织批准

3 维权典型案例

Oracle vs. Google（Java API案）：非版权保护的可应用性（美国最高法）
Software Freedom Conservancy vs. Vizio：强制执行GPL合规
Monero矿工软件争议：未遵守开源许可导致的索赔

4 未来趋势观察

Server-Side Public License（SSPL）：MongoDB、Elastic等转向更强保护
Fair Source License：介于开源与商业之间的新尝试
自动合规工具：GitHub推出License API和Dependabot自动检查

选择许可证不是技术决策,而是法律、商业和社区价值观的综合权衡，在开源生态中，既没有完美的许可证，也没有万能的合规方案，建议中小项目优先选用MIT或Apache 2.0，大型社区项目根据治理模式选择GPL或MPL，而商业公司应建立定期审计机制。开源不是为了免费运行代码，而是为了构建可信用的数字基础设施，在提交代码或使用开源组件之前，花10分钟仔细阅读许可证全文，远比日后面临法律纠纷更有价值。

延伸阅读：

开源促进会（OSI）官方认证列表
tldrlegal.com（许可证简明摘要）
GitHub License API文档