在做智能家居项目时，很多人会直接从 GitHub 上找现成的固件代码，比如用 Arduino 或 ESP32 实现温控开关。代码拿来一烧，设备跑起来了，挺省事。但你有没有想过，这段代码用的是 MIT 许可证还是 GPL？如果没注意，产品一旦量产上市，可能就踩了开源许可证的雷。
GPL 代码用进固件，等于要公开你的全部源码
有个朋友做了一款基于 Linux 的工业控制器，底层用了大量开源组件。他把内核模块一通修改，性能调得不错，样机也交付客户试用了。结果某天收到律师函——他们用的驱动代码是 GPLv2 协议，修改后分发却没公开源码，构成违约。GPL 要求只要你的软件和开源代码动态或静态链接，整个作品就得按同样协议开放源代码。对硬件厂商来说，这意味着核心算法可能被迫曝光。
MIT 和 BSD 相对宽松，但也不是无条件可用
MIT 许可证看起来简单：保留原版权说明就能用。但实际操作中常被忽略细节。比如你在 STM32 项目里引用了一个 MIT 授权的 HAL 封装库，那最终发布的固件文档或系统信息里，就得明确列出这个库的作者和许可声明。有些厂商只在代码注释里留了作者名，设备界面和用户手册都没体现，严格来说也算不合规。
硬件里的“分发”不只是卖设备
很多人觉得，我只是把代码刷进设备，没有单独发布软件，就不算“分发”。但法律上，只要你把含开源代码的设备交给第三方使用，比如客户、合作伙伴甚至外包测试团队，都可能被视为分发行为。曾有一家做共享充电宝的公司，内部测试阶段就把带 GPL 代码的固件发给外包团队，对方没签保密协议，这就构成了非授权传播。
如何在开发流程中规避风险
建议在硬件研发早期就建立开源组件清单。每次引入第三方代码，记录来源、版本、许可证类型。可以用 SPDX 格式做标记，例如：
File: src/wifi_driver.c
License-Identifier: GPL-2.0
Copyright: (c) 2020 OpenLink Team
对于构建系统，可以集成 FOSSA 或 Scancode Toolkit 自动扫描依赖项。发现用了 AGPL 的网络服务库，就得警惕——它要求通过网络交互的用户也能获取源码，哪怕你不分发二进制。
商业产品中混用许可证的常见陷阱
别以为换个名字就能绕过限制。有家公司把 Linux 内核模块改名为“SmartCore Engine”，以为不提 Linux 就没人发现。结果人家反编译一眼看出 kernel version 字符串，证据确凿。更聪明的做法是选型时优先考虑许可证兼容的组件，比如用 LGPL 的库代替 GPL 的，这样动态链接时不需要开源自己的代码。
做硬件越来越离不开开源软件，从 U-Boot 到 Zephyr OS，处处都是别人写的轮子。用起来方便，但合规这根弦得一直绷着。一个小疏忽，轻则下架产品，重则赔款停业。别让开源帮你省了开发时间，却在法务上栽了大跟头。