致敬开源协议
这些协议定义了"代码可以被怎样使用、修改、再发布"的边界 —— 它是开源世界的法律基础设施。卡片标注发布年、主导方、官方链接、关键条款与适用场景。
收录标准:OSI-approved 或 SPDX 收录、有官方权威源(opensource.org / SPDX / FSF / Apache 基金会)。共 20 项分 5 组排列。
宽松型(Permissive) 7
-
MIT License
极致宽松:允许任意使用、修改、闭源衍生、再发布,只需保留版权与许可声明。GitHub 上最常见协议(约 50%+ 仓库)。适用:希望最大化传播、不强制衍生开源的库与工具。
opensource.org/licenses/MIT -
BSD 2-Clause "Simplified" License
"FreeBSD 许可证"前身:仅要求保留版权声明与免责声明,不提及"非 endorsement"条款。适用:与 MIT 几乎等价,但与 FreeBSD 生态更兼容。
opensource.org/licenses/BSD-2-Clause -
BSD 3-Clause "New" / "Revised" License
在 2-Clause 基础上加"非 endorsement"条款:禁止用项目方之名为衍生作品背书。适用:希望保留商标/品牌控制权的项目。
opensource.org/licenses/BSD-3-Clause -
ISC License
功能等价于简化 BSD + MIT,被 OpenBSD、bind9、nginx 等网络工具采用。措辞比 MIT 略严谨。适用:网络服务、工具软件。
opensource.org/licenses/ISC -
Apache License 2.0
在 BSD 基础上加"专利授权":贡献者明示授予用户相关专利使用权;衍生作品需标注修改。Apache 基金会、Hadoop、Kubernetes、Android 大量使用。适用:涉及专利的工业级项目。
www.apache.org/licenses/LICENSE-2.0 -
0BSD ("Free Public License 1.0")
"无任何保留"的 BSD:连版权声明都不要求保留,等同于公共领域。SPDX 收录。适用:希望"最自由"的代码片段与配置。
spdx.org/licenses/0BSD.html -
Unlicense
把代码自愿放弃所有版权,置于公共领域。法律上比 CC0 简洁、但仅在部分法域有效。适用:示例代码、纯个人小工具。
unlicense.org
弱著佐型(Weak Copyleft) 5
-
GNU Lesser General Public License v2.1
允许闭源程序"动态链接"LGPL 库,但库本身的修改必须以 LGPL 发布。FFmpeg、Qt(早期)、glibc 等都使用。适用:C/C++ 库。
www.gnu.org/licenses/old-licenses/lgpl-2.1.html -
GNU Lesser General Public License v3.0
LGPL 2.1 升级版:加专利条款、禁止数字锁(Tivoization)、与 GPL 3.0 兼容。适用:与 GPL 生态保持长期兼容的库。
www.gnu.org/licenses/lgpl-3.0.html -
Mozilla Public License 2.0
"文件级 copyleft":被许可文件须以 MPL 衍生,组合作品可保留其他许可。Firefox、Servo、HashiCorp 部分项目使用。适用:大型混合代码库。
www.mozilla.org/en-US/MPL/2.0 -
Eclipse Public License 2.0
商业友好:允许与 GPL 兼容、专利授权、可选 secondary license。Eclipse IDE、JetBrains 部分项目使用。适用:IDE、企业中间件。
www.eclipse.org/legal/epl-2.0 -
Common Development and Distribution License 1.0
文件级 copyleft + 专利条款,由 Sun 为 OpenSolaris 制定;与 GPL 不兼容。NetBeans 等部分 Solaris 衍生项目使用。适用:Java 生态历史项目。
opensource.org/licenses/CDDL-1.0
强著佐型(Strong Copyleft) 3
-
GNU General Public License v2.0
强著佐:任何"基于作品"的衍生(含静态链接)必须以 GPL 发布。Linux 内核、Git、WordPress 等采用。适用:希望保证衍生作品保持自由的系统级软件。
www.gnu.org/licenses/old-licenses/gpl-2.0.html -
GNU General Public License v3.0
GPL 2.0 升级:加专利条款、禁止数字锁(Tivoization)、强化国际兼容性。Bash、GCC、Let's Encrypt、systemd 等采用。适用:自由软件阵营核心项目。
www.gnu.org/licenses/gpl-3.0.html -
GNU Affero General Public License v3.0
GPL + 网络条款:服务端通过网络提供服务也算"分发",必须向网络用户开放源码。Mastodon、Nextcloud、ONLYOFFICE 等 SaaS 项目采用。适用:必须开源的 SaaS / 网络服务。
www.gnu.org/licenses/agpl-3.0.html
公共领域(Public Domain) 1
商业与特殊(Business / Source-Available) 4
-
Business Source License 1.1
"源码可见但非开源":非生产使用免费,4 年后转 Apache 2.0。MariaDB、HashiCorp Terraform、CockroachDB 早期版本使用。适用:商业模式想"延迟开源"的项目。
mariadb.com/bsl11 -
Server Side Public License v1
AGPL 风格 + 严苛:禁止把软件作为托管服务提供而不开放衍生。MongoDB 2018 年从 AGPL 切换至 SSPL 应对云厂商"挖走"。适用:担心云厂商零分成的数据库。
www.mongodb.com/licensing/server-side-public-license -
Elastic License v2
禁止托管服务、不禁止内部使用、不限制修改。ElasticSearch 在 2021 年从 Apache 2.0 切换至此。适用:担心云厂商白嫖的 SaaS 后端。
www.elastic.co/licensing/elastic-license -
Fair Source License
按用户数分级:≤ 50/100/1000 用户的项目可闭源使用,超过须开源或购买许可。Sentry、GitButler 早期采用。适用:希望"按规模开源"的中间路线。
fair.io
协议兼容关系
不同协议组合使用时是否"能合并"是一个常被问的问题。下面的矩阵是精简版(覆盖工程实践里最常见的组合):
"A → B 兼容" 指 A 协议代码可被 B 协议项目包含/分发;"双向"指反之亦然;"不兼容"指默认情况下需额外行动。
| A 协议 | B 协议 | 兼容性 | 备注 |
|---|---|---|---|
MIT | Apache-2.0 | 兼容(双向) | 双方互认,最常组合 |
BSD-3-Clause | Apache-2.0 | 兼容(双向) | BSD 需保留版权声明 |
MIT | GPL-2.0 | 兼容(单向:MIT 代码可进 GPL 项目) | GPL 项目不能并入 MIT-only 项目 |
MIT | GPL-3.0 | 兼容(单向) | 同 GPL-2.0 |
Apache-2.0 | GPL-2.0 | 不兼容 | Apache 专利条款不兼容 GPL 2.0 |
Apache-2.0 | GPL-3.0 | 兼容(双向) | 2010 年 Apache 加入 GPL 3.0 兼容条款 |
LGPL-2.1 | GPL-2.0 | 兼容(单向:LGPL 库可被 GPL 项目静态链接) | GPL 项目并入 LGPL 库需遵循 LGPL |
LGPL-3.0 | GPL-3.0 | 兼容(双向) | — |
MPL-2.0 | GPL-2.0 | 兼容(单向:MPL 文件可并入 GPL-2.0) | MPL 文件保留 MPL |
MPL-2.0 | Apache-2.0 | 兼容(双向) | MPL 2.0 明确加入 Apache 2.0 兼容 |
EPL-2.0 | GPL-3.0 | 兼容(双向) | EPL 2.0 明确加入 GPL 3.0 兼容 |
CDDL-1.0 | GPL-2.0 | 不兼容 | FOSS 争议结论 |
AGPL-3.0 | GPL-3.0 | 兼容(单向:AGPL 改 GPL 需降级为 GPL 触发义务) | — |
BSL-1.1 | MIT | 不直接兼容(BSL 4 年后转 Apache 2.0) | 时间触发后 |
Unlicense | 任何 | 兼容(公共领域) | 无版权 |
CC0 | 任何 | 兼容(公共领域) | 国际覆盖更广 |
协议范本关键条款
下面摘录是各协议"最核心"的 1-2 句 —— 快速看清协议意图。
注意:使用协议时仍需到 opensource.org/licenses / FSF / Apache 等官方源获取完整文本,原文是法律生效版本。
MIT / BSD 核心句
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction... THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.
Apache 2.0 专利句
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work.
GPL 3.0 核心句
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty... you must give the recipients all the rights that you have.
LGPL 3.0 链接条款
You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL, provided that you also meet the terms of this License... a combined work, a copy of the Library is needed for the combined work to function.
MPL 2.0 文件级 copyleft
The contents of this file may be used under the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/. Any modifications to this file must be made available under the terms of the MPL.
AGPL-3.0 网络条款
If you modify the Program, your modified version must prominently offer all users interacting with it remotely (through a network) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server.
为什么致敬开源协议
选协议是项目方"最重要的一行决定"之一。它影响 5 年、10 年后你的代码还能不能被用、被用在哪、对使用者意味着什么。把协议本身作为对象来介绍,是为了给项目方一个"看全所有选项"的入口。
常见问题
CalcGuide 致敬开源协议收录了哪些协议?
共 20 项分 5 组:宽松型(MIT / BSD 2-Clause / BSD 3-Clause / ISC / Apache 2.0 / 0BSD / Unlicense)、弱著佐型(LGPL 2.1 / LGPL 3.0 / MPL 2.0 / EPL 2.0 / CDDL 1.0)、强著佐型(GPL 2.0 / GPL 3.0 / AGPL 3.0)、公共领域(CC0)、商业与特殊(BSL 1.1 / SSPL v1 / Elastic v2 / Fair Source)。
为什么 Apache 2.0 项目可以和 GPL 3.0 项目合并,而不能和 GPL 2.0 合并?
2010 年 Apache 基金会发布了 Apache 2.0 版本 2 补丁,引入"如果在 GPL 3.0 下分发则允许"条款,使 Apache 2.0 与 GPL 3.0 双向兼容。GPL 2.0 不承认这条专利条款,因此 Apache 2.0 与 GPL 2.0 在专利维度上不兼容。
LGPL 和 GPL 怎么选?
LGPL 适合"库":闭源程序可动态链接 LGPL 库而无需开源,但库的修改必须以 LGPL 发布。GPL 适合"程序":使用 GPL 库的程序也必须以 GPL 发布。Mozilla 与 Qt 早期都从 GPL 切换到 LGPL 正是因为想让闭源软件能链接他们的库。
AGPL 3.0 比 GPL 3.0 多了什么?
AGPL 增加了"网络条款":即使你没有"分发"软件(仅通过互联网提供 SaaS 服务),也必须向网络用户开放源码。这是 2013 年 MongoDB 早期、2017 年 Nextcloud 等 SaaS 项目选择 AGPL 的原因 —— 防止云厂商零分成地托管服务。
为什么 BSL / SSPL / Elastic License 被列在"商业"而不是"开源"?
OSI(Open Source Initiative)定义"开源"必须满足分发自由、不歧视用途等 10 条标准。BSL / SSPL / Elastic License 限制托管服务或商业使用,违反 OSI 定义。它们是"源码可见"(source-available)而非"开源"(open source),但工业上影响巨大,仍值得收录。
项目方应如何选择协议?
三步:① 想要最大化传播(库/工具)→ MIT / BSD / Apache 2.0;② 想要保证衍生作品保持自由(系统/平台)→ GPL 3.0 或 AGPL 3.0;③ 想要库能被闭源程序链接(库)→ LGPL 3.0 或 MPL 2.0。
协议范本可以复制粘贴到我的项目吗?
LICENSE 文件应用整份协议原文。卡片里的"关键条款"是协议最核心的 1-2 句引文,用于快速理解协议意图 —— 不替代完整协议文本。完整协议请通过卡片链接到 opensource.org / FSF / Apache 等官方源获取。
← 返回致敬枢纽,查看全部 10 个维度。