开源协议完全指南

开源协议完全指南 · Open Source License Guide

开源协议完全指南

什么是开源协议、为什么需要它、常用协议详解与选型指南

目录

  1. 什么是开源协议
  2. 为什么需要开源协议
  3. 两大阵营：宽松与著佐权
  4. 常用开源协议详解
  5. 协议对比总表
  6. 如何选择开源协议
  7. 知名项目使用举例
  8. 常见问题

一、什么是开源协议

开源协议（Open Source License），又称开源许可证，是一种具有法律效力的授权声明。软件作者通过开源协议，明确授予他人使用、复制、修改和分发软件的许可，同时保留部分权利或附加特定条件。

没有开源协议的开源代码，在法律上默认适用著作权法（Copyright）——这意味着他人无权使用、修改或分发该代码，即使代码是公开可见的。因此，开源协议是开源项目合法运作的基石。

一句话总结：开源协议 = 作者允许他人使用代码的”使用说明书”，规定了”能做什么”和”必须做什么”。

二、为什么需要开源协议

保护作者与使用者双方——协议明确了版权归属，同时也为用户提供了法律保障，避免因使用开源代码而侵权。

明确使用边界——哪些场景允许商业使用？修改后的代码是否必须开源？这些关键问题都需要协议来界定。

促进社区协作——统一的开源协议降低了协作的法律门槛，让全球开发者可以在同一规则下共同贡献代码。

防止法律纠纷——清晰的许可条款减少了因代码使用引发的争议，开源社区得以健康发展。

三、两大阵营：宽松 vs 著佐权

开源协议根据其传染性（Copyleft）的强弱，大致可分为两类：

宽松 Permissive License

允许使用者自由使用、修改和再发布代码，甚至可以将修改后的代码以闭源、商业软件的形式发布，只需保留原始版权声明。

代表协议：MIT Apache 2.0 BSD

著佐权 Copyleft License

要求修改或衍生作品必须使用同一种协议进行发布，即修改后的代码也必须开源（”传染性”）。著佐权越强，限制越严格。

代表协议：GPL LGPL MPL

四、常用开源协议详解

宽松 MIT

MIT License

MIT 协议是最宽松、最简洁的开源协议之一，源自麻省理工学院（MIT）。使用者几乎可以”为所欲为”——任意使用、修改、复制、分发、商用，只需保留原始版权声明。
  • ✅ 允许商业使用
  • ✅ 允许闭源再发布
  • ✅ 允许修改和分发
  • ✗ 不提供专利授权（未提及专利问题）
  • ✅ 需保留原始版权声明
  • ✗ 无担保条款
典型项目：React、Vue.js、Node.js、jQuery、Bootstrap
宽松 Apache 2.0

Apache License 2.0

Apache 2.0 是宽松协议中最完善、最详细的版本，由 Apache 软件基金会制定。除了 MIT 的基本权利外，还特别加入了明确的专利授权条款，保护贡献者和使用者免受专利诉讼。企业级项目首选。
  • ✅ 允许商业使用
  • ✅ 允许闭源再发布
  • ✅ 允许修改和分发
  • ✅ 明确专利授权（贡献者授予使用者专利许可）
  • ✅ 需保留原始版权声明
  • ✅ 需注明修改内容（NOTICE 文件）
典型项目：Android、Kubernetes、Spring Framework、TensorFlow、Apache HTTP Server
宽松 BSD

BSD License

BSD 协议（Berkeley Software Distribution License）历史悠久，主要有两个版本：BSD 2-Clause（简化版）和 BSD 3-Clause（标准版）。3-Clause 比 MIT 多了一个”禁止背书条款”——不得使用原作者姓名进行推广。
  • ✅ 允许商业使用
  • ✅ 允许闭源再发布
  • ✅ 允许修改和分发
  • ✗ 不提供专利授权
  • ✅ 需保留原始版权声明
  • ✅（3-Clause）禁止用原作者名义推广
典型项目：Go（BSD 3-Clause）、Nginx（BSD 2-Clause）、Redis（BSD 3-Clause）、Swift（Apache 2.0 但早期使用 BSD）
强著佐权 GPL

GNU General Public License (GPL)

GPL 是最著名的著佐权协议，由自由软件基金会（FSF）发布。核心要求：如果发布（分发）了基于 GPL 代码的修改版或衍生作品，必须使用 GPL 协议开源。当前主流版本是 GPLv3。
  • ✅ 允许商业使用
  • ✗ 不允许闭源再发布（衍生作品必须开源）
  • ✅ 允许修改和分发
  • ✅ 提供专利授权
  • ✅ 需保留原始版权声明
  • ✅ 修改后的代码必须使用 GPL
典型项目：Linux Kernel（GPLv2）、Git（GPLv2）、WordPress（GPLv2）、GCC（GPLv3）
弱著佐权 LGPL

GNU Lesser General Public License (LGPL)

LGPL 是 GPL 的“弱化版”，主要针对软件库（Library）。如果修改了 LGPL 代码本身，则必须开源；但通过动态链接使用 LGPL 库的应用程序，可以保持闭源。这使得 LGPL 成为”库”的理想选择。
  • ✅ 允许商业使用
  • ✅ 动态链接可以闭源
  • ✅ 允许修改和分发
  • ✅ 修改库本身必须开源
  • ✅ 需保留原始版权声明
典型项目：FFmpeg、glibc、GTK、Qt（早期版本使用 LGPL）
弱著佐权 MPL 2.0

Mozilla Public License (MPL 2.0)

MPL 是 Mozilla 基金会制定的协议，采用文件级著佐权——修改了某个 MPL 文件，该文件必须开源；但可以将 MPL 代码与其他文件（专有代码）混合编译，其他文件不受影响。
  • ✅ 允许商业使用
  • ✅ 混合编译可闭源（其他文件不受影响）
  • ✅ 允许修改和分发
  • ✅ 修改过的 MPL 文件必须开源
  • ✅ 需保留原始版权声明
典型项目：Firefox（浏览器）、Thunderbird、LibreOffice
公共领域 Unlicense

Unlicense / Public Domain

Unlicense 和 CC0 将代码完全放弃版权，释放到公共领域。使用者可以不受任何限制地使用、修改和分发，甚至无需保留版权声明。这是最”自由”的选择。
  • ✅ 允许商业使用
  • ✅ 允许闭源再发布
  • ✅ 允许修改和分发
  • ✅ 无需保留版权声明
  • ✅ 不附带任何担保
典型项目：SQLite（公共领域）、许多小型工具库

五、协议对比总表

特性 MIT Apache 2.0 BSD 3-Clause GPLv3 LGPLv3 MPL 2.0 Unlicense
商业使用 ✓ ✓ ✓ ✓ ✓ ✓ ✓
闭源再发布 ✓ ✓ ✓ ✗ △ △ ✓
专利授权 ✗ ✓ ✗ ✓ ✓ ✓ ✗
保留版权声明 ✓ ✓ ✓ ✓ ✓ ✓ —
修改须开源 ✗ ✗ ✗ ✓ △ △ ✗
传染性范围 无 无 无 全项目 库本身 文件级 无
适用场景 个人/小型项目 企业/大型项目 学术/合规敏感 保护自由软件 开源库 混合项目 完全放弃版权
说明：△ 表示有条件允许。LGPL 动态链接可闭源但修改库本身须开源；MPL 修改文件须开源但混合编译可闭源。

六、如何选择开源协议

选择协议时，建议从以下几个问题出发：

是否希望
代码永远开源？ →
否 → 是 → GPL
选择 GPL 确保所有衍生作品保持开源
是否允许闭源
商业使用？ →
是 → 需要专利保护？ →
否 → 需要专利保护？ → GPL 等
是 → 需要专利 → Apache 2.0
是 → 不需要专利 → MIT / BSD
发布的是
代码库？ → 是 → 允许动态链接
闭源使用？ →
否 → — → 是 → LGPL / MPL
否 → — → 否 → GPL
快速决策建议：
• 想最大化被使用 → MIT（最宽松，门槛最低）
• 企业项目/需要专利保护 → Apache 2.0
• 希望代码永远自由 → GPLv3
• 发布开源库供他人使用 → LGPL / MPL 2.0
• 完全放弃版权 → Unlicense / CC0
• 不确定 → MIT 是安全默认选择

七、知名项目使用举例

MITReact
MITVue.js
MITNode.js
MITBootstrap
MITjQuery
MITNext.js
Apache 2.0Kubernetes
Apache 2.0TensorFlow
Apache 2.0Android
Apache 2.0Spring
BSD 3Go
BSD 2Nginx
BSD 3Redis
GPLv2Linux Kernel
GPLv2Git
GPLv2WordPress
LGPLFFmpeg
LGPLglibc
MPL 2.0Firefox
MPL 2.0LibreOffice
UnlicenseSQLite
Apache 2.0Swift

八、常见问题

Q：开源协议是法律文件吗？
是的。开源协议具有法律约束力，在司法实践中已被法院认可。违反开源协议可能构成版权侵权。
Q：GPL 的”传染性”到底有多远？
GPL 的传染性仅限于”发布”（Distribution）行为。如果仅仅内部使用 GPL 代码，无需开源；但如果将修改版对外分发，则必须使用 GPL 开源。GPLv3 还增加了对”反规避”和”Tivoization”的限制。
Q：可以在商业软件中使用 MIT/Apache 代码吗？
可以。MIT 和 Apache 2.0 都明确允许商业使用，包括将修改后的代码作为闭源商业软件发布，只需保留原始版权声明。
Q：可以同时使用多个开源协议吗？
可以。项目可以选择”多协议发布”（Dual License），让使用者根据自身需求选择最合适的协议。例如，MySQL 同时提供 GPL 和商业许可证。
Q：开源协议之间可以兼容吗？
不完全兼容。例如，GPL 代码不能与 MIT 代码混合后以 MIT 协议发布（GPL 会”覆盖”MIT）。将 MIT 代码整合到 GPL 项目中则可以。协议兼容性是一个复杂问题，需要具体分析。
Q：如何为自己的项目选择协议？
建议使用 choosealicense.com 工具，它通过问答引导帮助选择最合适的协议。不确定时，MIT 是最安全、最通用的默认选择。

Open Source License Guide What open source licenses are, why they matter, and how to choose the right one

Table of Contents

  1. What is an Open Source License
  2. Why Open Source Licenses Matter
  3. Two Categories: Permissive vs Copyleft
  4. Common Open Source Licenses
  5. Comparison Table
  6. How to Choose a License
  7. Real-World Examples
  8. FAQ

1. What is an Open Source License

An open source license is a legally binding statement by which a software author grants others the permission to use, copy, modify, and distribute the software, while retaining some rights or imposing specific conditions.

Without a license, publicly available source code is protected by copyright law by default — meaning no one has the right to use, modify, or distribute it, even if the code is publicly visible. Therefore, an open source license is the foundation of legal operation for any open source project.

In a nutshell: An open source license is a “user manual” from the author that tells others what they can and must do with the code.

2. Why Open Source Licenses Matter

Protects both authors and users — The license clarifies copyright ownership while providing legal protection for users, preventing infringement claims when using open source code.

Defines usage boundaries — Can the code be used commercially? Must modified code be open-sourced? These critical questions need a license to answer.

Enables community collaboration — A unified license lowers the legal barriers to collaboration, allowing developers worldwide to contribute under the same rules.

Prevents legal disputes — Clear licensing terms reduce disputes over code usage, helping the open source community thrive.

3. Two Categories: Permissive vs Copyleft

Open source licenses can be broadly divided into two categories based on their copyleft strength:

Permissive Permissive License

Users are free to use, modify, and redistribute the code, even in proprietary, closed-source commercial software, as long as the original copyright notice is retained.

Representative: MIT Apache 2.0 BSD

Copyleft Copyleft License

Requires that modified or derivative works be distributed under the same license — meaning modified code must also be open source (the “viral” effect). The stronger the copyleft, the stricter the requirements.

Representative: GPL LGPL MPL

4. Common Open Source Licenses

Permissive MIT

MIT License

The MIT License is the most permissive and simplest open source license, originating from the Massachusetts Institute of Technology. Users can do almost anything — use, modify, copy, distribute, and commercialize — as long as the original copyright notice is retained.
  • ✅ Commercial use allowed
  • ✅ Closed-source redistribution allowed
  • ✅ Modification & distribution allowed
  • ✗ No patent grant (patent issues not addressed)
  • ✅ Must retain copyright notice
  • ✗ No warranty clause
Notable projects: React, Vue.js, Node.js, jQuery, Bootstrap, Next.js
Permissive Apache 2.0

Apache License 2.0

Apache 2.0 is the most comprehensive permissive license, created by the Apache Software Foundation. Beyond MIT’s basic rights, it includes explicit patent grant provisions, protecting both contributors and users from patent litigation. The preferred choice for enterprise projects.
  • ✅ Commercial use allowed
  • ✅ Closed-source redistribution allowed
  • ✅ Modification & distribution allowed
  • ✅ Explicit patent grant
  • ✅ Must retain copyright notice
  • ✅ Must document changes (NOTICE file)
Notable projects: Android, Kubernetes, Spring Framework, TensorFlow, Apache HTTP Server, Swift
Permissive BSD

BSD License

The BSD License (Berkeley Software Distribution License) has two main versions: BSD 2-Clause (simplified) and BSD 3-Clause (standard). The 3-Clause adds a “no endorsement” clause — the author’s name cannot be used for promotion.
  • ✅ Commercial use allowed
  • ✅ Closed-source redistribution allowed
  • ✅ Modification & distribution allowed
  • ✗ No patent grant
  • ✅ Must retain copyright notice
  • ✅ (3-Clause) No endorsement clause
Notable projects: Go (BSD 3-Clause), Nginx (BSD 2-Clause), Redis (BSD 3-Clause)
Strong Copyleft GPL

GNU General Public License (GPL)

The GPL is the most famous copyleft license, published by the Free Software Foundation (FSF). Core requirement: if you distribute modified or derivative code based on GPL-licensed code, it must be open-sourced under GPL. The current major version is GPLv3.
  • ✅ Commercial use allowed
  • ✗ No closed-source redistribution (derivatives must be open)
  • ✅ Modification & distribution allowed
  • ✅ Patent grant included
  • ✅ Must retain copyright notice
  • ✅ Modified code must use GPL
Notable projects: Linux Kernel (GPLv2), Git (GPLv2), WordPress (GPLv2), GCC (GPLv3)
Weak Copyleft LGPL

GNU Lesser General Public License (LGPL)

LGPL is a “weakened” version of GPL, designed for software libraries. Modifications to the LGPL code itself must be open-sourced, but applications that use LGPL libraries via dynamic linking can remain closed-source. This makes LGPL ideal for libraries.
  • ✅ Commercial use allowed
  • ✅ Dynamic linking can be closed-source
  • ✅ Modification & distribution allowed
  • ✅ Modifications to the library itself must be open
  • ✅ Must retain copyright notice
Notable projects: FFmpeg, glibc, GTK, Qt (earlier versions under LGPL)
Weak Copyleft MPL 2.0

Mozilla Public License (MPL 2.0)

MPL is a license by the Mozilla Foundation with file-level copyleft — if a specific MPL file is modified, that file must be open-sourced, but it can be combined with proprietary files in the same project without affecting them.
  • ✅ Commercial use allowed
  • ✅ Combined compilation can be closed (other files unaffected)
  • ✅ Modification & distribution allowed
  • ✅ Modified MPL files must be open-sourced
  • ✅ Must retain copyright notice
Notable projects: Firefox, Thunderbird, LibreOffice
Public Domain Unlicense

Unlicense / Public Domain

Unlicense and CC0 dedicate code to the public domain, waiving all copyright. Users can use, modify, and distribute without any restrictions, even without retaining a copyright notice. This is the most “free” option available.
  • ✅ Commercial use allowed
  • ✅ Closed-source redistribution allowed
  • ✅ Modification & distribution allowed
  • ✅ No copyright notice required
  • ✅ No warranty of any kind
Notable projects: SQLite (public domain), many small utility libraries

5. License Comparison Table

Feature MIT Apache 2.0 BSD 3-Clause GPLv3 LGPLv3 MPL 2.0 Unlicense
Commercial use ✓ ✓ ✓ ✓ ✓ ✓ ✓
Closed-source distribution ✓ ✓ ✓ ✗ △ △ ✓
Patent grant ✗ ✓ ✗ ✓ ✓ ✓ ✗
Retain copyright notice ✓ ✓ ✓ ✓ ✓ ✓ —
Modifications must open ✗ ✗ ✗ ✓ △ △ ✗
Copyleft scope None None None Whole project Library itself File-level None
Best for Small / personal projects Enterprise / large projects Academic / compliance-sensitive Protecting free software Open source libraries Mixed projects Dedicating to public domain
Note: △ means conditionally allowed. LGPL allows closed-source dynamic linking but modifications to the library itself must be open. MPL requires modified files to be open but allows combined compilation to remain closed.

6. How to Choose a License

Keep code
open forever? →
No → Yes → GPL
Choose GPL to ensure all derivatives remain open source
Allow closed-source
commercial use? →
Yes → Need patent
protection? →
No → Need patent? → GPL etc.
Yes → Need patent → Apache 2.0
Yes → No patent → MIT / BSD
Releasing a
library? → Yes → Allow dynamic-link
closed use? →
No → — → Yes → LGPL / MPL
No → — → No → GPL
Quick Decision Guide:
• Maximize adoption → MIT (most permissive, lowest barrier)
• Enterprise / need patent protection → Apache 2.0
• Keep software forever free → GPLv3
• Release a library for others → LGPL / MPL 2.0
• Full public domain dedication → Unlicense / CC0
• Not sure → MIT is the safe default

7. Real-World Examples

MITReact
MITVue.js
MITNode.js
MITBootstrap
MITjQuery
MITNext.js
Apache 2.0Kubernetes
Apache 2.0TensorFlow
Apache 2.0Android
Apache 2.0Spring
BSD 3Go
BSD 2Nginx
BSD 3Redis
GPLv2Linux Kernel
GPLv2Git
GPLv2WordPress
LGPLFFmpeg
LGPLglibc
MPL 2.0Firefox
MPL 2.0LibreOffice
UnlicenseSQLite
Apache 2.0Swift

8. FAQ

Q: Are open source licenses legally binding?
Yes. Open source licenses are legally enforceable and have been recognized by courts in practice. Violating an open source license may constitute copyright infringement.
Q: How far does GPL’s “copyleft” reach?
GPL’s copyleft only applies to “distribution.” If GPL code is used internally only, no open-sourcing is required. However, if modified code is distributed externally, it must be open-sourced under GPL. GPLv3 also adds anti-circumvention and anti-Tivoization provisions.
Q: Can I use MIT/Apache code in commercial software?
Yes. Both MIT and Apache 2.0 explicitly allow commercial use, including redistributing modified code as closed-source commercial software, as long as the original copyright notice is retained.
Q: Can a project use multiple licenses?
Yes. This is called “dual licensing” — allowing users to choose the license that best fits their needs. For example, MySQL offers both GPL and commercial licenses.
Q: Are open source licenses compatible with each other?
Not fully. For example, GPL code cannot be mixed with MIT code and released under MIT (GPL “overrides” MIT). However, MIT code can be incorporated into a GPL project. License compatibility is a complex topic that requires case-by-case analysis.
Q: How do I choose a license for my project?
Use the choosealicense.com tool — it guides you through questions to find the best license. When in doubt, MIT is the safest and most common default choice.