同事问我开源协议要背多少条，我让他先做这三个排查

上周三下午，同事条让做后端的问开老周把一段代码贴进群里，说想直接搬进公司项目，源协议背问「这协议能不能用」。多少我回他一句：先别急着看协议名，个排你连它从哪来的同事条让都没确认。判断开源协议常识够不够用，问开靠的源协议背不是背条款，而是多少走一条排查顺序：先排除什么，再查什么，个排哪一步走不通就换下一路，同事条让而不是问开把所有知识并列摊开。

第一步：先排除「协议根本不存在」的源协议背错觉

很多人卡住，不是多少不懂 GPL 和 MIT 的区别，而是个排搞错了前提。仓库首页没写协议，不等于没有协议；README 里一句「仅供学习」，也不等于它是个正式协议。先做这个排除动作：打开仓库根目录，找 LICENSE、LICENSE.md、COPYING 这类文件，再看代码文件头部有没有版权声明。三个地方都没有，你就该按「未声明授权」处理，默认保留所有权利，不能因为代码能下载就当成能商用。

还有一种更隐蔽的情况：项目本身是 MIT，但里面嵌了一个 GPL 的小库。这时候你查仓库根目录的协议文件是查不出来的。判断标准很简单——看依赖清单和 vendor 目录，有没有带自己协议文件的子目录。如果有，那个子目录的协议优先级高于外层。走不通怎么办？把这个子目录单独拎出来查，别用外层的结论覆盖它。

第二步：查协议版本和「or later」这类尾巴

确认协议存在之后，再看的不是条文全文，而是版本号和可选后缀。GPL-2.0 和 GPL-3.0 在专利授权、安装信息要求上差别不小，Apache-2.0 和 Apache-1.1 也不是一回事。实际操作中，先看 LICENSE 文件第一行的标准名称，再看 package.json、pom.xml 或 Cargo.toml 里的 license 字段是否一致。两边打架时，以仓库根目录的协议全文为准，因为构建配置可能是从别处复制来的。

接着留意「or later」这种尾巴。GPL-2.0-or-later 意味着你可以按 2.0 或更高版本履行义务，选择权在你；只写 GPL-2.0 就锁死在 2.0。这一步的判断不需要读完整份协议，但需要你知道自己在选哪个版本。如果项目同时给出多个协议选项，比如「MIT OR Apache-2.0」，那是让你二选一，不是两个都要满足——这一点查错的人不少。

第三步：把「我怎么用它」翻译成义务清单

前两步走通，才轮到判断开源协议常识够不够用。这时候别问「这协议严不严」，要问「我打算怎么分发」。场景不同，义务完全不同。

只在自己公司内部用、不对外提供二进制或源码，大多数宽松协议（MIT、BSD、Apache-2.0）基本只需保留版权声明；但 AGPL 是个例外，它把「通过网络提供服务」也算作分发触发点，SaaS 场景要特别留意。反过来，你要把代码打包进对外发布的客户端，宽松协议要求随附许可证文本和版权声明，这点容易被漏掉，因为它在源码里往往只是一行注释。

再看修改行为。改了 MIT 代码再发布，通常只需保留原版权声明；改了 GPL 代码再发布，衍生部分要按同一协议开放。这里有个具体的核对动作：把你计划发布的形式（源码、二进制、容器镜像、在线服务）逐条写下来，对照协议里「convey」「distribute」这类词的定义，看哪一条被触发。写不出来，说明你还没到「常识够用」的程度，该去读协议原文或问法务，而不是继续在论坛里找二手结论。

最后一步是失败路径。如果查完发现协议是自定义的、或者条款里出现「非商业用途」「仅限评估」这类限制，不要自己解释，直接走下一路：联系维护者确认，或者换一个协议清晰的替代库。自定义协议在技术上都算「源码可见但未开源」，按保守处理不会错。

什么时候可以停下来

把这三步走完，你能说清楚三件事：协议在哪、版本是哪个、我的使用方式触发了哪些义务，那日常开发里的开源协议常识就够用了，不必背条文。剩下真正需要读全文的情形只有两类：一是要把它嵌进有合规要求的商业产品，二是协议本身是 GPL 系或自定义条款。这两种情况交给法务或官方邮件窗口，比自己硬啃划算。老周最后没搬那段代码，因为第二步就卡住了——仓库没协议文件，只有 README 里一句「欢迎使用」。这个结论比背十条协议名有用得多。