客户要求软件“不开源”：交付承诺前，先分清自有代码和开源组件义务

先给判断：商业软件可以保护自有代码，但不能用一句“不开源”跳过组件许可证

客户采购定制软件时，常会要求合同写明“源代码不公开”或“交付软件不含开源义务”。这类承诺不能只按项目是商业项目来判断。最终交付物一旦使用开源组件，是否需要保留声明、提供许可证文本、公开对应源码或履行其他条件，要回到该组件的版本、许可证文本、是否修改，以及实际是向客户分发、交付源码，还是仅提供在线服务来判断。

因此，自有代码的保密安排与开源组件的许可义务是两条不同的线。客户可以约定自有代码的交付范围和保密要求，但交付负责人不能在没有核清组件事实前，把它概括成“项目全部代码都绝不需要公开”。

判断一：开发环境里出现过，不等于已进入客户收到的交付物

先区分组件出现在哪个位置。构建环境、测试工具或历史依赖中出现的组件，未必被编入本次安装包、SDK、容器镜像或源码包；反过来，最终制品中的间接依赖也不能因研发人员没有手工加入而被忽略。

判断交付义务时，应以本次客户实际收到或可取得的制品为中心，而不是只看研发仓库里的一份通用依赖表。交付包、镜像、SDK、部署脚本和源码包的范围不同，对应需要核对的组件集合也可能不同。

判断二：组件名称相同，版本和修改情况不同，结论也可能不同

同一开源组件换了版本、被修改过，或只是被作为未修改依赖使用，许可分析不能直接沿用旧项目的结论。仅凭采购单、产品名称或“我们一直这么用”，都不足以判断本次交付应作何种声明或安排。

对准备交付的版本，至少把组件名称、准确版本、许可证文本、修改情况和进入哪个制品对应起来。没有这五项事实，不宜先向客户承诺“肯定不需要任何开源处理”，也不宜反过来笼统说“必须公开全部代码”。

判断三：合同条款要对应交付方式，不能替许可证作事实判断

合同中的源码、第三方组件、开源合规和责任分配条款，应以已经核对的交付事实为基础。若客户取得的是安装包、SDK或源码，条款应对应各自的组件清单和许可证处理；若只是在线服务，也应先确认实际提供方式再写承诺。

合同可以约定双方之间的交付边界，却不能把尚未识别的许可证条件变成一句空泛保证。把“无开源义务”写进合同前，先确认它指的是自有代码保密、某个交付包不含特定组件，还是已完成某项许可证要求；这三种表述不是同一回事。

交付前先形成一张与制品对应的清单

为本次客户交付分别列出安装包、镜像、SDK、源码包或在线服务：每一项对应哪些组件、哪个版本、适用什么许可证、是否修改、采用何种提供方式，以及已准备哪些声明或交付材料。再让合同中的源码和开源条款逐项对应这张清单。

Open Source Initiative 的许可证目录可以帮助定位具体许可证文本，但不能替代对实际代码、交付方式和条款的分析。本文提供一般信息，不对任何具体组件或合同作出发布义务结论。