许可证版本升级如何处理旧代码

本文目录导读：

1. 核心前提：旧代码的“遗产”
2. 场景一：你的项目从【宽松许可证】升级为【强Copyleft许可证】（例如：MIT → GPLv3）
3. 场景二：你的项目从【弱 Copyleft】升级为【OSI 认可的更强 Copyleft】（例如：LGPL → GPLv3）
4. 场景三：你的项目从【Copyleft】降级为【宽松许可证】（例如：GPLv3 → MIT）
5. 场景四：升级同一许可证的版本（例如：GPLv2 → GPLv3）
6. 通用操作清单
7. 核心法律风险与行动建议

许可证版本升级时处理旧代码，核心原则是在新许可证的条款下，旧代码的遗留状态不能破坏新许可证的合规性，具体处理方式取决于旧代码的许可证类型和版本升级的方向（如从宽松许可证改为强Copyleft许可证，或反之）。

以下是针对不同场景的详细处理指南：

核心前提：旧代码的“遗产”

旧代码通常指你之前基于旧许可证发布的、已经被他人使用的代码，对于这部分代码，无法单方面撤销或变更已授予的许可，你只能影响未来的新版本。

你的项目从【宽松许可证】升级为【强Copyleft许可证】（MIT → GPLv3）

这是最复杂、风险最高的情况,因为Copyleft许可证要求衍生作品也使用相同许可证。

处理步骤：

1. 明确分界线：

   • 旧版本：已发布的旧版本（如 v1.0 under MIT）永久保留在 MIT 许可证下，用户可以继续使用、修改、分发这些旧版本,不受新许可证影响。
   • 新版本：从 v2.0 开始，所有新发布的代码（包括对旧代码的修改和新增）都采用 GPLv3。

2. 清理贡献者同意（关键）：

   • 必须获得所有旧代码贡献者的书面同意，因为旧代码是 MIT（允许闭源），但 GPLv3 强制要求开源，你不能在未获得原作者许可的情况下，将他们的 MIT 代码“重新许可”为 GPLv3。
   • 实际操作：联系所有旧贡献者，要求他们签署“版权贡献者协议”（CLA），明确同意将他们的代码在 GPLv3 下使用。

3. 代码清理：

   • 从头改写：最安全的方法，但成本高，将需要保留的旧代码模块重写,确保新代码是独立版权。
   • 逐步迁移：将项目拆分为独立模块，旧模块继续保持在 MIT 下，新模块采用 GPLv3，使用清晰的 API 隔离，避免强链接导致传染（如果旧模块被新 GPL 模块静态链接，旧模块也会被传染）。

4. 项目重新发布：

   • 在项目仓库中明确声明：“本仓库 v2.0 及更高版本采用 GPLv3，v1.x 版本仍遵循 MIT 许可。”
   • 在项目主页、README、LICENSE 文件中清晰标注版本升级历史。

⚠️ 禁忌：永远不要直接将旧仓库的 LICENSE 文件和代码头部的许可证声明直接替换,这会导致法律合规风险。

你的项目从【弱 Copyleft】升级为【OSI 认可的更强 Copyleft】（LGPL → GPLv3）

相对简单，因为弱 Copyleft 通常允许库与闭源项目链接。

处理建议：

• 最佳实践：版本号大版本升级（v3.0 → v4.0）时，直接声明新版本采用 GPLv3。
• 通知社区：在发布新版本前至少 3-6 个月通过邮件列表、GitHub Issue 公告,给出明确过渡期。
• 关键矛盾：如果你之前发布了 LGPL 版本的库，用户已将其与自己的闭源软件链接，你的库升级到 GPL 后，并不会强迫这些用户将他们过去基于旧版本开发的、已发布的产品开源，但新发布的、引用新版本库的产品必须遵守 GPL。

你的项目从【Copyleft】降级为【宽松许可证】（GPLv3 → MIT）

这在法律上是可行的，因为 MIT 比 GPL 更宽松（允许闭源）,但需注意：

• 旧版本用户：仍受 GPLv3 约束（已发布的历史版本不可撤销）。
• 新版本用户：可以按 MIT 使用。
• 抄袭争议：如果有人从你的 MIT 新版本中复制了核心算法，但未遵守 GPL 的保留版权声明要求，你需要确保新版本的 MIT 许可证声明清晰且独立。
• 实际操作：同样需要获得贡献者同意（因为贡献者当时同意的是 GPL，现在要改为 MIT，必须征得同意）。

升级同一许可证的版本（GPLv2 → GPLv3）

这是最顺畅的升级。

• “或更高版本”条款：如果你的旧代码在 GPLv2 下且包含“或任何更高版本”（GPLv2 or later）的条款，则直接升级到 GPLv3 无需额外操作。
• “仅此版本”条款：如果旧代码是 GPLv2 only，则不能直接升级，你需要：
  • 保留旧代码（v2 only）
  • 发布新代码时，可以同时提供双重许可选项（用户可以选择 GPLv2 或 GPLv3），或者完全采用 GPLv3，但必须剥离受“v2 only”约束的旧代码。

通用操作清单

核心法律风险与行动建议

1. 最大风险：未经许可，将旧贡献者的代码从宽松许可证强制改为强 Copyleft 许可证,这可能导致侵权诉讼或社区分裂。
2. 最佳策略：版本化隔离，发布“旧许可证”的最后一版（如 v1.0.0），然后发布新许可证的新版本（如 v2.0.0），两者同时存在,互不影响。
3. 社区沟通：提前公告，在计划升级前 3-6 个月通过 GitHub Issue、Discord、邮件列表等渠道通知所有用户和贡献者，解释升级原因、影响范围及迁移计划。
4. 法律咨询：如果项目被大量使用或涉及商业利益,强烈建议在实施前咨询专业的知识产权律师。

一句话结论：你只能控制未来的版本，无法撤销过去，升级意味着创建一条新的“法律版本线”，旧线永久保留原许可证，核心工作在于：获得贡献者同意、隔离代码、明确文档、通知社区。