别人说“开源随便用”时，先别急着信

上个月一个做电商的别人便用别急朋友踩了坑。他在外包群里听人说“这组件是说开时先开源的，随便用”，源随就把一套带界面的着信管理后台直接打包进了客户项目。结果交付前对方技术负责人问了一句：LICENSE 文件在哪、别人便用别急二次分发有没有保留版权声明？说开时先他翻遍压缩包只找到个 README，里面写着“MIT”。源随再细看，着信那个仓库其实把另一个 GPL 项目的别人便用别急代码整个拷了进来，只是说开时先外层套了个 MIT。最后只能连夜替换模块。源随问题不在他不懂技术，着信而在他把“别人说开源”当成了结论，别人便用别急跳过了自己核对的说开时先那几步。

正确的源随顺序不是先查协议条文，而是先排除几种最容易被带偏的情况，再逐层往下走。每一路走不通，就换下一路，不要停在原地猜。

第一步：先确认“这一份”到底从哪来

很多争论其实是对象搞错了。别人说“这个库是开源的”，你要先问：说的是哪个仓库、哪个版本、哪次提交？同一个项目名，GitHub 上一个主仓、npm 上一个包、公司内网 fork 出来的分支，可能对应三份不同的授权状态。

具体动作：打开你实际引入的那份代码或安装包，找到根目录的 LICENSE、COPYING、NOTICE 文件，以及包管理描述文件里的 license 字段。三处对不上，就以仓库根目录的 LICENSE 原文为准，其余只能当线索。如果连 LICENSE 都没有，先别往下讨论“能不能商用”，这一路直接判为不明，去找上游要说明。

排除掉“道听途说”和“版本错位”之后，再谈协议类型，才有意义。这一步也是独立判断开源协议常识的起点：先锁定对象，再谈规则。

第二步：看它是单一协议还是拼装货

第一路走通了，拿到明确的 MIT 或 Apache-2.0，也别急着下结论。真正的分叉点在依赖树。

做法很实在：在项目目录里跑一次依赖清单，把直接依赖和传递依赖都列出来，逐个看许可证标识。重点盯两类：一是 GPL、AGPL 这类带传染性的协议，二是标注为 UNKNOWN、SEE LICENSE IN 或者自定义条款的包。前者会影响你分发时的义务，后者等于没告诉你规则。

如果依赖太多看不过来，先按“会被打包进最终产物”和“只在构建时用”分开。前者风险高，后者通常宽松些，但也不是绝对。分不清的时候，把那个包的仓库地址和版本号记下来，去它的发布页核对，不要凭包名猜。

第三步：把“使用方式”代进去再判断

协议条文是死的，你的用法是活的。同一份 AGPL 代码，放在内部系统不对外提供网络服务，和做成 SaaS 对外卖，义务完全不同。所以第三步不是背协议，而是写清自己的场景：是内部自用、随产品分发、还是作为网络服务提供？有没有修改源码？会不会再许可给别人？

把这几个问题的答案写在一张纸上，再回去对照 LICENSE 里关于分发、修改、网络使用的段落。看不懂原文就找官方 FAQ 或项目自己的授权说明，注意以项目官方渠道为准，论坛回答只能参考。拿不准的边界，比如“动态链接算不算衍生作品”，这类问题没有统一答案，该问法务就问法务，别自己拍板。

如果三步都走完仍有疑点，处理方式不是硬上，而是换方案：找授权更清晰的替代库，或者直接联系版权方要书面许可。留下邮件和回复，比群里一句“应该没事”可靠得多。别人推开源协议常识时，你能独立判断的标志，不是记住多少协议名，而是知道每一步该看哪个文件、卡住时往哪退。