1. 宽松型协议（Permissive Licenses）
(1) MIT License
核心条款：
允许任意使用（商用、修改、私有化），仅需保留原许可声明。
无专利授权条款，不承担代码使用风险。
适用场景：
个人或企业希望代码被广泛采用（如 jQuery、React）。
不介意他人闭源使用你的代码。
(2) Apache License 2.0
核心条款：
允许商用和闭源，但需保留版权/专利声明。
明确授予专利使用权（贡献者不可通过专利诉讼限制用户）。
修改文件需标注变更说明。
适用场景：
企业项目需专利保护（如 Android、Kubernetes）。
希望代码被集成到商业产品中。
(3) BSD License
变种：BSD 2-Clause（简化版）、BSD 3-Clause（禁止用作者名推广）。
核心条款：
类似 MIT，但 BSD 3-Clause 禁止用作者名义为衍生品背书。
适用场景：
学术或科研项目（如 FreeBSD、Nginx 早期版本）。
2. Copyleft 协议（严格传染型）
(1) GPL（GNU General Public License）
核心条款：
任何分发或修改后的代码必须开源，并采用相同协议（GPL）。
动态链接 GPL 代码的软件也需遵循 GPL（如 Linux 内核）。
适用场景：
强制开源生态（如 Git、GIMP），防止代码被闭源商用。
(2) LGPL（GNU Lesser General Public License）
核心条款：
允许动态链接闭源代码（如库文件），但修改 LGPL 部分仍需开源。
静态链接时需提供闭源程序的兼容接口。
适用场景：
开源库希望被闭源软件广泛使用（如 GLib、FFmpeg）。
(3) AGPL（GNU Affero General Public License）
核心条款：
网络服务（SaaS）使用 AGPL 代码时，必须公开修改后的源码。
适用场景：
防止云服务商闭源使用开源项目（如 MongoDB、Nextcloud）。
3. 其他协议
(1) MPL（Mozilla Public License）
核心条款：
文件级 Copyleft：修改后的文件需开源，但可与其他闭源代码组合。
适用场景：
平衡商业友好与开源要求（如 Firefox、Thunderbird）。
(2) SSPL（Server Side Public License）
核心条款：
若将代码用于提供云服务，需开源服务端整体代码（争议条款）。
适用场景：
开源项目对抗云厂商（如 MongoDB、Elasticsearch）。
4. 协议对比表
协议
允许闭源
要求衍生作品开源
专利授权
典型项目
MIT
✅
❌
❌
React, Rails
Apache 2.0
✅
❌
✅
Android, Kafka
BSD
✅
❌
❌
FreeBSD, Nginx
GPL
❌
✅（传染）
❌
Linux, GIMP
LGPL
✅（动态链接）
✅（修改部分）
❌
FFmpeg, GTK
AGPL
❌
✅（含 SaaS）
❌
MongoDB, Nextcloud
5. 如何选择？
个人/小项目：优先选择 MIT（简单、易推广）。
企业/专利敏感：选择 Apache 2.0（专利保护）。
强制开源生态：使用 GPL/AGPL（防止代码被闭源）。
库/工具开发：考虑 LGPL 或 MPL（平衡商业友好性）。
注意：混合协议需谨慎（如 GPL 代码不可与 MIT 代码直接混合），建议咨询法律专家。