协议用错了版本，夜里补授权还是等发版前改

晚上十点，协议打包脚本刚跑完，用错夜里同事在群里甩来一句：这个组件是版本补授版前 GPL 的，我们把它塞进闭源安装包里了。权还或者临下班前，协议法务转来一封邮件，用错夜里说产品页面上挂的版本补授版前开源声明少了一个库。再或者，权还招标窗口叫到号，协议对方要看第三方组件清单，用错夜里你才发现某个库的版本补授版前 LICENSE 文件根本没随包发出。这三种场景的权还共同点是：时间不够，但必须马上决定先做什么。协议

先把一件事说清楚：开源协议不是用错夜里“免费就不用管”，也不是版本补授版前“用了就一定会被告”。它是一份附条件的授权，条件没满足，授权就可能中断。所以止损的第一步不是慌，而是判断自己错在哪一层：是没保留版权声明、没附协议文本，还是把带传染性的许可证代码混进了不该混的模块。判断标准很朴素：去看该项目的 LICENSE 原文和仓库里的 NOTICE、COPYING 文件，别只看二手解读。拿不准时，把链接和版本号记下来，问法务或项目维护者，不要靠猜。

做法一：当晚补声明、补源码，先把“可见的错”修掉

适用边界：错在分发环节，比如发布包里缺 LICENSE 文本、缺版权头、修改过的文件没标注；或者用的是 MIT、BSD、Apache-2.0 这类要求相对清晰、以保留声明为主的许可证。

具体动作按顺序来。第一，冻结当前构建产物，别再往外发新包。第二，把对应版本的源码或许可证原文找到，确认没有拿错分支。第三，在安装包、关于页面、文档里补上版权声明和协议全文，修改过的文件加变更说明。第四，如果协议要求提供源码，就把对应源码放到可访问的位置，并在声明里写清获取方式。第五，留一份修复记录，写清哪次发布、哪个组件、改了什么。

选错的后果：如果错在 GPL 这类要求提供完整对应源码的许可证上，只补一句“本产品使用开源软件”远远不够，声明写了但源码没给，问题还在。反过来，如果只是 MIT 组件漏了版权头，你大动干戈去开源整套代码，属于过度反应，白白增加维护成本。所以这一路的边界是：先确认许可证类型，再决定补到什么程度。

做法二：先隔离模块，等下一个版本再动架构

适用边界：错在架构耦合，比如闭源主程序直接链接了 GPL 库，或者把 AGPL 组件放进了对外提供网络服务的后端。这时候当晚补声明解决不了根本问题，需要拆依赖。

动作同样是短步骤。第一，把涉事组件从主构建里摘出来，标记为待替换。第二，评估替换成本：有没有许可更宽松的同类库，或者能不能改成进程间调用、独立服务。第三，在替换完成前，暂停相关功能的对外发布，或者明确内部试用范围。第四，把这次依赖引入的评审环节补上，新组件进仓库前先看 LICENSE。

选错的后果：明明该拆的耦合，只靠补声明蒙混，下一次发版还会带着同样的问题，而且随着代码量增加，替换成本只会更高。反过来，明明只是漏了一份声明，却连夜重构核心模块，容易引入新缺陷，也不划算。这里的分界线是：许可证是否对“衍生作品”或“网络使用”提出了额外义务，这要回到原文判断，拿不准就问专业人士。

判断先走哪条路：看三个具体信号

第一个信号，错的位置在分发包还是在代码结构。前者偏向补声明，后者偏向隔离。第二个信号，许可证类型是否要求提供源码或对网络服务有额外条件。第三个信号，距离下一次对外发布还有多久。如果窗口就在明天，优先做能立刻降低可见风险的事：停发、补文本、记录在案，同时把架构问题列进待办，而不是假装它不存在。

还有一点常被忽略：已经做错时，内部沟通的记录本身就是止损的一部分。把判断依据、谁确认过、下一步谁负责写清楚，比事后口头解释有用。开源协议常识的核心不是背许可证名字，而是知道“条件没满足就先停、再核、后补”。夜里能做完的是补声明和停发，做不完的架构调整，就明确排期，别拖成下一个窗口的同一个问题。

最后收一句：先确认许可证原文和错的层级，再决定是当晚补声明还是隔离模块；两条路都别省掉记录和停发这一步。