最后一天了，最后麻烦大家投一票抱拳：https://www.csdn.net/blogstar2025/detail/099
团队用 Qt 写跨平台应用很爽，但临近交付才问许可证，往往来不及。核心结论其实就一句：
不是"用了 Qt 就开源"，而是"用了哪些模块 + 怎么链接 + 怎么交付"，决定会不会被 GPL/LGPL 影响。
一、先说清楚：Qt 不是一个许可证
Qt 很多模块是双重许可 ：商业许可 / 开源许可（二选一）。开源里最常见的是 LGPL ，也有一些模块是 GPL-only（只给 GPL 或商业许可，不给 LGPL）。
所以第一步永远是：列清单盘点模块（不盘点就无法判断）。
二、LGPL：大多数场景可以闭源，但要守规则
1）最推荐：动态链接（风险最低）
如果你用的是 LGPL 模块 ，并且动态链接（.dll/.so），你的业务代码通常可以闭源。常见合规动作包括：
- 随产品提供/保留：Qt 版权声明、许可证文本、第三方清单
- 不要用技术手段阻止用户替换/更新 Qt 动态库
- 如果你改了 Qt 的 LGPL 库：分发时通常要按 LGPL 方式提供改动对应源码/补丁
一句话：
动态链接 + 不改库 = 闭源合规最省事。
2）静态链接：不一定"整包开源"，但要让用户能"重链接"
LGPL 静态链接的麻烦点不是"你必须开源业务代码"，而是要保证：
用户改了 LGPL 库后，仍然能把你的程序重新组合运行。
工程上常见意味着：你可能要提供可重链接所需的目标文件/构建说明等交付物。
一句话：
静态链接会显著抬高交付成本与流程复杂度。
三、GPL：传染性强，闭源项目基本当"红灯"看
1）什么时候会"被传染"？
通常满足两件事就危险：
- 对外分发/交付（给客户、上架、拷贝给外部用户等）
- 软件与 GPL 模块发生合并/修改/链接（动态/静态链接通常都算高风险）
结果往往是：整体要按 GPL 做开源交付（对应源码等）。
2）哪些场景通常不触发？
- 企业内部自用（不对外发包）
- 仅服务器端使用 / SaaS 部署（不把可执行程序交给用户）
- 仅把 Qt Creator 当开发工具（工具许可证不等于你产物许可证，关键看你产物是否链接 GPL 库）
3）"进程隔离"能不能降风险？
把 GPL 模块做成独立进程，闭源主程序用 socket/gRPC/HTTP 通信，确实是常见的降风险架构。想更稳一点：
- 用标准协议（HTTP/gRPC/Protobuf 等）
- 避免共享内存/共享复杂内部数据结构
- 功能边界清晰，别做成"同一个程序拆两半"
但要记住：
进程隔离是降风险手段，不是自动免疫。
四、落地建议：闭源商业软件的"最优路线"
- 尽量只用 LGPL 模块
- 优先动态链接
- 尽量不改 Qt 库（必要改动做成可对外提供的补丁/分支）
- 产品随包准备这几样材料：
- 第三方许可证清单（NOTICE/THIRD-PARTY）
- Qt 许可证文本与版权声明
-（如涉及静态链接）可重链接所需材料与说明
-（如改过库）修改部分源码/补丁的提供方式说明
五、决策口诀（3 秒自查）
- 想闭源 ：优先 LGPL + 动态链接 + 不改库
- 碰到 GPL-only ：默认认为 一旦交付就高风险 → 换模块 / 买商业许可 / 接受开源 三选一
- LGPL 静态链接：重点不是开源，而是准备"可重链接"的交付义务