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

上周同事小李上线一个内部工具，结果刚跑两天就被法务叫停——原来他顺手引入的某个 npm 包，底层依赖了 GPL-3.0 许可的库，而公司政策明确禁止在闭源产品中使用 GPL 类许可代码。这不是个例，很多开发者日常写代码时，只关心功能好不好用、文档齐不齐全，却忽略了 依赖许可证合规检查 这一关键环节。

许可证不是摆设，是法律条款

你装的不只是代码，还可能是一纸协议。比如：MIT 允许商用、修改、再分发，几乎没限制；Apache-2.0 要求保留版权声明和 NOTICE 文件；而 GPL-3.0 一旦链接使用，整个项目都得开源。这些不是技术门槛，是法律红线。

三步快速做一次基础检查

第一步：查当前项目的直接依赖许可证
以 Node.js 项目为例，运行：

npm ls --prod --depth=0 --parseable | xargs -I {} sh -c 'echo "{}: $(cat {}/package.json 2>/dev/null | grep \"license\" | head -1)"'

第二步：挖出深层依赖的许可证
别只看第一层。用 license-checker 工具扫全量：

npm install -g license-checker
license-checker --json --onlyAllow "MIT,Apache-2.0,BSD-3-Clause"

如果报错提示某依赖含 GPL-2.0，就得立刻排查它是否被实际调用，能不能换掉。

Python 和 Java 也一样不能松懈

Python 用户可以用 pip-licenses：

pip install pip-licenses
pip-licenses --format=markdown --output=third-party-licenses.md

Maven 项目则可在 pom.xml 中加 license-maven-plugin，构建时自动校验并生成报告。

有次我们改一个老 Java 后台服务，发现用了十几年的 log4j 1.x（已停止维护），其依赖的 oro 库许可证是 Apache-1.1，虽不算高危，但公司安全规范要求所有组件必须满足 Apache-2.0 或以上，最后还是替换成 commons-text 才过审。

自动化才是日常习惯

把许可证检查塞进 CI 流程最靠谱。GitHub Actions 示例片段：

name: License Compliance
on: [pull_request]
jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install license-checker
        run: npm install -g license-checker
      - name: Verify allowed licenses
        run: license-checker --onlyAllow "MIT,Apache-2.0,BSD-3-Clause" --failOnLicense "GPL-2.0,GPL-3.0"

每次提 PR 自动跑一遍，不合规矩的依赖根本合不了并。

许可证合规不是给程序员加活，而是帮团队避坑。多花五分钟查清一个依赖的许可证，可能省下后续几周的法务沟通、代码重构甚至产品下线风险。