我为什么更喜欢 BSD 风格的许可证
最近在整理自己的代码仓库，重新研究了一遍开源许可证。刚好 又想水一篇文章 （不是），谈一下，我为什么更喜欢 BSD 风格的许可证，以及为什么觉得 GPL 是一种“邪恶”。当然我这里没有说 GPL 就是坏蛋，只是在这种条件下比较显得“邪恶”。
平时接触的项目里，MIT、BSD、Apache、GPL 这些名字经常出现。以前觉得许可证无非就是在仓库根目录放一个 LICENSE 文件，后来发现，真正涉及代码复用、修改、合并和重新分发时，里面的区别还挺多。
比如，一个 MIT 项目能不能修改后改成 BSD-3-Clause？BSD-3 能不能改成 MIT？Apache-2.0 为什么和 GPL-2.0-only 不兼容，却可以和 GPL-3.0 兼容？MPL 为什么说是文件级 Copyleft？
这些问题放在一起看，才比较容易理解许可证设计背后的思路。
先说我的立场：我更喜欢 BSD 风格的许可证。在我看来，BSD 才是我真正认同的开源方式。
这里说的「真正」，是我自己的价值判断，不是在否认其他许可证符合 Open Source Definition。MIT、Apache、GPL 等都可以是开源许可证，只是我对开源应该给予使用者多少自由，有自己的理解。
我认同 OpenBSD 项目的理念：代码应该尽可能让任何人都能自由使用、修改和重新分发，不应该因为使用了一段开源代码，就必须接受一整套额外的下游授权义务。
Free Software 和 Open Source 是一回事吗？
先说两个经常一起出现的组织：FSF 和 OSI。
FSF，全称 Free Software Foundation，即自由软件基金会，由 Richard Stallman 于 1985
年创立。它和 GNU Project 有密切关系，也是 GNU GPL 等许可证背后的重要推动力量。OSI，全称 Open Source Initiative，成立于 1998 年，主要负责维护 Open Source
Definition，并通过审查程序认可符合定义的开源许可证。
两者的理念有交集，但关注重点不完全一样。
FSF 使用的是 Free Software，也就是自由软件。
这里的 Free 主要指自由，而不是免费。
FSF 强调用户应当拥有运行、研究、修改和重新分发软件的自由，通常概括为四项基本自由。
OSI 使用 Open Source，即开放源代码。
它通过 Open Source Definition 定义什么样的许可证可以被认可为开源许可证，重点包括自由再分发、允许修改、不得歧视个人或团体、不得限制其他软件等要求。
所以，Free Software 和 Open Source 并不是「免费软件」和「公开源码软件」这么简单的区别。
两套定义都认可用户使用、修改和分发软件的权利，只是背后的理念和强调重点有所不同。
这里也需要区分 FSF 和 GNU Project。GNU 是一个操作系统及相关软件项目，FSF 是推动自由软件理念的基金会。GNU 项目大量使用 GPL，但不能把所有 GNU 软件都简单理解为只有 GPL 一种许可证。
我个人并不认同 FSF 对 Copyleft 的价值判断。GPL 希望通过许可证要求，让衍生作品继续保持相同的自由软件属性。这种设计有它自己的逻辑，但我不认为为了保护这种自由，就应该限制下游开发者选择其他许可证的权利。
我更看重代码能否被尽可能广泛地复用。有人拿我的代码去做商业产品、闭源产品，甚至开发出一个完全不同的项目，只要遵守原始许可证的基本要求，我都可以接受。
为什么我更认同 OpenBSD 的许可证理念？
这也是我比较喜欢 OpenBSD 的一个原因。
OpenBSD 的官方 Project Goals 明确写到，项目希望整合来自任何来源、许可证条件可接受的代码，并且偏好 ISC 或 Berkeley 风格许可证。它希望代码可以被任何人用于任何目的，也不接受将 GPL 作为新代码加入项目的授权方式。
OpenBSD 的 Copyright Policy 进一步解释了这种选择：
- 允许任何人自由使用、复制、修改和分发。
- 不对私人用途或商业用途施加额外限制。
- 保留必要的版权声明和免责声明。
- 尽可能避免复杂、额外的授权义务。
- 不因为使用代码而要求下游必须采用特定许可证。
我认同这种思路。
举个实际例子：我写了一个网络库，采用 BSD-2-Clause 发布。某家公司看中了其中的实现，把它放进自己的商业产品里，修改了一部分代码，最后没有公开自己的修改。
从 BSD 的角度看，这完全可以接受。只要它遵守许可证要求，就可以这样做。
我不认为这家公司一定要把修改后的代码交还给我。开源代码被使用、被修改、被整合到更多产品里，本身就是一种价值。
当然，这也意味着我不能要求所有使用者都必须公开自己的修改。选择 BSD，就应该接受它带来的结果。
OpenBSD 的许可证政策甚至比一般意义上的宽松许可证偏好更严格。它认为 Apache-2.0 的专利诉讼终止条款等内容带来了额外限制，因此不接受 Apache-2.0 代码进入基础系统。它也不接受 GPL 代码作为新代码加入基础系统。
这并不是说 Apache-2.0 或 GPL 不符合 OSI 的开源定义，而是 OpenBSD 对「可以接受的自由」有自己的标准。
我认同的正是这种尽可能减少限制的方向。
常见许可证有什么区别？
先把经常遇到的许可证放在一起。下面主要从开发者实际使用和分发代码的角度整理。
| 许可证 | 类型 | 主要特点 |
|---|---|---|
| MIT | 宽松许可证 | 条款简单，保留版权和许可声明即可 |
| MIT-0 | 宽松许可证 | MIT 的简化变体，不要求保留原版权和许可声明 |
| ISC | 宽松许可证 | 与 MIT 非常接近，文本更精简 |
| BSD-1-Clause | 宽松许可证 | 早期 BSD 单条款版本 |
| BSD-2-Clause | 宽松许可证 | 保留版权声明和免责声明 |
| BSD-3-Clause | 宽松许可证 | 在 BSD-2 基础上增加禁止未经许可使用作者姓名背书的条款 |
| 0BSD | 宽松许可证 | 几乎不附加条件，接近公有领域式授权 |
| Apache-2.0 | 宽松许可证 | 包含明确的专利授权和专利诉讼终止条款 |
| GPL-2.0 | 强 Copyleft | 分发衍生作品时通常需要遵守 GPL-2.0 的要求 |
| GPL-3.0 | 强 Copyleft | 增加专利、反锁定和安装信息等方面的规定 |
| AGPL-3.0 | 强 Copyleft | 在 GPL-3.0 基础上增加网络交互场景下的源代码提供要求 |
| LGPL | 弱 Copyleft | 主要针对库，允许在满足条件时被不同许可证的软件使用 |
| MPL-1.1 | 文件级 Copyleft | 修改后的受覆盖文件需要遵守 MPL 条款，兼容机制较旧 |
| MPL-2.0 | 文件级 Copyleft | 允许与其他许可证的代码组合，提供 Secondary License 机制 |
| The Unlicense | 公有领域式授权 | 尝试放弃版权限制，并提供备用许可条款 |
| Public Domain | 公有领域 | 一种版权状态，不是一个统一的许可证名称 |
这里有几个容易混淆的地方。
MIT、ISC、BSD-2-Clause 和 BSD-3-Clause 都属于宽松许可证。它们通常允许将代码放进闭源项目，也允许修改和商业分发。区别主要在于声明保留、免责声明以及背书限制等具体条款。
MIT-0 和 0BSD 则进一步减少了再分发时的要求。它们适合希望尽量减少声明和许可文本负担的场景。
Apache-2.0 也是宽松许可证，但它比 MIT 多了一套明确的专利授权机制。对于企业项目和涉及专利的代码，这一点相当重要。
GPL、LGPL 和 AGPL 则属于 Copyleft 许可证。它们的区别主要在于要求覆盖的范围和触发条件，而不是能不能收费或者商用。
Public Domain 和 The Unlicense 也不应该完全画等号。Public Domain 描述的是作品所处的版权状态；The Unlicense 是一份试图将作品奉献给公有领域、并提供备用许可条款的法律文本。
GPL、LGPL 和 AGPL：Copyleft 到底管什么？
GPL 是 GNU General Public License 的缩写，中文一般称为 GNU 通用公共许可证。
它最重要的特点是 Copyleft。简单理解就是：你可以自由使用和修改 GPL 软件，但如果你向别人分发基于它的衍生作品，就需要遵守相应 GPL 版本的要求，提供对应源代码，并允许下游用户继续行使许可证赋予的权利。
这和 MIT 的思路有明显区别。
MIT 允许你把代码放进一个闭源商业产品，只需要履行版权声明和许可文本保留义务。GPL 则会对分发的衍生作品施加更强的许可证要求。
GPL 还有版本区别。
GPL-2.0 和 GPL-3.0 并不是完全兼容的。一个明确标记为 GPL-2.0-only 的项目，不能随便和 GPL-3.0-only 代码合并后再以 GPL-2.0 或 GPL-3.0 分发。
但如果项目写的是 GPL-2.0-or-later，情况就不同了。因为原作者已经允许使用后续版本，所以可以选择 GPL-3.0。
LGPL 是 Lesser General Public License，通常翻译为 GNU 宽通用公共许可证。它主要用于库，允许其他许可证的软件在满足相应条件的情况下链接和使用它，而不必把整个应用程序都改成 LGPL。
不过，如果你直接修改 LGPL 库本身，修改后的库仍然需要遵守 LGPL 的相关要求。动态链接、静态链接、替换库文件的能力等问题，也可能影响具体的合规方式。
AGPL 则是在 GPL-3.0 基础上增加网络交互场景要求的许可证。
例如，你修改了一个 AGPL 项目，将它部署成网站服务，让用户通过网络使用。即使你没有把程序作为传统软件包分发，AGPL 也可能要求你向这些网络用户提供对应版本的源代码。
这也是为什么很多 SaaS 项目会特别注意 AGPL。
我个人不太倾向于在自己的普通工具项目里使用 GPL 或 AGPL，但这只是许可证选择上的偏好。对于希望确保衍生作品继续保持 Copyleft 属性的项目，GPL 确实有它的用途。
许可证兼容性：代码能不能拿来混用？
这是我觉得最值得认真研究的部分。
看到一个 GitHub 项目使用 MIT，另一个项目使用 BSD-3-Clause，还有一个使用 Apache-2.0，能不能直接把它们的代码复制到自己的项目里？
大多数情况下可以，但需要看具体许可证条款，以及最终的分发方式。
这里先说明一个概念：许可证兼容性不是简单地问两个许可证能不能同时出现在一个仓库里，而是要看它们能不能在同一个组合程序或衍生作品中分发，并且同时满足各自的条件。
例如，两个独立程序放在同一个安装包里，不代表它们就一定形成了一个需要统一许可证的作品。直接复制代码、静态链接、动态链接、通过进程通信调用，也可能产生不同的法律分析。
下面这张表就是我觉得比较直观的对比方式。
纵向表示当前代码的许可证，横向表示最终希望采用的目标许可证。
表格中的符号：
✓：通常可以组合分发，仍需保留原许可证要求。△：有条件，必须检查额外条款、授权声明或具体组合方式。✗：通常不能直接按目标许可证重新分发。—：同一种许可证。
| 当前代码 ↓ / 目标许可证 → | MIT | BSD-2 | BSD-3 | Apache-2.0 | MPL-2.0 | GPL-2.0-only | GPL-3.0 |
|---|---|---|---|---|---|---|---|
| MIT | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| BSD-2-Clause | △ | — | ✓ | ✓ | ✓ | ✓ | ✓ |
| BSD-3-Clause | ✗ | ✗ | — | △ | ✓ | ✓ | ✓ |
| Apache-2.0 | △ | △ | △ | — | △ | ✗ | ✓ |
| MPL-2.0 | △ | △ | △ | △ | — | △ | △ |
| GPL-2.0-only | ✗ | ✗ | ✗ | ✗ | △ | — | ✗ |
| GPL-3.0 | ✗ | ✗ | ✗ | ✗ | △ | ✗ | — |
这张表需要结合下面几个说明一起看，不能把它当成自动授权转换表。
MIT → BSD-3-Clause：
通常可以。MIT 允许修改、合并、再授权和分发，但原始版权声明及许可声明仍然必须保留。不能因为最终项目采用 BSD-3-Clause，就把原来的 MIT 声明删掉。
BSD-3-Clause → MIT：
不能简单地把 BSD-3-Clause 的代码改成 MIT。BSD-3-Clause 有禁止未经许可使用作者姓名背书的额外条件，MIT 不包含完全相同的条件。直接替换许可证可能丢失原授权要求。
Apache-2.0 → GPL-2.0-only：
不兼容。Apache-2.0 有明确的专利授权和专利诉讼终止条款，GPL-2.0 没有相应的兼容机制。
Apache-2.0 → GPL-3.0：
兼容。GPL-3.0 能够处理 Apache-2.0 的相关专利条款，但仍然需要履行 Apache-2.0 的版权、许可证和 NOTICE 等要求。
GPL-2.0-only → GPL-3.0：
不兼容。只有 GPL-2.0-or-later 明确允许选择后续版本时，才能选择 GPL-3.0。
MPL-2.0 → GPL：
需要检查 MPL-2.0 的 Secondary License 条件。并不是所有 MPL-2.0 代码都能无条件转成 GPL。特别要注意文件是否声明了 Incompatible With Secondary Licenses。
另外，MPL-2.0 的 Secondary License 机制明确涉及 GPL-2.0、LGPL-2.1 和 AGPL-3.0 等许可证，不能把它简单理解为与所有 GPL 版本都自动兼容。
还有一个重要区别：兼容不代表原许可证消失。比如 MIT 代码进入 GPL 项目，最终组合作品可以按 GPL 分发，但原 MIT 的版权和许可声明仍然要保留。
所以这张表适合用来初步判断方向，真正发布之前还是应该检查原始许可证全文和项目的具体授权声明。
Apache-2.0 为什么值得单独说？
Apache-2.0 经常被和 MIT、BSD 放在一起比较，因为它们都属于宽松许可证。
但 Apache-2.0 有两个特别值得关注的地方。
第一个是专利授权。
Apache-2.0 不仅处理版权许可，还明确规定了贡献者向使用者授予相关专利权的机制。对于包含复杂算法、网络协议、编解码器或其他可能涉及专利的项目，这一点比 MIT 的简单授权更明确。
第二个是专利诉讼终止条款。
如果你发起诉讼，声称某个 Apache-2.0 作品或其贡献侵犯了你的专利，那么许可证授予你的相关专利权可能会终止。
另外，Apache-2.0 要求保留许可证、版权声明，以及适用时的 NOTICE 文件。修改过的文件还需要有显著的修改声明。
它和 GPL 的关系也很特殊：
- Apache-2.0 与 GPL-3.0 兼容。
- Apache-2.0 与 GPL-2.0-only 不兼容。
- 如果 GPL-2.0 项目明确允许使用后续版本，那么可以选择 GPL-3.0，但这不意味着 Apache-2.0 和 GPL-2.0 本身兼容。
这也是为什么企业项目经常会认真考虑 Apache-2.0，而 OpenBSD 则对它的一些专利条款持不同看法。
MPL-1.1 和 MPL-2.0 有什么不同？
MPL 是 Mozilla Public License，即 Mozilla 公共许可证。
它最有意思的地方是文件级 Copyleft。
GPL 通常会对基于 GPL 代码形成的衍生作品提出较强的许可证要求，而 MPL 的 Copyleft 主要落在包含 MPL 覆盖代码的文件上。
举个例子：
project/
├── src/
│ ├── mpl_parser.c
│ ├── mpl_network.c
│ ├── app.c
│ └── database.c
└── README.md其中 mpl_parser.c 和 mpl_network.c 使用 MPL-2.0。
你修改这两个文件，通常需要按照 MPL-2.0 的要求提供修改后的源代码。
但你另外编写的 app.c 和 database.c，并不会仅仅因为与 MPL 文件处于同一个程序，就自动变成 MPL-2.0。
这就是文件级 Copyleft 和 GPL 常见 Copyleft 范围之间的区别。
MPL-2.0 允许将 MPL 代码与 MIT、BSD、Apache-2.0 等许可证的代码组合在同一个程序中。Mozilla 自己的 FAQ 也明确说明了这一点。
不过，MPL-2.0 还有一个很容易忽略的机制：Secondary License。
它允许在满足条件时，将 MPL 覆盖代码与 GPL、LGPL 或 AGPL 等许可证下的代码组合，作为一个更大的作品分发。
这里有几个条件：
- 相关 MPL 代码不能被标记为
Incompatible With Secondary Licenses。 - 必须确实是 MPL 覆盖代码与其他 Secondary License 作品组合形成的 Larger Work。
- 分发时需要同时满足 MPL 和对应 Secondary License 的要求。
它不是一个随时可以把 MPL 代码单方面改成 GPL 的开关。
MPL-1.1 就没有 MPL-2.0 这么直接的机制。MPL-1.1 有与 GPL/LGPL 组合相关的条款，但需要检查原始授权中是否包含相应的兼容声明。
如果现在新建项目，我会优先考虑 MPL-2.0，而不是继续选择已经比较旧的 MPL-1.1。
MIT 项目修改后，能不能改成 BSD-3-Clause？
回到最开始的问题。
假设我找到一个 MIT 项目，觉得它的实现不错，于是 fork 了一份。随后我修改了大量原有代码，又把自己以前写的很多模块加了进去，最后希望整个项目以 BSD-3-Clause 发布。
这种情况并不罕见。尤其是维护一个长期项目时，经常会遇到从其他 MIT 项目吸收代码的情况。
首先，MIT 本身允许修改、合并、发布、分发和再授权。它要求在软件副本或实质性部分中保留原版权声明和许可声明。
所以，原 MIT 项目的代码可以被修改，也可以进入一个以 BSD-3-Clause 为主要许可证的项目。
但要注意，原作者已经授予的 MIT 权利不会因为你 fork 了项目、修改了代码或者更换了根目录的 LICENSE 文件就消失。
我会把代码分成三类。
第一类：原项目直接复制的代码。
保留原作者版权声明和 MIT 许可证文本，不要把它们删掉。
第二类：基于原项目修改的代码。
保留原作者的版权信息，再增加自己的贡献声明。修改量大并不意味着原作者的版权自动消失。
例如：
/*
* Copyright (c) 2022 Alice
* Copyright (c) 2026 mxd
*
* SPDX-License-Identifier: MIT
*/这里表示整个文件仍按 MIT 授权。如果实际授权安排是同一文件同时适用两套许可证条件，则需要准确表达，例如：
SPDX-License-Identifier: MIT AND BSD-3-Clause但 AND 是两套条件都需要满足，并不是让使用者二选一。
第三类：完全由自己编写的代码。
如果版权确实属于自己，没有其他贡献者或第三方代码限制，那么可以直接采用 BSD-3-Clause：
/*
* Copyright (c) 2026 mxd
*
* SPDX-License-Identifier: BSD-3-Clause
*/项目目录可以这样组织：
my-project/
├── LICENSE
├── LICENSES/
│ └── MIT.txt
├── THIRD_PARTY_NOTICES
├── README.md
└── src/
├── original/
│ ├── parser.c
│ └── network.c
├── modified/
│ └── engine.c
└── new/
├── database.c
├── api.c
└── main.c根目录的 LICENSE 可以放 BSD-3-Clause，作为项目主要许可证；LICENSES/MIT.txt 则保留原项目完整的 MIT 文本。
README 里说明哪些部分采用 BSD-3-Clause，哪些部分仍然包含 MIT 授权的上游代码。THIRD_PARTY_NOTICES 则记录来源、作者、仓库地址和许可证。
这里还要考虑一个问题：如果自己的项目以前也使用 MIT，现在想改成 BSD-3-Clause，是否可以？
如果代码版权完全属于自己，那么可以选择用 BSD-3-Clause 重新发布，也可以同时提供 MIT 和 BSD-3-Clause 两种授权。
但如果项目有其他贡献者，就不能默认自己拥有整个仓库的重新授权权利。需要检查贡献协议、版权归属和已有授权。
同样，之前已经对外授予的 MIT 权利不能被单方面撤销。
因此，我认为比较稳妥的做法是：自己的新代码采用 BSD-3-Clause，原 MIT 代码保留对应声明，整个项目在 README 中明确许可证边界。如果确实希望整个衍生作品统一授权，需要进一步审查原代码的授权关系、贡献者权利和具体分发方式，而不是只修改一个 LICENSE 文件。
SPDX 的 AND、OR 到底怎么用？
SPDX 是 Software Package Data Exchange 的缩写，它提供了一套标准化的许可证标识和表达方式。现在很多开源项目会在源文件头部写：
// SPDX-License-Identifier: MIT它比在每个文件里复制一大段许可证正文更容易管理。
但 SPDX 的表达式也有一些细节。
MIT AND BSD-3-Clause表示必须同时遵守 MIT 和 BSD-3-Clause 的条件。
MIT OR BSD-3-Clause表示可以选择其中一个许可证作为授权依据。
还有：
GPL-2.0-only
GPL-2.0-or-later前者表示只能使用 GPL-2.0，后者表示可以选择 GPL-2.0 或后续版本。
这两个写法在许可证兼容性分析中非常重要。
比如，一个 GPL-2.0-or-later 项目可以选择 GPL-3.0，而 GPL-2.0-only 项目则不能直接这样做。
需要注意，SPDX 表达式应该准确反映实际授权关系。不能因为一个仓库同时包含 MIT 和 BSD 文件，就在所有文件头部都写成 MIT OR BSD-3-Clause。
如果一个文件包含不同来源的代码，应该先弄清楚各部分的授权关系，再决定如何标记。
我还发现一个挺实用的项目：REUSE。它提供了管理源文件版权和许可证信息的规范及工具，适合文件数量比较多、来源比较复杂的项目。
我会怎么选？
如果只是写一个自己的小工具，或者发布一个独立库，我大概率会选 BSD-2-Clause 或 BSD-3-Clause。
MIT 的优势是非常简单，几乎所有开发者都熟悉。BSD-2-Clause 与 MIT 一样简洁；BSD-3-Clause 则多了一个禁止未经许可使用作者姓名背书的条款。
如果比较在意项目名称、作者身份被拿去做宣传，BSD-3-Clause 会更符合我的想法。
ISC 也不错，条款更精简。0BSD 和 MIT-0 则适合希望尽量减少声明义务的场景。
如果项目涉及专利，或者希望明确规定专利授权和专利诉讼终止机制，我会认真考虑 Apache-2.0。不过这并不是 OpenBSD 所偏好的授权方式。
如果希望修改后的文件继续公开，但允许项目其他部分使用不同许可证，可以考虑 MPL-2.0。
如果项目的目标就是确保衍生作品继续保持 Copyleft，那么 GPL 是合理选择；如果主要面向网络服务，还需要考虑 AGPL。
至于 Public Domain 和 The Unlicense，我会先确认目标使用环境和法律适用范围，不会只因为它们看起来限制最少就直接使用。
我不认为存在一个适合所有项目的许可证。许可证选择最终还是取决于项目希望给下游用户多少自由，以及自己是否希望对衍生作品施加条件。
不过，对我自己维护的项目，我会优先选择 BSD 风格的许可证。
我喜欢这种授权方式：你可以拿我的代码去研究、修改、移植、商业化，也可以把它放进闭源产品。你不需要因为使用了我的代码，就必须公开自己的整个项目，更不需要被迫接受某种固定的许可证。
我不要求使用者必须按照我的方式开发软件，也不要求他们把自己的修改交还给我。只要保留必要的版权声明和许可证文本，其他事情交给使用者自己决定。
这也是我认同 OpenBSD 的地方。
当然，BSD 许可证并不意味着没有规则。版权声明、免责声明和 BSD-3-Clause 的禁止背书条款仍然需要遵守。它也不会自动解决专利、商标等所有问题。
但在我看来，这种尽可能减少授权限制、让代码可以自由流动的方式，更接近我理解的开源。
代码被更多人使用，被移植到更多平台，被整合进更多产品，甚至被商业公司拿去闭源使用，我都认为是可以接受的结果。
我更希望别人因为代码本身的质量而选择它，而不是因为许可证要求不得不继续使用它。
参考资料
- OpenBSD Project Goals
- OpenBSD Copyright Policy
- OpenBSD FAQ
- FSF：Various Licenses and Comments about Them
- FSF：License Compatibility and Relicensing
- FSF：Frequently Asked Questions about the GNU Licenses
- OSI：Open Source Licenses
- Apache：Apache License 2.0 and GPL Compatibility
- Mozilla：MPL 2.0 FAQ
- SPDX：License Expressions
- REUSE
本文记录的是个人对开源许可证的理解和整理，不构成法律意见。涉及多位版权持有人、商业分发或大规模重新授权时，应结合实际代码来源和授权记录进行审查。