一份全面的决策指南
目录导读
为什么许可证选择至关重要
许多开发者刚接触开源时，会认为“开源就是免费公开代码”，但实际上，许可证是开源项目的法律骨架，它决定了他人可以如何使用、修改、分发你的代码,也直接影响项目的商业潜力和社区活跃度。
根据GitHub 2024年度的开源调查，超过38%的开源项目因许可证选择不当导致了后续的版权纠纷或商业合作障碍，错误的许可证可能让企业用户因法律风险而放弃使用你的项目，或者让你自己后期想商业化时发现“已无路可走”。
核心原则：许可证不是束缚，而是保护，它保护作者的权利（署名、免责），也赋予用户明确的权利（复制、修改、分发）。
主流开源许可证全景概览
当前，开源促进会（OSI）认可的许可证超过80个，但真正广泛使用的只有约10个，下图按“宽松度”排列：
完全宽松型（几乎无限制）
- MIT License：允许任何人做任何事，只需保留版权声明，最受欢迎,适合希望代码被广泛使用的个人项目。
- Apache 2.0：比MIT多了专利授权条款，保护贡献者免于专利诉讼，适合大型企业级项目（如Kubernetes使用此协议）。
- BSD 2/3-Clause：类似于MIT，但BSD 3禁止用项目名称做推广背书。
弱传染型（对修改有限制）
- LGPL（GNU Lesser General Public License）：允许动态链接的商业使用，但修改库本身必须开源，适合底层库（如FFmpeg）。
- MPL 2.0（Mozilla Public License）：文件级传染，只要求修改过的文件保持开源，未改动的文件可保持闭源,平衡性极佳。
强传染型（要求全部开源）
- GPL 2.0/3.0：如果你的软件使用了GPL代码并分发，整个软件必须按GPL开源，适合希望保护“代码自由”的项目（如Linux内核）。
- AGPL 3.0：针对网络服务场景，即使通过云提供也不允许绕过开源义务,适合SaaS类项目。
特殊用途型
- CC BY-SA 4.0：针对文档、设计资源,不是软件许可证。
- Unlicense / WTFPL：放弃所有版权,相当于公共领域。
快速选择口诀：
想火选MIT，想防专利选Apache，想强制对方开源选GPL,想兼容商业闭源选LGPL或MPL。
选择许可证的五大核心决策维度
你的目标是什么？
- 获得最大用户数 → MIT或Unlicense
- 防止被商用闭源 → GPL或AGPL
- 鼓励贡献但允许商业使用 → Apache 2.0或MPL 2.0
是否依赖其他开源项目？
检查你的项目依赖库的许可证。
- 依赖了GPL的库 → 你的项目必须用GPL兼容许可证（GPL或AGPL）
- 依赖了MIT库 → 可自由选择任何许可证
- 依赖了Apache 2.0库 → 可兼容MIT、GPL v3等
操作建议：使用工具如 license-checker 或 npm-license-crawler 自动分析依赖。
你希望商业变现吗？
- 双许可证模式：社区版用AGPL（强制开源），商业版用自定义商业许可证（如MongoDB的策略）
- 付费提供额外功能：MIT + 付费插件（如WordPress模式）
社区文化偏好
- Python生态：大多偏爱MIT或BSD（如Flask、Requests）
- Java生态：Apache 2.0常见（如Spring、Tomcat）
- 嵌入式/硬件：GPL或LGPL（Linux、Arduino）
法律风险承受能力
- 低风险：使用MIT、不附带专利条款
- 中风险：Apache 2.0（需确保专利授权）
- 高风险：GPL（可能触发衍生作品法律纠纷）
不同场景下的许可证推荐矩阵
| 项目类型 | 推荐许可证 | 理由 |
|---|---|---|
| 个人实验项目 | MIT | 零限制，易于传播 |
| 企业级基础库 | Apache 2.0 | 专利保护，兼容性广 |
| 桌面/移动应用 | GPL v3 | 强制用户开源修改 |
| SaaS/云服务 | AGPL 3.0 | 防止厂商偷偷闭源使用 |
| 文档/教程 | CC BY-SA 4.0 | 鼓励分享再创作 |
| 嵌入式库 | LGPL | 让商业应用可链接使用 |
| 公司开源官方项目 | Apache 2.0 + CLA | 保证版权归属清晰 |
常见误区与避坑指南
误区1：以为GPL能“保护”所有代码。
- 事实：GPL只防止闭源分发，但不阻止内部使用或云服务使用（AGPL才针对云）。
误区2：认为MIT项目可以被任意使用,包括抹去作者名字。
- 事实：MIT要求保留版权声明,删除作者信息属于违规。
误区3：选择“无许可证”代表放弃权利。
- 事实：无许可证默认保留所有版权（All Rights Reserved）,他人无权使用。
误区4：认为BSD与MIT完全等价。
- 事实：BSD 3-Clause禁止使用作者名字做宣传,而MIT不禁止。
操作检查清单：
- [ ] 是否确认所有依赖库的许可证兼容？
- [ ] 是否在代码仓库根目录放置了
LICENSE文件？ - [ ] 是否在项目说明文档中明确写了许可证名称？
- [ ] 是否了解修改代码后是否需要变更许可证？
问答环节：用户最关心的10个问题
Q1：如果我选了MIT，别人能把我代码改成闭源卖钱吗？
A：是的，MIT允许闭源商业使用，如果你不希望这样,请选GPL。
Q2：我的项目用了GPL代码，还能选MIT吗？
A：不能，GPL代码会“传染”整个项目，你必须使用GPL兼容许可证，建议选GPL v3或Apache 2.0（Apache 2.0与GPL v3兼容）。
Q3：AGPL适合个人开发者吗？
A：适合如果你的项目会通过SaaS提供服务，但AGPL可能吓退商业用户,谨慎选择。
Q4：我开源后又想收费，怎么办？
A：使用双许可证模式，例如社区版AGPL,商业版付费获取专有许可。
Q5：Mozilla Public License 2.0 有什么特别？
A：文件级传染，只要求修改过的文件开源，未修改的保持闭源,适合不想整个项目开源的情况。
Q6：我可以给MIT项目增加额外限制吗？
A：可以，但那就不是标准的MIT了，需要自定义许可证,建议尽量避免。
Q7：开源项目能不能中途换许可证？
A：可以，但必须获得所有已有贡献者的同意（除非贡献者签署了CLA），一般做法：保留旧版本旧协议,新版本换新协议。
Q8：是否需要法律审查？
A：如果项目预计商业化或涉及专利，强烈建议咨询律师，复杂场景下,GitHub的官方指南无法替代法律建议。
Q9：Unlicense和WTFPL有什么区别？
A：两者都将代码置于公共领域，Unlicense更正式，有法律文本；WTFPL更随意,但在某些国家法律效力不确定。
Q10：如果我什么许可证都不加，可以吗？
A：代码默认受版权保护，他人无权使用，Open Source Initiative建议：要么选一个OSI认可的许可证,要么明确声明放弃版权。
从合规到生态共建
选择开源许可证，本质上是在“自由”与“控制”之间寻求平衡，没有“最好”的许可证，只有“最合适”的。
在GitHub上，超过90%的项目使用前六大许可证（MIT、Apache、GPL v3、LGPL、BSD、MPL），如果你的场景非常典型，直接选这些即可；如果属于边缘场景（如硬件设计文件、混合闭源+开源项目），建议使用 choosealicense.com 的向导功能。
请记住：把你的选择写清楚，一个没有LICENSE文件的开源项目，等于没有许可，在GitHub创建项目时，务必勾选“Add a license”，并填写正确信息，这是对社区的基本尊重,也是保护你自己最重要的第一步。
参考来源：Open Source Initiative官方文档、GitHub许可证选择指南、ChooseALicense.com、Apache License与GNU GPL官方解读。
