定制软件做到后期，企业最关心的问题之一往往是：源码到底给不给？不给怕被绑定，给又担心报价与责任边界说不清。定制软件源码归属，应在合同阶段就写明白，而不是上线后再争。
源码交付争议，表面上争文件，实际上争的是可维护性与二次开发权。下面从争议点、约定方式、条款清单、双方边界四个维度说明。
一、源码争议通常争什么
争的不只是文件在不在，还包括：能否独立编译部署、是否含第三方闭源组件、文档是否齐全、是否允许换供应商继续开发。
只约定「给源码」四个字，仍然可能拿到无法维护的半成品，二次开发权形同虚设。
二、常见约定方式
验收后完整交付：结清尾款后交付约定范围内源码与文档，适合多数定制项目。
里程碑逐步交付：降低单边风险，但仓库权限与版本管理成本更高。
托管或监管交付：源码放约定仓库，双方权限清晰，适合较大或长期项目。
三、企业侧建议写清的条款
交付清单：应用源码、构建脚本、接口文档、部署说明、账号移交清单。
第三方组件：哪些可交付、哪些仅授权使用，许可证风险谁承担。
售后边界：源码交付后，质保与付费运维如何划分，避免「源码到手却无人会部署」。
四、也要理解供应商的合理诉求
未结清款项前限制交付、对自研中间件另行授权、对开源合规共同负责，这些在行业里并不少见。
关键是透明写进合同，而不是口头默认。清晰的条款反而有利于长期合作。
建议验收时做一次「干净环境部署演练」：按文档在新机器拉起系统，验证源码交付不是形式主义。
对依赖云服务密钥、证书、第三方控制台的部分，应列入账号移交清单，否则定制软件源码归属完整也无法独立运行。
若使用供应商自研框架，可要求提供培训或额外文档，避免二次开发权有名无实。
开源组件清单（SBOM 或依赖列表）越来越被重视，可在合同附件中要求定期更新。
若未来可能拆分模块给不同供应商，合同里可预留模块化交付与接口文档义务，降低锁定。
源码交接当天建议做清单勾选与双方签字，定制软件源码归属从约定变成可审计事实。
小结
定制软件源码归属不是给或不给的单选题，而是交付物、时机、权利与售后的组合题。提前约定，合作更长久。
质保之后的持续迭代可参考网站运营另行约定。