同事问“这库能不能商用”，我让他先别急着回答

“这库是同事 MIT 的，直接商用没问题吧？问库”午休时同事端着杯子站在我工位旁边，屏幕上是不能商某个依赖包的首页。我没接这句话，用让而是先别把页面往上翻了两屏，找到版本号和仓库地址，回答又点进仓库根目录看了 LICENSE 文件。同事同一个包名，问库不同大版本、不能商不同发布时间，用让甚至不同地区的先别镜像站页面，显示的回答信息都可能不一样。开源协议常识里最容易被忽略的同事一点就是：协议不是跟着“包名”走的，而是问库跟着具体版本、具体文件、不能商具体发布渠道走的。

先看版本号，再看协议名

很多人查协议的方式是搜“某某库 开源协议”，点开第一条结果就下结论。问题在于，搜索结果可能指向旧版本的文档站，或者指向一个已经换了维护者的分叉仓库。比较稳妥的做法是：在包管理器里确认当前安装的版本号，比如依赖清单里写的是哪个版本区间，实际锁文件里落到了哪个具体版本，然后到该版本对应的源码标签页去看 LICENSE 文件。

举个具体场景：某个前端工具库在 2.x 时期用的是较为宽松的协议，3.0 发布时调整了部分条款。如果你的项目锁在 2.x，讨论时拿 3.0 的协议页面来说事，结论就会偏。反过来，如果团队准备升级大版本，那升级前必须重新核对一次，而不是沿用两年前的判断。开源协议常识的第一步不是背协议名，而是养成“协议随版本变化”的意识。

核对动作可以固定成三步：第一，在锁文件或安装日志里找到确切版本；第二，在代码托管平台的标签或发布记录里切到该版本；第三，打开仓库根目录的 LICENSE、COPYING 或 LICENSE.md 文件，读原文而不是读二手解读。协议原文通常不长，宽松型协议往往一两屏就能看完。

镜像站和二手解读页，不能当最终依据

国内访问代码托管平台有时会走镜像或代理，包管理器也可能配置了企业内网源。这些渠道的页面缓存、字段截断、甚至协议字段的展示方式，都可能和上游不一致。我见过依赖安装时弹出的提示写着某种协议，但点进仓库原文发现表述更细，附带了一些附加条件。这时该信谁？信上游仓库对应版本的原文，镜像页只作为线索。

另一个常见来源是各类“协议对比表”和技术博客。这类内容适合建立初步印象，不适合作为合规判断的最终依据。原因很实际：对比表往往不标注更新日期，也不区分版本。你可以用它快速判断某个协议大致属于哪一类，但涉及商用、再分发、修改后是否必须公开源码这些具体问题时，还是要回到原文，必要时对照官方组织发布的协议全文页面。协议全文的官方页面也会修订，核对时留意页面上的版本说明和日期。

公司规模和使用场景，会改变结论

同一个协议，在不同组织里的处理方式可能不同。个人项目、小团队内部工具、对外交付的商业产品，面对的风险面不一样。有些公司有专门的开源合规审查流程，要求登记依赖清单、留存协议原文快照；有些团队则完全没有这条线。如果你所在的组织有法务或合规窗口，涉及对外分发、嵌入硬件、SaaS 交付这些场景时，把依赖清单和协议原文一起提交过去，比自己在群里问“能不能用”更稳妥。

人群差异还体现在角色上：写代码的人关心能不能引入，做发布的人关心分发时要带什么声明，做采购或商务的人关心合同里怎么写。同一份协议，这三类人需要核对的重点不同。比较实际的做法是，在引入一个新依赖时，顺手在项目文档里记一行：包名、版本、协议名、原文链接、核对日期。等半年后有人再问，不用重新考古。

把核对日期和原文链接一起留档

开源协议常识里最实用的一条，是承认信息会变。协议文本可能随版本调整，仓库可能迁移，文档站可能改版，镜像页可能滞后。所以每次核对完，别只记一个协议名，把版本号、原文链接和核对当天的时间一起写进依赖说明或内部台账。下次升级依赖时，先看台账里的日期，再决定要不要重新翻原文。

如果核对过程中发现镜像页和上游原文对不上，处理顺序是：以锁文件里的版本为准，去上游仓库对应标签页确认原文，把差异记录下来，再判断是否需要找合规窗口确认。拿不准的时候，不要用“应该没事”来收尾，把问题停在“待确认”状态，比给出一个错误结论要好。同事那个问题，我最后回的是：先把版本号发我，我看完原文再说。