路由器固件升级前，别忘了做依赖许可证合规检查

老张给公司新换的OpenWrt路由器刷完第三方固件，第二天就收到一封邮件，说他部署的某个网络监控插件违反了GPL协议——不是功能出问题，而是打包时漏掉了源码声明和许可证文件。这事听起来离谱，但真不少见。

什么叫依赖许可证合规检查？

简单说，就是你在路由器上装的每一个软件包（比如dnsmasq、curl、openssl，甚至一个小小的luci-app-adguardhome），背后都可能绑着特定开源许可证（MIT、Apache-2.0、GPL-2.0等）。这些许可证不是摆设：GPL要求你分发修改版固件时，必须同步提供对应源码；MIT则只用保留原作者版权声明。一旦忽略，轻则被社区提醒，重则面临法律风险或固件被下架。

路由调优里，它藏在哪？

很多人调优只盯着QoS、DNS缓存、MTU值，却没注意构建固件镜像时，buildroot或ImageBuilder自动拉进来的依赖库。比如你加了个支持TLS 1.3的curl包，它底层可能依赖gnutls或mbedtls——而这两个库的许可证条款完全不同。OpenWrt官方源默认做了基础合规处理，但一旦你手动添加非官方feed、patch代码、或交叉编译私有模块，合规责任就落到你自己肩上。

一个真实操作片段

用 make menuconfig 选中 Network → File Transfer → curl 后，执行：

make package/curl/compile V=s

再运行：

./scripts/feeds list -d | grep curl

就能看到它显式依赖的组件及对应许可证类型。关键要看输出里有没有 GPL-2.0-only 或 GPL-3.0-or-later 这类强传染性条款。

怎么快速过一遍？

在OpenWrt SDK目录下，跑这条命令：

make package/index | grep -E '(License|LicenseFiles)'

它会列出所有已编译包的许可证声明路径。如果某包显示 LicenseFiles: NONE，就得立刻查它的Makefile里是否漏写了 LICENSE:= 和 LICENSE_FILES:= 字段。

另外，别迷信“别人编译好的固件”。上周有用户反馈，某热门AdGuard Home固件镜像里，adguardhome二进制文件未附带其依赖的libcap源码链接——而libcap是GPL-2.0 licensed，这就踩线了。

合规不是给开发添堵，是让调优成果能稳稳落地。下次刷机前，花两分钟翻翻 staging_dir/target-*/pkginfo/ 下的 .mk 文件，看看你用的每个模块，到底签的是哪份“电子契约”。