公司新项目上线前，法务突然叫停开发，原因是某个开源组件的许可证不合规。这种情况并不少见，很多团队在快速迭代时忽略了依赖许可证合规检查，结果埋下法律隐患。
什么是依赖许可证合规检查
现代软件开发离不开第三方库，比如前端用 React，后端调 Spring Boot，这些都属于“依赖”。每个开源项目都有自己的许可证，像 MIT、Apache 2.0 允许商用，而 GPL 则要求衍生作品也必须开源。依赖许可证合规检查，就是梳理项目中所有第三方组件的授权条款，确保使用方式不越界。
举个例子，你在做一个闭源商业系统，偷偷用了 AGPL 协议的数据库驱动，一旦被发现，对方有权要求你公开全部源码。这不是危言耸听，已有企业因此被起诉索赔。
怎么查？手动太累，工具来帮忙
靠人眼翻几百个 npm 或 Maven 依赖的 LICENSE 文件不现实。更靠谱的方式是引入自动化工具。比如在 Node.js 项目中，可以安装 license-checker：
npm install -g license-checker
license-checker --json > licenses.json执行后会生成一份清单，列出所有依赖及其许可证类型。再配合策略过滤，比如自动拦截 GPL、AGPL 等高风险协议。
Java 项目可以用 spotbugs 配合 license-maven-plugin，CI 流程中加入检测步骤，一旦发现不合规依赖，直接让构建失败。
常见陷阱：间接依赖更危险
很多人只检查自己 package.json 或 pom.xml 里写的库，却忘了这些库本身也有依赖。比如你引入了一个 MIT 许可的工具包，但它底层调了另一个 LGPL 的库，这个间接依赖同样受约束。
所以合规检查必须覆盖整个依赖树，不能只看表面。有些安全平台如 Snyk、FOSSA 能做深度扫描，还能关联漏洞数据库，一箭双雕。
企业该怎么做
大公司通常建立开源软件清单（OSS Inventory），规定哪些许可证允许使用，哪些需要审批。开发人员在引入新依赖前，系统自动校验是否在白名单内。类似银行转账前的身份核验，提前堵住漏洞。
小团队没资源搞复杂流程，至少要在发布前跑一次许可证扫描，把报告存档。万一将来有纠纷，能证明“我们查过”也能减轻责任。
开源不是免费午餐，用得好是加速器，用不好就是定时炸弹。花半天时间做一次依赖许可证合规检查，可能就省下了百万赔偿。”}