夜里赶着交差，开源协议怎么三步判断

晚上十一点，夜里明天一早要发版，交差法务窗口九点才叫号；或者你正坐在办事大厅，开源屏幕上的协议号已经跳到前面三位。这种时候没人有耐心从头读一份许可证全文。步判你要的夜里不是一篇开源协议发展史，而是交差一个能在几分钟内做完的简化判断。下面这套三步，开源只解决“赶时间、协议没窗口、步判必须马上给个说法”的夜里场景，其余的交差尽调、归档、开源逐条比对，协议一律留到白天再补。步判

第一步：先看代码从哪来，别急着读条文

拿到一个项目，先别打开 LICENSE 文件。先问自己一句：这份代码是我从别人仓库整包拷来的，还是我自己写的、只是引了几个依赖？这两种情况的判断路径完全不同。整包拷来的，协议跟着原仓库走，你改不了；自己写的，协议由你选，但依赖会把义务传导进来。

赶时间的做法是：打开项目根目录，先找 LICENSE、LICENSE.txt、COPYING 这类文件名，再看 package.json、pom.xml、requirements.txt 里有没有 license 字段。两分钟能定位到“有没有声明”。如果根目录什么都没有，而你又确实是从某仓库拉的，回到那个仓库首页右侧或仓库根目录找，GitHub 这类平台通常会把许可证显示在仓库信息栏。找不到不等于没有协议，只等于“没写清楚”，这种情况在夜里最危险，因为它没法在几分钟内定性。

举个具体例子：同事把一个工具库的整个目录拖进你的项目，说“随便用”。你打开一看，根目录有 LICENSE，正文第一行是 MIT。这就属于“整包拷来、协议明确”，后面两步可以走得很快。反过来，如果那个目录里只有源码和 README，没有任何许可文件，你就不能默认它是随便用。

第二步：认三五个高频名字，别在长条文里迷路

许可证名字很多，但赶时间时真正要先认出来的就那么几类。看到 MIT、BSD 这类，通常义务集中在“保留版权声明和许可声明”，改动后一般不需要公开你的源码；看到 Apache-2.0，除了保留声明，还要注意它带专利授权条款和 NOTICE 文件的要求；看到 GPL 系列，就要立刻警觉：它属于会向整个作品传导义务的强 copyleft 协议，你把它嵌进闭源产品，问题不在今晚能不能跑通，而在将来分发时怎么办。

还有一个高频但容易看错的：LGPL。它常被用在库上，判断关键在于你是“动态链接、以库的形式调用”，还是“把库的代码改进了自己的源码里”。前者和后者义务差别很大，夜里没有把握时，最稳的动作不是猜，而是把依赖列出来，标上“待确认”，先不合并进要发布的分支。

这里说的“开源协议常识拆成三步”，第二步的核心不是背全文，而是把许可证归到三类里：宽松型、带专利与通知义务型、强 copyleft 型。归错类的代价远大于读得慢。

第三步：看你怎么用，用“分发”这个词做分界线

同一个许可证，内部用和对外发，结论可能不同。赶时间时，用“会不会分发出去”当分界线最省事。只在公司内网跑、不把二进制或源码交给外部，很多义务暂时不触发；一旦打包进 App、做成镜像对外提供、或者把源码贴到公开仓库，分发就发生了，声明保留、许可证附随、源码提供这些动作就要跟上。

具体到窗口场景：办事人员问你“这个软件用了什么开源组件、协议是否合规”，你手里如果只有一份依赖清单，没有协议归类，最实用的回答是先给出“已识别出的宽松型协议清单 + 待确认的 copyleft 清单”，并说明待确认项已隔离、不在本次提交范围内。这比含糊地说“都是开源的”要可核验得多。

再补一个夜里容易忽略的细节：有些项目是双许可，仓库里同时放两个 LICENSE 文件，或者 README 里写“可选用 A 或 B”。这种不要自己挑一个顺眼的，按项目声明的方式选，声明不清就记为待确认。还有的仓库根目录有 LICENSE，但某个子目录另有许可，整包拷用时子目录的协议同样生效，扫一眼子目录有没有单独的许可文件，能省掉后面返工。

做完这三步，留一张能交差的纸条

几分钟内你未必能给出最终法律结论，但可以留下一条可核验的记录：代码来源（仓库地址或同事移交）、根目录许可证文件名与名称、归类（宽松 / 专利与通知 / 强 copyleft / 待确认）、是否对外分发、待确认项清单。把这张纸条贴在发布单或提交说明里，第二天有人接手就能接着查，不用从头再来。

如果三步走完仍是“待确认”，正确的下一步是指向官方文本和项目自身的许可声明，必要时找法务或知识产权窗口确认，而不是在深夜凭印象拍板。赶时间的判断只负责把问题缩小到可处理的范围，不负责替你做最终决定。