临下班被问开源协议能不能商用，先做这几步

周五下午五点四十，临下同事把一份依赖清单甩过来，班被不能步问下周能不能直接交付给客户。问开清单里几十个包，源协议许可证一栏写着 MIT、商用Apache-2.0、临下BSD、班被不能步LGPL，问开还有两个没标。源协议窗口快关了，商用来不及逐个读全文，临下但也不是班被不能步只能回一句“我周一再看”。下面这几步，问开今天下班前能做完，源协议做完至少能给出一个有依据的商用初步判断。

先把“没标许可证”的包单独拉一张表

不要一上来就读长篇法律文本。第一步是打开项目根目录，找 LICENSE、LICENSE.txt、COPYING 这类文件，再看每个包的 package.json、pom.xml、setup.py 或 METADATA 里的 license 字段。把结果分成三列：明确写了许可证的、写了但写法含糊的（比如只写“BSD”不写版本）、完全没写的。

完全没写的那几个最要紧。按通行的著作权规则，没有许可证授权，默认保留所有权利，哪怕代码公开在仓库里，也不等于允许你复制、修改、再分发。这时候别猜，先去该项目的仓库首页和发布页核对，再看它依赖的上游有没有说明。如果仍然找不到，今天的结论就写“来源不明，暂不引入”，这比硬着头皮用要稳。

顺手做一件事：把每个包的版本号一起记下来。同一项目不同版本换许可证的情况确实存在，只写包名不写版本，后面复查会白做一遍。这张表不用做得多漂亮，三列加一列版本号，够用。

把 MIT、Apache-2.0、BSD 三类先分清楚

这三类通常被归为宽松型，但细节不一样，交付前值得花十分钟分清。

MIT 最短，核心是保留版权声明和许可声明。你要做的动作很具体：在分发的产物里，把原项目的 LICENSE 文本和版权行带上。很多打包工具默认不会自动塞进去，需要手动在“第三方声明”文件里补一段。

BSD 有 2 条款、3 条款、4 条款之分，差别主要在“不得用作者名义背书”和“广告条款”。看到只写 BSD 的，必须回去确认到底是哪一版，不能默认当 3 条款处理。这是开源协议常识里最容易被忽略的细节之一：简称不等于全称，版本号决定义务范围。

Apache-2.0 比前两者多出两件事。一是明确的专利授权条款，二是要求你标注修改过的文件。也就是说，如果你改了某个 Apache-2.0 的源码再分发，得在文件里说明“已修改”。另外它带一个 NOTICE 文件机制，原项目有 NOTICE 的，分发时要一并保留。今天能做的动作是：在依赖表里加一列“是否有 NOTICE”，有的话把文件复制到你的第三方声明目录。

LGPL 和 GPL 别只记“传染”两个字

很多人一听 GPL 就紧张，一听 LGPL 就放松，这两个反应都不够准确。判断的关键不是许可证名字，而是你怎么用它。

如果只是在自己的服务端进程里调用某个 GPL 库，没有把程序分发给客户，通常不触发分发义务；但一旦把包含它的软件交给客户安装，情况就变了。反过来，LGPL 允许你在一定条件下动态链接使用，同时要求用户能替换那个库的版本。落到具体动作上：检查你是静态链接还是动态链接，产物里那个库是不是独立文件、能不能被替换。如果是静态链接进一个单体可执行文件，这条路径就要重新评估。

这里必须说清边界：具体到你的产品形态、分发方式、是否修改源码，结论可能不同。涉及商业交付和闭源安排，别只靠同事之间互相确认，找法务或有开源合规经验的律师过一遍，成本远低于事后返工。

下班前写一段三行结论，附上核对表

做完上面几步，别只口头回一句“应该没问题”。写一段能存档的结论：一是本次交付的依赖里，哪些是宽松型、义务是保留声明；二是哪些需要进一步确认版本或来源，暂时不引入；三是哪些需要法务复核，列出包名和版本。

再留一张核对表放在项目里，下次直接复用：许可证全称和版本是否写明；版权行和许可文本是否随产物分发；Apache-2.0 的 NOTICE 是否保留、修改文件是否标注；LGPL 的链接方式和可替换性是否确认；来源不明的包是否已排除。每次发版前扫一遍，比临时翻仓库快得多。

最后提醒一句：开源协议常识不是背几个缩写，而是把“谁授权、授权到什么程度、我分发时要不要带上什么”这三件事落实到文件和版本上。今天能把这张表建起来，下次窗口再叫号，你翻开就能答。