私有化部署采用开源组件：部署方合规核查清单

私有化部署采用开源组件：部署方合规核查清单

私有化部署采用开源组件，合规核查不能只停留在“代码可以访问”。从技术选型、镜像构建到上线运行，部署方需要持续核查许可证义务、依赖来源、修改范围、交付方式和安全维护责任。

本文以 Dify、Open WebUI、LangChain、vLLM 等存在公开仓库的项目为示例，仅整理通用核查框架，不代表任何项目方授权、认可或商业背书，也不对任何具体版本的许可证、依赖构成或企业使用适用性作出结论。

一、确认使用对象与版本边界

建立组件清单，记录项目名称、仓库地址、分支或标签、提交版本、下载日期、用途及部署位置。除顶层项目外，还应覆盖直接依赖、传递依赖、容器基础镜像、前端资源、模型文件、插件和运维脚本。

二、核对许可证原文

以拟采用版本仓库中的 LICENSE、NOTICE、COPYING 等文件为核查依据，同时查看 README、发布说明及源码文件头是否包含补充要求。许可证及附加条件可能随版本、分支或子目录变化，应按实际锁定版本留档，不能以其他版本的核查结论替代。

三、识别使用和交付方式

明确组件是仅供企业内部运行，还是会向客户交付软件、镜像、设备或托管服务。不同使用及交付方式可能对应不同义务。涉及复制、修改、再发布、网络服务或嵌入式交付时，应由合规或法务人员结合许可证原文和实际场景判断。

四、记录修改与衍生内容

保存原始版本、修改文件、补丁、提交记录和构建日志，区分上游代码、自研代码与其他第三方代码。修改范围可能影响声明保留、源码提供及交付材料准备，不应仅依赖口头说明。

五、检查声明与材料保留

核对是否需要保留版权声明、许可证文本、NOTICE 文件、免责声明或修改说明。对外交付前，应检查安装包、镜像、管理后台、产品文档和交付清单中的相关声明是否完整，避免在构建或压缩环节遗漏必要文件。

六、开展依赖与制品核查

建议为每次正式发布生成并归档软件物料清单，记录依赖版本、许可证识别结果、来源地址和制品摘要。对许可证缺失、来源不明、版本漂移或识别结果冲突的依赖，设置阻断或人工复核流程。

七、区分代码、模型与数据授权

代码仓库公开不等于其中涉及的模型权重、数据集、字体、图标、文档和示例素材适用相同许可条件。部署方案包含这些资产时，需要分别查验其来源、许可范围、使用限制和再分发条件。

八、核查商标与对外表述

开源许可证通常不当然授予项目名称、标识或商标的使用权。官网、方案书和交付文档应准确描述技术来源，避免形成项目方授权、联合发布、官方合作或商业背书的误解。

九、建立安全与更新机制

明确漏洞信息接收、版本评估、补丁验证、升级回滚和停止维护后的处置责任。公开仓库状态不能替代企业自身的稳定性验证与安全运营。正式上线前，还应结合调用量、权限模型、可用性目标和故障恢复要求进行测试。

十、形成可审计记录

建议归档选型审批、许可证原文、版本快照、软件物料清单、扫描报告、修改记录、构建日志、风险处置和法务意见。上线后如发生组件升级、部署方式变化或新增对外交付，应重新核查，不能直接沿用旧结论。

适用边界

本清单面向部署方的初步技术与流程核查，不构成法律意见，也不能替代对具体仓库、具体版本、完整依赖树和实际交付模式的逐项审查。涉及 Dify、Open WebUI、LangChain、vLLM 等项目时，应在选型阶段直接核对其对应公开仓库，并由人工确认仓库地址、锁定版本、许可证文件、NOTICE、子目录许可及依赖构成。

下载合规核查资料后，可结合部署场景、预计调用量、权限设计和稳定性要求，进一步梳理企业模型网关的部署评估范围。