本文目录导读：
- 核心前提：旧代码的“遗产”
- 场景一：你的项目从【宽松许可证】升级为【强Copyleft许可证】（例如：MIT → GPLv3）
- 场景二：你的项目从【弱 Copyleft】升级为【OSI 认可的更强 Copyleft】（例如：LGPL → GPLv3）
- 场景三：你的项目从【Copyleft】降级为【宽松许可证】（例如：GPLv3 → MIT）
- 场景四：升级同一许可证的版本（例如：GPLv2 → GPLv3）
- 通用操作清单
- 核心法律风险与行动建议
许可证版本升级时处理旧代码，核心原则是在新许可证的条款下，旧代码的遗留状态不能破坏新许可证的合规性，具体处理方式取决于旧代码的许可证类型和版本升级的方向（如从宽松许可证改为强Copyleft许可证，或反之）。
以下是针对不同场景的详细处理指南：
核心前提：旧代码的“遗产”
旧代码通常指你之前基于旧许可证发布的、已经被他人使用的代码，对于这部分代码，无法单方面撤销或变更已授予的许可，你只能影响未来的新版本。
你的项目从【宽松许可证】升级为【强Copyleft许可证】（MIT → GPLv3）
这是最复杂、风险最高的情况,因为Copyleft许可证要求衍生作品也使用相同许可证。
处理步骤：
-
明确分界线：
- 旧版本：已发布的旧版本（如 v1.0 under MIT）永久保留在 MIT 许可证下，用户可以继续使用、修改、分发这些旧版本,不受新许可证影响。
- 新版本：从 v2.0 开始，所有新发布的代码（包括对旧代码的修改和新增）都采用 GPLv3。
-
清理贡献者同意（关键）：
- 必须获得所有旧代码贡献者的书面同意，因为旧代码是 MIT（允许闭源），但 GPLv3 强制要求开源，你不能在未获得原作者许可的情况下，将他们的 MIT 代码“重新许可”为 GPLv3。
- 实际操作：联系所有旧贡献者，要求他们签署“版权贡献者协议”（CLA），明确同意将他们的代码在 GPLv3 下使用。
-
代码清理：
- 从头改写：最安全的方法，但成本高，将需要保留的旧代码模块重写,确保新代码是独立版权。
- 逐步迁移：将项目拆分为独立模块，旧模块继续保持在 MIT 下，新模块采用 GPLv3，使用清晰的 API 隔离，避免强链接导致传染（如果旧模块被新 GPL 模块静态链接，旧模块也会被传染）。
-
项目重新发布：
- 在项目仓库中明确声明：“本仓库 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”约束的旧代码。
通用操作清单
| 步骤 | 关键点 | |
|---|---|---|
| 版权审计 | 识别所有旧代码的贡献者、第三方依赖及其许可证。 | 确保你拥有所有代码的版权（或已获得再许可权）。 |
| 获得许可 | 联系所有贡献者，获取他们同意新许可证的书面证明。 | 这是法律底线，未获得同意前，不能修改他们的代码许可证。 |
| 代码标记 | 在新版本的文件头中，明确注释：“Based on work from v1.0 (MIT), modifications from v2.0 (GPLv3)”。 | 清晰区分新旧部分的法律状态。 |
| 项目文档 | 在 README 和 LICENSES 目录下，明确列出旧版本和新版本的许可证文件。 | LICENSE-v1.0-MIT.txt，LICENSE-current-GPLv3.txt。 |
| 版本隔离 | 如果无法获得同意，考虑将旧代码作为一个独立的、历史分支（如 archive/old-license），新项目从头开始基于新许可证。 |
避免法律风险。 |
| 依赖处理 | 检查新许可证是否与项目依赖的第三方库许可证冲突。 | GPLv3 与某些非商业许可证不兼容。 |
核心法律风险与行动建议
- 最大风险：未经许可，将旧贡献者的代码从宽松许可证强制改为强 Copyleft 许可证,这可能导致侵权诉讼或社区分裂。
- 最佳策略：版本化隔离，发布“旧许可证”的最后一版（如 v1.0.0），然后发布新许可证的新版本（如 v2.0.0），两者同时存在,互不影响。
- 社区沟通：提前公告，在计划升级前 3-6 个月通过 GitHub Issue、Discord、邮件列表等渠道通知所有用户和贡献者，解释升级原因、影响范围及迁移计划。
- 法律咨询：如果项目被大量使用或涉及商业利益,强烈建议在实施前咨询专业的知识产权律师。
一句话结论：你只能控制未来的版本，无法撤销过去，升级意味着创建一条新的“法律版本线”，旧线永久保留原许可证，核心工作在于：获得贡献者同意、隔离代码、明确文档、通知社区。
