// 维基 · 指南 · 2026 年 9 月
公司产品中的 open source
文章草稿。许可描述是简化的工作参考；具体许可的文本及其适用性始终是第一位的。
供讨论的草稿。本文回答“发布产品前应检查什么”，但不能替代对具体构建的审计：依赖的构成比主许可的选择更重要。
简短回答
在商业产品中使用开源代码几乎总是可以的——问题在于条件。宽松许可（MIT、BSD、Apache）只要求保留署名声明。Copyleft 许可（GPL、AGPL）要求开放衍生代码的源码——在专有产品中，这通常是企业不愿支付的代价。风险管理不是禁止 open source，而是组件清单加两条给开发者的规则。
许可地图
| 许可 | 可否进入专有产品 | 开放代码的义务 | 记住 |
|---|---|---|---|
| MIT, BSD | 可以 | 没有 | 保留许可副本和作者声明 |
| Apache-2.0 | 可以 | 没有 | 作者的专利授权；NOTICE 文件；变更清单 |
| MPL-2.0 | 可以，但须隔离 | 仅 MPL 下的修改文件 | 文件级 copyleft：模块边界务必保持干净 |
| LGPL-2.1 / 3 | 可以，但须动态链接 | 对库本身的修改 | 静态链接和修改库会削弱法律地位 |
| GPL-2 / 3 | 几乎不行 | 分发时的全部衍生代码 | “衍生作品”是关键且有争议的术语 |
| AGPL-3.0 | 没有 | 即使不分发——网络访问即触发 | 见下文：SaaS 的主要风险 |
单独的一类是“源码可得”（source-available：SSPL、BSL 及厂商自有许可）：代码可见，但不是 open source——商业使用条款必须完整阅读。
AGPL：SaaS 的陷阱
GPL 在 分发 时才要求开放代码——云服务不向任何人交付二进制文件，因此 SaaS 长期绕开 GPL。AGPL 堵住了这个漏洞：如果用户通过网络使用程序，运营者必须向其提供衍生版本的源码。一个进入服务端代码的 AGPL 包，理论上就把开放该代码的义务一并带入。团队规则：运行时出现 AGPL 一律升级评审——不允许“但它很小”。
典型错误
- 复制粘贴片段 ——Stack Overflow 和博客上的代码通常采用 CC BY-SA——其相同方式共享条件与专有产品不兼容。
- 传递性依赖： 您的 MIT 包引入了 GPL 包——许可地图要按整个依赖树收集，而非只看直接依赖。
- SDK 与客户端： 封装 AGPL 服务的包装器或带 copyleft 条款的 SDK，会像代码本身一样“感染”产品。
- “没有许可”=“什么都可以”。 恰恰相反：没有许可文件的代码默认受保护——在作者明确许可之前不能使用。
组件清单
工作纪律是维护第三方代码清单（SBOM）：组件、版本、许可、使用位置。它由成分扫描器自动生成；法务只需控制触发点：树中出现新的 GPL/AGPL、许可冲突、无许可组件。对监管敏感的产品，该清单还是证据基础的一部分——类似文章中的数据来源日志： 《在他人作品上训练模型》.
交易中的 open source
在融资轮和并购中，open source 清单是标准的尽职调查事项：投资方检查产品是否被拉低资产价值的 copyleft“拖累”（详见 《AI资产尽职调查》）。如果没有清单，就得在交易前抢建——更贵且总有问题。更便宜的是给团队三条政策：宽松许可——可用；MPL/LGPL——经评审；GPL/AGPL——须批准。
产品许可审计与 open source 政策是以下业务的一部分： 技术权利业务.