HN讨论 · 身份未知
原仓库已删除时，开源作者如何公开变更旧项目许可证
一位开源项目作者收到复活请求，希望把已从 GitHub 删除的旧项目由 GPLv3 改为 LGPL/MIT。原始仓库已不存在，只有第三方 fork 仍保留旧许可证，作者不确定如何让许可证变更被公开知晓，这暴露了重新许可流程中的具体缺口。
查看原始信号hn:49391444
目标用户
原仓库已删除、项目被第三方 fork 并收到复活或改许可证请求的开源项目作者
潜在需求
需要一种可信且公开的方式，在原始仓库不复存在、只有第三方 fork 仍携带旧许可证的条件下，向所有使用者声明许可证变更。
发生场景
一个旧的开源项目已从 GitHub 删除多年，但第三方 fork 仍存在并继续保留 GPLv3 许可证。现在有人想复活该项目并请求作者把许可证改成 LGPL 或 MIT；作者愿意配合，但不知道在原始仓库不可用的前提下，如何正确、公开地宣布许可证变更。
来源证据
一位开源项目作者愿意将已删除仓库的旧项目从 GPLv3 改为 LGPL 或 MIT，但不知道在只剩第三方 fork 的情况下如何公开声明许可证变更。
I've heard from someone who wants to revive an old abandoned project of mine and asks that I change the license from GPLv3 to LGPL or MIT. I'm willing to do that but I took down the original repo from github a long time ago and there seems to be only a fork that still exists. What's the right way to make it publicly known that I'm changing the license?https://news.ycombinator.com/item?id=49391444
为什么值得留意
提问指向开源项目生命周期中一个具体且真实的流程缺口：重新许可的前提是“让使用者知道”，而原仓库被删除使常见公告渠道失效。这类场景会随旧项目被 fork、复活而出现，维护者需要可操作的公告与记录方法，适合以说明文档、检查清单或流程指引回应。
未满足部分
- 缺少针对“原始仓库已删除、仅剩第三方 fork”场景的许可证变更公开声明方法
- 没有说明如何让 fork 使用者确认新许可证对旧版本代码有效
可能延伸 · 模型推测
- 整理重新许可公告的操作指南、模板或检查清单（模型推测）
- 借助第三方 fork 仓库发布可核验的许可证变更声明（模型推测）
- 提供许可证变更记录与时间戳存证的方式（模型推测）
目前未知
- 作者是否尝试过在 fork 或平台层面发布声明，材料未说明
- 现有其他开源项目的许可证变更实践中是否有现成做法，材料未说明
继续核实
- 有多少开源项目作者或维护者遇到过原仓库删除后的重新许可公告问题？
- 在只剩第三方 fork 的情况下，许可证变更的声明通常通过哪些渠道被认可？
主题词
open source relicensinglicense change announcementabandoned project revivalfork distribution