公司新项目刚上线，团队用了一堆开源库，结果法务突然发来邮件：某个依赖的许可证不合规，得立刻整改。这种情况在中小公司并不少见，很多开发者觉得“代码能跑就行”，却忽略了背后藏着的法律风险。
不是所有开源都能随便用
开源不等于免费商用。比如你用了 MIT 许可的工具，基本没啥限制，只要保留原作者声明就行。但要是碰上 GPL 协议的项目，情况就复杂了——一旦你的软件链接了 GPL 代码，整个项目都可能要跟着开源，这对闭源商业产品来说几乎是红线。
曾经有家做监控设备的公司，在固件里用了 GPL 的网络组件，结果被竞争对手举报，最后被迫公开部分源码，连带硬件设计也被反向分析，吃了大亏。
常见许可证类型扫盲
MIT 和 Apache 2.0 属于宽松型，适合大多数商业项目。BSD 类似 MIT，但要求不能用作者名字做推广。而 LGPL 相对友好，允许动态链接而不强制开源主程序，常用于类库开发。
最需要警惕的是 AGPL。它比 GPL 更狠，就算你只是通过网络提供服务（比如 SaaS），也得公开源码。如果你在后台用了 AGPL 的数据库或中间件，就得掂量清楚。
自动化工具帮你盯住风险
手动查每个依赖的许可证太费劲。可以用 license-checker 这类工具扫描项目：
npm install -g license-checker
license-checker --json > licenses.json输出的结果会列出所有依赖及其许可证类型，方便快速筛查出 GPL、AGPL 等高风险项。集成到 CI 流程里，每次提交自动检查，能提前拦截问题。
别忽视传递性依赖
你以为只引入了一个 Apache 2.0 的包，但它内部又依赖了个 MIT 的子模块，子模块再套了个 GPL 的底层库……这种嵌套关系很容易漏看。用 npm ls 或 mvn dependency:tree 查依赖树，确保每一层都在合规范围内。
某创业团队曾因一个测试工具的传递依赖含 GPL，差点导致产品无法发布。后来他们定下规矩：上线前必须跑一遍许可证扫描，写进发布 checklist。
建立自己的开源使用规范
技术团队可以和法务一起定个白名单，明确哪些许可证可用、哪些需审批、哪些直接禁止。新人入职时给份简明指南，避免随手 npm install 埋雷。
有些公司还设了“开源管理员”角色，负责审核外部代码引入。哪怕只是复制一段 GitHub 上的示例代码，也要确认其 LICENSE 文件是否存在，避免片段式侵权。
开源是把双刃剑，用好了加速开发，用不好反被割伤。花点时间了解规则，比事后救火划算得多。