4、许可证合规性检查：为什么关注开源许可证？如何扫描依赖的许可证

说实话，许可证合规性检查，是很多团队最容易忽视的一环。

我见过不少项目，代码写得漂漂亮亮，功能也跑得稳稳当当，结果发布前被法务叫停——因为某个依赖的许可证跟商业协议冲突了。嗯，那场面，挺尴尬的。

为什么非要关注开源许可证？

你想想看，SDK 里用了开源组件，就等于你借了别人的轮子。借轮子没问题，但得遵守人家的规矩。不同的开源许可证，规矩完全不一样。

我个人习惯把许可证分成三类：

• 宽松型（MIT、Apache 2.0、BSD）：基本随便用，保留版权声明就行。我大部分项目都优先选这类。
• 弱传染型（LGPL、MPL）：如果你只是动态链接，问题不大。但静态链接或修改了源码，就得开源。我在项目中遇到过，有人把 LGPL 的库静态编译进 SDK，结果法务要求公开整个 SDK 源码……
• 强传染型（GPL、AGPL）：用了就得开源整个项目。商业 SDK 基本碰都不能碰。我曾经有个客户，不小心引了个 GPL 的日志库，最后花了三天重写日志模块。

怎么扫描依赖的许可证？

手动翻每个依赖的 LICENSE 文件？别傻了，一个中型项目几百个依赖，翻到天亮也翻不完。

我推荐用自动化工具。这里说两个我常用的：FOSSA 和 Snyk。

1. 用 FOSSA 做全量扫描

FOSSA 这东西，说白了就是个许可证合规的「扫描仪」。它能自动分析你的依赖树，把每个组件的许可证、版本、风险等级列得清清楚楚。

我一般这么用：

# 安装 FOSSA CLI
curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install.sh | bash

# 在项目根目录初始化
fossa init

# 执行扫描
fossa analyze

# 查看结果（会生成一个网页报告）
fossa test

跑完之后，FOSSA 会给你一个类似这样的报告：

依赖名称	版本	许可证	风险等级	建议
lodash	4.17.21	MIT	低	无
ffmpeg	4.4.0	LGPL	中	确认链接方式
gpl-lib	1.0.0	GPL	高	立即替换

2. 用 Snyk 做持续监控

Snyk 不只是扫许可证，它还能扫漏洞。但我个人更看重它的「持续监控」能力——项目代码变了，它自动重新扫描。

基本用法：

# 安装 Snyk CLI
npm install -g snyk

# 认证（需要先注册账号）
snyk auth

# 扫描项目
snyk test

# 只看许可证信息
snyk test --json | jq '.licenses'

Snyk 的输出里，会明确标出每个依赖的许可证类型，以及是否跟你的策略冲突。比如：

✔ Tested 147 dependencies for known issues
✔ Found 3 license issues

License Issues:
  ✗ GPL-3.0 (high) in gpl-lib@1.0.0
    - 这个许可证与公司策略冲突，建议替换为 MIT 或 Apache 2.0 替代品

避坑指南

我曾经踩过一个坑，说出来你可能不信——一个看似 MIT 的依赖，它的某个子依赖居然是 GPL 的。这就是所谓的「传递性许可证风险」。

所以，扫描的时候千万别只看顶层依赖。一定要做递归扫描，把整个依赖树翻个底朝天。

另外，有几个点我建议你记一下：

• 别信「网上说」：每个许可证的具体条款可能有版本差异。比如 Apache 2.0 和 Apache 1.1 差别就很大。以官方 LICENSE 文件为准。
• 保留扫描记录：每次发布前，把扫描报告存档。万一以后有人问「这个版本用了什么许可证」，你能直接甩证据。
• 建立许可证白名单：我习惯在项目里维护一个 LICENSE_ALLOWLIST.md，明确列出允许的许可证列表。新依赖进来，先过白名单。

知识体系总览

下面这张图，是我自己总结的许可证合规检查流程。你可以把它贴在墙上，或者放进团队的 Wiki 里。

嗯，流程其实不复杂。关键是要养成习惯——每次加新依赖，先扫一遍。别等到发布前才手忙脚乱。