致敬开源协议

这些协议定义了"代码可以被怎样使用、修改、再发布"的边界 —— 它是开源世界的法律基础设施。卡片标注发布年、主导方、官方链接、关键条款与适用场景。

收录标准:OSI-approved 或 SPDX 收录、有官方权威源(opensource.org / SPDX / FSF / Apache 基金会)。共 20 项分 5 组排列。

宽松型(Permissive) 7

弱著佐型(Weak Copyleft) 5

强著佐型(Strong Copyleft) 3

公共领域(Public Domain) 1

商业与特殊(Business / Source-Available) 4

协议兼容关系

不同协议组合使用时是否"能合并"是一个常被问的问题。下面的矩阵是精简版(覆盖工程实践里最常见的组合):

"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 个维度。