开源协议踩坑后，先别急着删仓库

先给一条能当场核对的开源判断标准：打开项目的 LICENSE 文件或仓库根目录的协议声明，看它是协议否明确写出协议名称和版本号。只有“MIT”“Apache-2.0”“GPL-3.0”这类可检索的踩坑仓库标识，才算有协议；写“仅供学习”“禁止商用”但不给正式文本的后先，等于没授权。别急你如果已经基于这种项目改了代码、着删发了版本，开源现在该做的协议不是继续加功能，而是踩坑仓库停手核对。

先把已发布的后先版本冻住，别再往外发

很多人发现协议问题后的别急第一反应是“我删掉仓库就没事了”。删不掉。着删已经推送到包管理器的开源版本、已经发给客户的协议二进制、已经合并进主分支的踩坑仓库提交，都还在别人手里。正确动作是先冻结：停止打新 tag，停止发布新包，把主分支设为只读或加保护规则。冻结不是认错，是防止问题版本继续扩散。

接着做一次清单：哪些提交引入了该项目的代码，哪些发行版包含这些提交，哪些下游用户拿到过。清单不用完美，但要有时间点和提交哈希，后面回退和沟通都靠它。这一步做不完，别进入下一步。

回退时按提交粒度拆，不要整仓库重来

回退的常见失败是直接 git revert 一个大合并提交，结果冲突一堆，最后手动改错更多。更稳的顺序是：先用 git log 和 git blame 定位引入点，再按文件或按函数拆成小回退。涉及协议传染性的项目（比如 GPL 系列），回退范围要覆盖到“衍生作品”的判断，这个判断自己拿不准就找法务或律师，不要靠搜索问答下结论。

如果代码已经和自研逻辑缠在一起，拆不干净，那就换方案：要么替换成协议兼容的同类库，要么重写那一小块。重写前先确认新库的协议和你的分发方式不冲突。开源协议常识里最容易忽略的一点是“分发方式决定义务”——SaaS 不分发二进制，和发安装包不是一回事，但具体边界仍要看协议原文。

换人不是甩锅，是换一个能签字的人

反复失败的典型场景是：同一个人既写代码又做协议判断，越改越乱。这时候该换的是决策角色，不是换工具。找一个能对发布负责的人——技术负责人或法务——让他对“这份清单能不能发”签字。你负责提供提交记录和依赖树，他负责判断义务范围。两边职责分开，才不会出现“我以为 MIT 可以随便用”的循环。

换人还包括换沟通对象：如果上游项目协议声明含糊，直接去它的 issue 区或邮件列表问，保留书面答复。口头说“随便用”不算授权。拿不到明确答复，就按没有授权处理，这是最省事的止损。

把这次的判断写进依赖准入清单

收尾不是写检讨，是改流程。在引入新依赖时加一道检查：协议名称、版本、是否允许商用、是否要求开源衍生代码。把这条写进 PR 模板或依赖审核表，比事后补救便宜得多。开源协议常识不需要背全文，但要知道 MIT、Apache-2.0、GPL 三类在“能否闭源分发”上的差别，以及遇到不确定时停手核对原文。下次再有人问“这个库能不能用”，先让他把 LICENSE 文件贴出来，再谈别的。