依赖许可证合规检查：别让开源库悄悄拖垮你的项目

上周，朋友老张的创业公司刚上线一款内部管理工具，结果上线第三天就被法务叫停——原因不是代码有 bug，而是用了某个 MIT 协议的 UI 组件，但没按要求在 About 页面里声明作者和许可证。更尴尬的是，他们还顺手把另一个 Apache-2.0 的日志库改了源码，却没保留原始版权声明。这事儿不稀奇，很多开发者写完功能就打包发布，压根没想过：你写的代码，可能一半都不是你自己‘原创’的。

依赖不是白用的，许可证是带条款的‘借条’

npm、Maven、pip 这些包管理器太方便了，敲两行命令就能拉来几十个现成模块。可每个依赖背后都绑着一份许可证——MIT、GPL、Apache-2.0、BSD，甚至还有 AGPL 这种‘传染性’极强的。它们不是摆设，是法律文件。比如 GPL 要求你分发修改版时必须公开全部源码；而 MIT 只要你保留原作者声明就行。漏掉一行声明、改了代码又不标注，轻则被发律师函，重则下架产品、赔款。

怎么查？别靠人眼翻 LICENSE.md

一个中型前端项目，node_modules 里动辄上千个依赖，手动一个个点开看 LICENSE 文件？不现实。实际做法是借助自动化工具：

比如用 license-checker 扫描 npm 项目：

npm install -g license-checker
license-checker --json --out licenses.json --exclude "MIT"

它会输出所有非 MIT 协议的依赖列表，一眼就能揪出那个用了 GPL 的图表库。Python 项目可用 pip-licenses：

pip install pip-licenses
pip-licenses --format=markdown --output=THIRD-PARTY-LICENSES.md

生成的文档能直接放进项目根目录，既是合规动作，也是给后续维护者留的线索。

CI 里加一道卡口，比事后补救强十倍

有些团队等法务提需求才去查，结果开发完才发现核心组件是 GPL，只能推倒重做。更稳妥的做法，是在 GitHub Actions 或 GitLab CI 里跑许可证检查脚本。比如在 PR 合并前自动拦截含禁用协议（如 AGPL）的依赖：

# .github/workflows/license.yml
- name: Check licenses
  run: npx license-checker --failOn "AGPL,GPL-3.0"

一次配置，以后每次提交都自动过筛。不是增加负担，是把风险挡在代码入库之前。

别只盯着‘大库’，小工具也可能踩雷

有人觉得：“我就用了一个 tiny-date-format，能出啥事？”结果一查，它依赖的底层正则库是 GPL-2.0。许可证会逐层传递，上游链路越长，隐藏风险越高。所以检查不能只看直接依赖（dependencies），devDependencies 和 peerDependencies 也得扫——比如某些测试工具自带 GPL 示例代码，打包进生产环境就容易被误引。

许可证合规不是法务部门的 KPI，是每个写代码的人该盯住的细节。它不酷，不出现在炫技的 Demo 里，但它决定了你的软件能不能安稳跑下去。