开源许可证选择器 - 帮您选择开源协议

Copyleft 是一种特殊的开源授权方式，其核心理念是「使用 Copyleft 许可证发布的代码，其衍生作品也必须以相同或兼容的许可证开源」。这与普通宽松许可证（如 MIT、BSD）形成鲜明对比——宽松许可证允许用户将代码整合到闭源商业产品中，而 Copyleft 许可证则要求修改和扩展后的代码继续保持开源。Copyleft 的典型代表是 GPL 系列许可证，它通过「传染性」机制确保软件的自由性在衍生作品中得以延续。对于希望确保代码始终保持开源的项目，Copyleft 是理想选择；对于希望最大化代码传播和商业应用的项目，宽松许可证更为合适。

MIT 和 Apache 2.0 都属于宽松许可证，主要区别在于三个层面。第一，MIT 极其简洁（仅约 170 个英文单词），而 Apache 2.0 篇幅较长，包含了更详细的法律条款。第二，Apache 2.0 包含明确的专利授权条款——贡献者授予用户永久的、不可撤销的专利使用权，而 MIT 没有专利相关条款。第三，Apache 2.0 要求对修改过的文件进行标注说明，MIT 仅要求保留版权声明。选择建议：如果你的项目涉及专利技术或希望为使用者提供专利保护，优先选择 Apache 2.0；如果追求最大程度的简洁性和宽松性，MIT 是更好的选择。对于库类型的项目，MIT 更受欢迎（因为对下游更友好）；对于应用型项目，Apache 2.0 的专利保护更有价值。

GPL v2 和 GPL v3 的核心差异体现在四个方面。第一，GPL v3 新增了反 Tivoization 条款，防止硬件厂商通过硬件限制阻止用户运行修改后的软件。第二，GPL v3 包含了明确的专利授权和反专利诉讼条款，为用户提供更强的专利保护。第三，GPL v3 兼容更多其他许可证，而 GPL v2 的兼容性较窄。第四，GPL v3 的语言更现代化，条款更清晰。是否升级取决于项目需求：如果项目不涉及硬件锁定问题且不需要额外的专利保护，继续使用 GPL v2 是完全可以的；如果希望获得更强的用户保护和更好的许可证兼容性，可以考虑升级。注意，GPL v2 本身有一个「或任何后续版本」的选项，如果原始声明中包含此表述，则自动兼容 v3。

AGPL（Affero General Public License）主要适用于 SaaS（软件即服务）和 Web 应用场景。AGPL 与 GPL 的核心区别在于「远程网络交互」条款：GPL 许可证只要求分发软件时开源，如果仅通过网络提供服务（不分发二进制或源代码），GPL 不触发开源义务；而 AGPL 明确规定，即使仅通过网络提供服务，用户与软件交互时也必须提供源代码。典型适用场景包括：公有云平台上的开源软件、Web 应用后端服务、API 服务等。如果你的项目以 SaaS 模式运营且希望确保服务端代码的开源性，AGPL 是合适的选择。需要注意的是，AGPL 的传染性较强，许多企业对使用 AGPL 组件持谨慎态度。

许可证变更是一个复杂但可行的操作，需要满足以下条件。首先，如果你是项目的唯一版权持有者，你有权随时更改许可证，只需在新版本中明确声明新的许可证即可。其次，如果项目有多个贡献者，你需要获得所有贡献者的同意才能更改许可证（除非原始贡献协议中已授权你进行许可证变更）。第三，已经按照旧许可证分发的版本，其许可证条款不可追溯更改——即已获取旧版本的用户仍然按照原许可证条款使用。实际操作中，建议在项目初期就选定合适的许可证，避免后期变更带来的法律风险和社区争议。如果确实需要变更，建议通过邮件列表或 GitHub 讨论与贡献者充分沟通，并保留所有同意变更的书面记录。

BSD 2-Clause（简化 BSD 许可证）和 BSD 3-Clause（新 BSD 许可证）的主要区别在于是否包含「非背书条款」。BSD 2-Clause 仅要求保留版权声明和免责声明，而 BSD 3-Clause 额外增加了一条规定：未经许可不得使用项目名称、作者姓名或贡献者姓名进行产品推广或背书。这个额外条款的目的是防止他人利用你的名义为衍生产品背书。选择建议：大多数情况下 BSD 2-Clause 已经足够，它更加简洁且宽松；如果你担心品牌被滥用或希望对项目名称的使用施加更多控制，可以选择 BSD 3-Clause。值得注意的是，BSD 3-Clause 是目前更主流的选择，Linux 内核之外的许多知名项目（如 FreeBSD）都采用此许可证。

LGPL（Lesser General Public License）确实是为库开发设计的许可证。LGPL 与 GPL 的核心区别在于「传染性」的范围：GPL 要求所有使用了 GPL 代码的衍生作品都必须开源，而 LGPL 允许闭源软件动态链接 LGPL 库而无需开源自身代码。具体来说，如果你的项目动态链接了 LGPL 库，你的项目可以选择不开源；但如果你修改了 LGPL 库本身的代码，修改部分必须以 LGPL 开源。LGPL v2.1 要求用户能够替换 LGPL 库（即支持动态链接），LGPL v3 在此基础上增加了反 Tivoization 和专利条款。适用场景：如果你开发的是工具库且希望被尽可能多的项目（包括商业项目）使用，LGPL 是理想选择；如果你希望确保所有衍生作品都保持开源，应选择 GPL。

MPL 2.0（Mozilla Public License 2.0）采用独特的「文件级 Copyleft」机制，这意味着传染性仅限于 MPL 授权的源文件本身。具体来说：如果你修改了 MPL 授权的文件，修改后的文件必须以 MPL 2.0 开源；但如果你在自己的文件中新增代码（不修改 MPL 文件），新增部分可以选择任何许可证，包括闭源。这使得 MPL 2.0 成为一种「弱传染性」许可证，介于 MIT/Apache（无传染性）和 GPL（强传染性）之间。MPL 2.0 的典型应用案例是 Firefox 浏览器——Mozilla 使用 MPL 授权其核心代码，允许第三方扩展以不同许可证发布。适用场景：如果你希望自己的代码修改保持开源，但不强制要求集成到更大项目中的其他代码也开源，MPL 2.0 是一个平衡的选择。

Unlicense 确实旨在将作品置入公共领域，相当于放弃所有版权和相关权利。但需要注意的是，不同司法管辖区对「放弃版权」的法律效力认定不同——在某些国家，作者可能无法完全放弃精神权利（如署名权）。Unlicense 的核心声明是：该作品以公共领域方式提供，任何人可以不受限制地使用、修改、分发。适用场景包括：个人学习项目、示例代码、教程素材、不受专利保护的简单工具等。不推荐用于可能涉及专利的项目（因为 Unlicense 不包含专利授权条款），也不推荐需要品牌控制的项目（因为 Unlicense 不包含商标保护）。与 CC0（Creative Commons Zero）相比，Unlicense 专为软件设计，而 CC0 适用于各种创意作品。如果你希望代码完全自由且不附加任何条件，Unlicense 是最简洁的选择。

MIT 许可证中的「above copyright notice」指的是许可证文本开头包含的版权声明行，通常格式为「Copyright (c) [年份] [版权所有者]」。这句话的含义是：当你分发软件时，必须在软件副本或显著位置保留原始的版权声明。实际操作中，你需要确保在代码仓库的 LICENSE 文件、源代码文件头部、以及软件的「关于」页面或文档中包含原始的版权信息。这个要求是 MIT 许可证唯一的强制性义务（除了保留许可证文本本身）。需要注意的是，「above」并非要求版权声明必须在物理位置上位于许可证文本的上方，而是指许可证文本中引用的那行版权声明。正确理解这一点可以避免在合规审查时产生不必要的困惑。

判断许可证兼容性的基本原则是：如果许可证 A 的条款允许在 GPL 许可证下重新分发，那么 A 就与 GPL 兼容。GNU 官方维护了一份许可证兼容性列表，可以直接参考。兼容性判断的关键考量包括：第一，A 是否要求与 GPL 相同或更宽松的条件；第二，A 是否包含与 GPL 冲突的附加限制（如不允许商用、不允许修改等）；第三，A 是否包含专利条款与 GPL 产生矛盾。常见的兼容性情况：MIT、BSD、Apache 2.0 与 GPL 兼容；LGPL 与 GPL 兼容（但反向不兼容，即 GPL 代码不能用 LGPL 授权）；AGPL 与 GPL v3 兼容；MPL 2.0 与 GPL 兼容（需在 MPL 文件层面进行重新授权）。实际项目中，建议优先选择已知与 GPL 兼容的许可证，避免在组合使用不同许可证时产生法律冲突。

企业在使用开源组件时需要关注以下关键风险点。第一，Copyleft 传染性风险：如果产品中集成了 GPL/AGPL 代码，可能被要求将整个产品开源，这对闭源商业软件是致命的。建议在引入 GPL 组件前进行严格的法律评估。第二，专利风险：某些许可证（如 Apache 2.0）包含专利授权，而另一些（如 MIT）不包含，使用不含专利授权的许可证可能面临专利诉讼风险。第三，商标风险：大多数开源许可证不授权使用项目名称或商标，企业不得在营销中使用开源项目的名称暗示关联关系。第四，合规文档缺失：未正确保留版权声明、未提供源代码、未满足许可证的其他义务，可能导致法律纠纷。第五，许可证冲突：在同一产品中混合使用不同许可证的组件时，需要确保许可证之间不冲突。建议企业建立开源治理流程，包括引入前的许可证审查、使用中的合规检查、发布前的许可证审计，以及持续的合规监控。