开源问题在融资尽调里很少被单列成一节，却几乎每次都会出现。原因不难理解：代码里用了什么，决定了公司的核心资产能不能自由处置；而这件事在财务报表上看不出来，只有做过审计才答得上。
多数企业第一次被问到时，拿出的是一份依赖清单。清单能说明"用了什么"，说明不了"能不能商用、义务履行了没有、出事谁承担"。投资人要的是后三个结论。
一、三个时点会有人来要这份材料
融资。 投资人律师在技术尽调环节发出问卷，问题通常只有六行，但要求附证据。回答含糊，会直接进入交割条件或估值调整。
并购。 买方按交割后责任倒推，关注的是历史遗留：哪些组件不能随产品一起卖，哪些义务在交割后仍需履行。
出海或收到主张。 产品进入海外市场，或收到许可证权利人、开源项目基金会的函件，此时审计不再是预防性的，而是应对性的，时间窗口很短。
三个时点的共同点：材料必须在短时间内拿得出，且能被第三方复核。
二、尽调问卷里的六个高频问题
| 问题 | 企业常见回答 | 合格证据 |
|---|---|---|
| 用了哪些开源组件 | 一份 package.json 或依赖树 | 含传递依赖的 SBOM，标注版本与引入路径 |
| 分别是什么许可证 | “都是 MIT 和 Apache” | 许可证清单，按组件逐一对应，含双许可与例外条款 |
| 有没有传染性许可证 | “没有 GPL” | 按分发形态判断的结论，区分内部使用与对外分发 |
| 商用有没有限制 | “开源都能商用” | 逐条列出限制，如 SSPL、 Commons Clause、非商业许可 |
| 义务履行了吗 | “加了 LICENSE 文件” | 版权声明、许可证全文、修改声明、源代码提供方式的具体记录 |
| 出问题谁承担 | “应该是社区” | 免责范围、赔偿上限、以及企业自身的替代与隔离方案 |
六个问题里，第三与第四个最难答。前四个问的是事实，后两个问的是判断。判断需要结合分发形态、修改方式与商业模式，不是查表能得出的。
三、合格交付物的五个部分
审计报告的价值不在篇幅，而在能否被投资人的律师直接引用。合格的交付物通常包含五部分。
| 部分 | 内容 | 用途 |
|---|---|---|
| 组件清单 | SBOM，含直接与传递依赖、版本、引入路径 | 回答"用了什么" |
| 许可证矩阵 | 组件、许可证、义务、履行状态四列 | 回答"要做什么" |
| 风险分级 | 红黄绿三级，附判断理由 | 回答"最坏情况" |
| 整改方案 | 替代组件、隔离方式、补履行步骤与工期 | 回答"怎么补" |
| 审计意见 | 结论、限制条件、复核触发点 | 回答"能不能签" |
第五部分最容易被省略，也最影响交易。投资人需要的不只是问题清单，而是一句可以写进尽调报告的话：在何种假设下，这些组件可以随产品商用。
四、风险分级怎么分
分级不是按许可证名字排，而是按"分发形态 + 义务是否履行"排。
| 等级 | 典型情形 | 处理方式 |
|---|---|---|
| 红 | AGPL、SSPL 或许可证禁止商用，且产品对外分发；无许可证代码；来源不明 | 替换、隔离为独立进程并评估，或在交易文件中单列 |
| 黄 | GPL/LGPL 用于对外分发；MIT/Apache 但版权声明或 NOTICE 缺失；双许可未选择 | 补履行、限期整改、交割前完成 |
| 绿 | 宽松许可证且义务已履行；仅内部使用不对外分发 | 记录即可 |
需要提醒的是，同一组件在不同分发形态下等级不同。内部使用的 GPL 组件通常不触发源代码提供义务，一旦产品改为私有化交付或 SDK 分发，结论就要重做。分级必须写明假设，否则半年后就不适用。
五、哪些自己做，哪些必须外部做
企业内部通常能完成 SBOM 生成与依赖梳理，这部分用工具即可，成本低。难以自办的是三类判断：传染性许可证与分发形态的边界、商用限制条款的识别、以及替代方案的技术可行性评估。
外部审计的介入点通常在这三处，而不是从头做一遍扫描。企业已有工具产出的清单，可以直接作为审计输入，费用与周期都会下降。
六、费用与周期由什么决定
审计报价通常按四个变量浮动：组件数量与依赖深度、是否包含模型权重与训练数据、分发形态（SaaS、私有化、SDK、硬件预装）、以及是否需要出具可用于交易的正式意见。
典型项目在两到四周。若涉及模型权重的许可证链（基座模型、微调产物、推理框架），周期会延长，因为需要逐层核对授权文件，而不只是扫描代码。
七、不做的代价
代价通常以三种形式出现，且都发生在交易或争议阶段。
交易延期。 尽调发现问题，买方要求整改后再交割，时间成本由卖方承担。
估值折让或专项赔偿。 传染性许可证涉及核心代码时，买方会要求降价或设置托管账户。
下游索赔。 产品交付给客户后，客户收到许可证主张，责任沿合同链条回到企业。此时整改空间远小于交易前。
审计费用与上述三项相比通常不高，这也是它值得在融资启动前完成的原因。
八、下一步
如果正在准备融资，可以先做三件事：生成一份含传递依赖的 SBOM；把对外分发形态写清楚（SaaS、私有化、SDK 分别对应不同结论）；对红黄两级组件列出替代或隔离方案。
三件事做完，再判断是否需要外部出具意见。多数时候，投资人真正想确认的只有一句：核心代码没有不可商用的组件，或者即便有，也已经隔离。
站内相关梳理：AI 企业知识产权布局、AI 企业核心合同清单、投资人合规尽调问答，以及知识产权服务页。
最后更新：2026 年 6 月 4 日。
常见问题↑ 回到正文
开源组件是不是都能商用？
不一定。MIT、Apache 这类宽松许可证通常可以商用；AGPL、SSPL 以及带非商业限制的许可证，需要结合分发形态判断。同一组件在内部使用与对外分发两种情形下，结论可能完全相反。
只在公司内部使用 GPL 组件，会触发开源义务吗？
通常不会。GPL 的源代码提供义务以对外分发为触发条件。但产品一旦改为私有化交付、SDK 分发或硬件预装，就需要重新评估，原有结论不再适用。
融资尽调时投资人通常要看哪些材料？
五个部分：含传递依赖的组件清单、逐组件的许可证矩阵、红黄绿风险分级、替代与隔离方案、以及可被引用的审计意见。前两项回答事实，后三项回答判断。
开源合规审计需要多长时间、费用怎么算？
典型项目两到四周。报价随四个变量浮动：组件数量与依赖深度、是否包含模型权重与训练数据、分发形态、以及是否需要出具可用于交易的正式意见。
代码里有没有许可证的组件，应该怎么处理？
按高风险处理。优先替换或取得权利人授权；短期无法替换的，做进程隔离并评估，同时在交易文件中单列披露。不能默认视为可自由使用。
审计报告能直接给投资人律师用吗？
可以，前提是写明结论所依赖的假设与复核触发点。投资人需要的不是问题清单，而是一句可以写进尽调报告的话：在何种假设下，这些组件可以随产品商用。