开源项目许可证变更如何通知社区

本文目录导读：

1. 通知前的必须准备
2. 通知社区的标准化流程（按时间线）
3. 不同变更场景下的通知重点
4. 常见错误与避坑指南
5. 示例模板（简短版）

开源项目许可证变更是重大事项，处理不当容易引发社区争议甚至法律纠纷，通知社区的核心在于提前沟通、透明解释、提供选择,以下是标准操作流程和最佳实践：

通知前的必须准备

1. 法律合规性确认：

   • 检查项目历史贡献者的授权情况，如果项目采用GPL、Apache 2.0、MIT等允许再许可的许可证（且无额外协议）,权利人可以单方面变更许可。
   • 关键点：如果贡献者是以“贡献者许可协议” (CLA, Contributor License Agreement) 贡献代码，且CLA授予了项目维护者“非排他性、不可撤销”的许可（如Apache 2.0的CLA），则变更通常可行，否则，你可能需要删除先前贡献者的代码并重写,或获得他们的书面同意。

2. 明确变更理由与范围：

   • 为什么改？（从开源社区版转向开源核心+商业闭源、防止被云厂商滥用、切换到更弱/更强的copyleft许可证）
   • 影响谁？ 仅针对未来的版本（常见做法），还是追溯所有历史版本？强烈建议仅对新版本生效,保留旧版本在旧许可证下的使用权利。

通知社区的标准化流程（按时间线）

第一阶段：提前预警（提前3-6个月或更早）

不要突然宣布，先在小范围内吹风,这是在GitHub等平台上的一致做法。

1. 创建公开的 Issue/Discussion：

   • 标题示例：[RFC] Proposed License Change from MIT to AGPL v3.0 或 Under Discussion: Future licensing model for v2.0+
   • 内容：详细阐述变更原因、新许可证对社区的影响、时间线预期。

2. 在项目文档和README显著位置标记：

   • 在README顶部加入横幅：⚠️ NOTICE: We are evaluating a license change to [新许可证]. See discussion #XXX.
   • 在CONTRIBUTING.md中更新关于未来贡献将默认采用新许可证的条款。

第二阶段：正式公告（确定变更前至少1个月）

1. 发布官方博文/邮件列表通知：

   • GitHub Discussions：置顶一个公告帖。
   • Mailing List / Newsletter：如果项目有独立的邮件列表,务必发送。
   • 社交媒体：Twitter (X)/Mastodon/Reddit的r/opensource或相关技术板块。

2. 公告的核心内容（建议包含）：

   • What：新旧许可证名称、版本号、确切URL（链接到开源倡议组织或官方文本）。
   • Why：清晰的商业或法律动机（“为了确保所有贡献代码的实体都能回馈项目”）。
   • When：确切生效的commit、tag或版本号（v2.0.0-rc1 或 2024年6月1日master分支上的commit abc123）。
   • Impact：
     • 旧版本：是否永久保留旧许可证？通常建议保留所有历史版本在旧许可证下的权利。
     • 后续贡献：明确说明从某个commit开始,所有新的代码提交将自动受新许可证约束。
   • 对贡献者的行动指南：现有贡献者是否需要重新签署CLA？他们是否可以选择撤回已贡献的代码（若项目允许）？

第三阶段：执行变更并持续沟通

1. 执行代码与文件变更：

   • 在每个源文件头部更新许可证声明（使用SPDX标准标识符, 如 SPDX-License-Identifier: AGPL-3.0-only）。
   • 更新根目录下的 LICENSE 文件。
   • 更新 README.md、CONTRIBUTING.md、本地化文档中的许可证信息。
   • 在 package.json、Cargo.toml、pyproject.toml 等包管理配置文件中的 license 字段。

2. 创建明确的分水岭Tag：

   • 建议：创建一个新的主版本号（如从v1.x到v2.0），这是最清晰的信号，让用户明白这是一个重大变化,可能需要重新评估是否升级。
   • 在Tag的Release Notes中,再次强调许可证变更。

3. 解决争议与反馈：

   • 如果你收到了大量社区反对，可能需要重新评估或提供例外条款（对非商业使用仍保留旧许可证）。
   • 如果贡献者要求移出代码（他们有权这样做吗？），需启动代码剥离流程。

不同变更场景下的通知重点

常见错误与避坑指南

1. 不要在合并PR后直接修改许可证而不通知

   • 这是最激怒贡献者的行为，必须先讨论，后行动。

2. 不要试图追溯变更已发布的旧版本

   • 一旦代码在一个许可证下发布，该版本的权利通常被视为“授予的，不可撤销”，除非你拥有所有贡献者版权（例如你独自在开发），否则不要更改旧版本的许可证。

3. 不要只用“提交历史注释”通知

   • 很多人不看commit，必须通过多种渠道（GitHub Issue、推特、邮件、博客）进行爆炸式通知。

4. 不要忽略“分布式”用户

   • 使用Docker镜像、Maven中央仓库、npm包的用户可能不会读你的GitHub公告。务必更新所有下游分发渠道（如Docker Hub、Maven Central上的LICENSE文件和项目描述）。

示例模板（简短版）

关于项目[项目名]许可证更新的通知

亲爱的贡献者和用户们，

经过数月的社区讨论，我们决定从v2.0.0版本开始，将项目许可证从 MIT License 变更为 GNU Affero General Public License v3.0 (AGPL-3.0-only)。

关键信息：

1. 旧版本不受影响：所有 v1.x 版本将继续在 MIT 许可证下永久开放。
2. 动机：我们观察到该项目被云厂商直接打包为商业服务却不贡献任何代码改进,AGPL能确保任何提供网络服务的修改都必须开源回馈社区。
3. 后续贡献：从2024年4月1日起，所有对main分支的新的Pull Request都将默认采用AGPL v3.0。
4. 您的选择：如果您对此有异议，可以在此Issue下留言，您也可以fork最后一个MIT版本（v1.5.0）并在MIT下继续开发您的分支。

详细讨论请移步：[链接到讨论Issue]

最终建议：如果项目有法律顾问或基金会支持，请务必让他们审核通知的法律用语，如果是一个小型个人项目，最安全的方式是：仅对新主版本采用新许可证，并付出大量时间在Issue中与每一位有疑虑的用户和贡献者进行一对一解释。