// 维基 · 指南 · 2026 年 9 月

公司产品中的 open source

文章草稿。许可描述是简化的工作参考；具体许可的文本及其适用性始终是第一位的。

简短回答

宽松许可证通常允许在遵守具体许可条件的前提下，将代码纳入闭源产品。Apache 2.0的条件包括保留许可证及必要通知、标明修改，以及遵守NOTICE要求。GPL和AGPL义务取决于产品组成、修改情况及程序提供方式；组件清单有助于确定核查范围。

许可地图

单独的一类是“源码可得”（source-available：SSPL、BSL 及厂商自有许可）：代码可见，但不是 open source——商业使用条款必须完整阅读。

AGPL：SaaS 的陷阱

修改后的AGPL程序若通过网络与用户交互，第13条要求向这些用户提供修改版本的对应源代码。义务范围取决于组件组成及组合方式。存在AGPL组件时，应核查具体许可和产品架构，不能自动认定必须公开整个服务的源代码。

典型错误

• 复制粘贴片段 ——Stack Overflow 和博客上的代码通常采用 CC BY-SA——其相同方式共享条件与专有产品不兼容。
• 传递性依赖： 您的 MIT 包引入了 GPL 包——许可地图要按整个依赖树收集，而非只看直接依赖。
• 对于API客户端和SDK，应核查组件本身的许可及其与产品的结合方式；通过API访问AGPL服务，本身不能决定整个产品的许可制度。
• “没有许可”=“什么都可以”。 恰恰相反：没有许可文件的代码默认受保护——在作者明确许可之前不能使用。

组件清单

工作纪律是维护第三方代码清单（SBOM）：组件、版本、许可、使用位置。它由成分扫描器自动生成；法务只需控制触发点：树中出现新的 GPL/AGPL、许可冲突、无许可组件。对监管敏感的产品，该清单还是证据基础的一部分——类似文章中的数据来源日志： 《在他人作品上训练模型》.

交易中的 open source

在融资轮和并购中，open source 清单是标准的尽职调查事项：投资方检查产品是否被拉低资产价值的 copyleft“拖累”（详见 《AI资产尽职调查》）。如果没有清单，就得在交易前抢建——更贵且总有问题。更便宜的是给团队三条政策：宽松许可——可用；MPL/LGPL——经评审；GPL/AGPL——须批准。

产品许可审计与 open source 政策是以下业务的一部分： 技术权利业务.