协议选错了再改代码，代价往往比想象大

上周有位读者把公司一个小工具开源到代码托管平台，协议选错象选了最宽松的再改协议，结果两周后合作方拿去做了闭源商用，代码代连署名都没留。往往他想回头改成带传染性的比想协议，却发现已经有人基于旧版本拉了分支，协议选错象改动根本收不回来。再改这就是代码代典型的顺序错了：先传代码，后想协议。往往正确的比想顺序是反过来的——动手之前先问自己三个选择问题，再决定买不买、协议选错象改不改、再改装不装。代码代

问题一：这份代码将来要不要被别人闭源使用

这是往往最优先的判断。如果你的比想目标是“谁都能用，包括拿去卖钱的产品”，那宽松型协议（如 MIT、Apache-2.0、BSD 系列）符合预期；如果你希望“基于我的代码改出来的东西也必须继续开源”，那就要考虑带传染性的协议（如 GPL 系列、AGPL）。注意 AGPL 的触发点在网络服务：即使不分发二进制，只要通过网络对外提供服务，也可能被要求开放源码。做 SaaS 的人尤其要在选型前确认这一点，别等上线后才翻协议原文。

判断标准很简单：问自己一句“别人拿它赚钱却一行代码不回馈，我能不能接受”。能接受，选宽松；不能接受，选传染性。拿不准就别急着发布，先看协议全文和官方 FAQ，OSI（开放源代码促进会）与 SPDX 的协议列表是可以核对的来源，别只信二手博客的概括。

问题二：仓库里有没有混进不该开源的第三方代码

很多人栽在这里。项目里引了一段来路不明的工具函数，或者从某处复制了一个文件，作者没写协议，你默认它“没有限制”——这是错的。没有声明协议不等于公共领域，默认仍受著作权保护。这种代码一旦进了你的仓库，你再套一个 MIT 发布，等于替别人做了授权决定，后续被追责时很难收场。

动手顺序应该是：发布前逐个核对依赖和复制片段的来源与协议，把不兼容的组合剔出去。常见的不兼容场景是宽松协议代码里混入 GPL 片段，整体就可能被迫按 GPL 处理。这一步不该省，也不该靠“应该没事”蒙过去。如果某个依赖的协议查不到，最稳的处理是替换掉它，而不是赌。

问题三：你是只自己用，还是要分发或对外提供服务

只在自己机器上跑，协议约束基本不触发；一旦分发（发安装包、发容器镜像、给别人拷源码）或对外提供网络服务，义务就来了。所以“要不要装”这件事也得先想清楚：装一个 GPL 的命令行工具自用，没问题；把它打包进你卖给客户的闭源产品里，就要看具体条款，不能一概而论。

同样，“要不要改”也分场景。改开源项目自用，通常只需保留原协议和版权声明；改完再分发，还得看是否构成衍生作品。这里边界模糊，涉及商业产品时建议找熟悉知识产权的律师确认，别自己拍板。

已经选错了，止损的先后顺序

如果已经发布且协议选错，先别慌着删仓库——删除往往不能消灭已经流出的副本，反而让你失去对版本历史的说明能力。可行的顺序是：第一，确认当前协议文本和仓库内 LICENSE 文件是否一致，很多“选错”其实是文件没放对；第二，梳理已发布版本的时间线和对外分发记录，弄清哪些人拿到了哪个版本；第三，如果只是想收紧未来版本，可以在新版本换协议，但旧版本授权通常无法单方面撤销，这点要如实告知合作方；第四，主动联系已使用的下游，协商补上署名或调整使用方式，比事后追责更现实。

止损的核心不是“把协议改回去”这一个动作，而是把授权链条讲清楚。开源协议常识的价值就在这里：它约束的不是代码本身，而是你和使用者之间的权利义务关系。三个选择问题问完再动手，比出了问题再补救省事得多。真要落到具体条款争议，官方协议文本和专业人士的意见，永远比论坛里的经验帖可靠。