开源协议对闭源软件有什么风险？
简答
风险有三类：传染性（GPL 类许可证要求衍生作品同样开源，你的闭源代码可能被迫公开）、弱保护型义务（MIT/Apache 要求保留版权声明与许可文本，漏了即违约）、专利条款（Apache 2.0 附带专利授权，GPLv3 含专利报复条款）。最大雷区是把 GPL 组件链接进闭源商业产品——历史上多起判例支持许可证的可执行性。
展开说明
许可证光谱
宽松型（MIT、BSD、Apache 2.0）：可闭源商用，义务是保留版权与许可声明（Apache 另含 NOTICE 文件与专利授权条款）。弱传染型（LGPL、MPL）：按文件/库边界隔离，动态链接 LGPL 库通常可保留闭源，但修改库本身须开源。
强传染型（GPLv2/v3、AGPL）：分发基于 GPL 的衍生作品必须整体以 GPL 开源——静态/动态链接的边界在社区与司法实践中趋于从严；AGPL 连「网络使用即分发」都覆盖，SaaS 场景同样触发。
闭源产品的三条纪律
一是入库审查：引入任何第三方组件（包括 npm/pip 传递依赖）先查许可证与版本，建立 SBOM（软件物料清单）；二是边界隔离：强传染组件只允许通过进程隔离、命令行调用等「分离作品」方式使用，链接进主程序即触发传染争议；三是义务留存：版权声明、许可证文本、修改记录按要求随产品分发。
忽略这些义务的后果不只是道德问题：许可证违约可构成侵权，法院可判停止侵害——对商业产品意味着下架重写。
专利维度的开源条款
Apache 2.0 第 3 条：贡献者就其贡献授予使用者专利许可——用 Apache 组件反而降低专利风险。GPLv3 含专利保护条款：发起专利诉讼指控 GPL 作品侵权者，许可自动终止。自研代码开源时的专利考量：开源即公开，专利申请必须在开源前完成，否则自己毁掉新颖性。
反向风险也要防：把公司代码误提交到开源仓库（或用开源代码污染自有代码库）会造成权属混乱与传染隐患，代码入库扫描应常态化。
「借力开源」的正确姿势
开源不只有风险：以宽松许可证开源非核心组件可以建立技术影响力、吸引贡献者、摊薄维护成本；核心增值部分闭源。最高法 2026 年涉人工智能纠纷意见 也提到开源生态的促进导向。关键是分层：开源层选 MIT/Apache 并保持代码洁净（无闭源代码混入），闭源层与开源层用明确接口隔离。
参考来源
引用均为官方文件或公开报道，访问日期 2026-11-06。