SaaS交付：4张清单先拆清

导语：不要只问源代码归谁

很多企业采购 SaaS 系统或定制软件时，最容易把问题压缩成一句话：源代码到底归谁？这个问题重要，但如果第一天只问源代码，往往会漏掉更关键的交付物、许可范围、数据退出和运维接管。等到项目验收、停服、换供应商、发生安全事件或需要融资尽调时，才发现合同里写了“系统归甲方”或“软件归乙方”，却没有说清代码、配置、接口、数据库、日志、账号和备份分别怎么处理。

吕箐翎律师处理知识产权和数据合规问题 14 年，接触过 11,000+ 件咨询和案件线索。我的判断是，SaaS 交付争议的第一步不是站队说“必须交源码”或“一定不用交源码”，而是把项目拆成四张表：交付物边界、知识产权许可边界、数据退出边界、运维接管边界。

一、为什么“买了系统”不等于拿到全部源代码

软件交易里可能同时存在几层关系：软件著作权、技术服务合同、许可使用、商业秘密、开源组件、第三方 SDK、个人信息处理和数据安全义务。客户付费购买的是在线服务、定制开发、私有部署、二次开发权，还是源码买断，法律后果并不一样。

供应商也不一定恶意。很多 SaaS 产品本来就是用同一套底层框架服务多个客户，客户需求只是配置、接口和部分业务模块定制。如果合同没有写清，客户可能认为自己付了开发费就应拿到全部源代码，供应商则认为报价只覆盖服务使用和项目交付，不包含底层框架和通用组件。

真正稳妥的做法，是把“系统”拆开写，而不是用一个大词覆盖全部内容。

二、第一张表：交付物边界

交付物清单至少要列：源代码、目标代码、部署包、数据库结构、接口文档、配置文件、管理后台、测试报告、操作手册、账号权限、第三方组件清单、开源软件清单、设计稿、培训记录、验收报告和运维文档。

每一项都要写清楚三件事：是否交付，交付格式是什么，客户能不能复制、修改、迁移、再部署或交给第三方运维。比如接口文档和数据库结构，很多项目平时不觉得重要，真正换供应商或做安全审计时却是接管基础。

如果是纯 SaaS 在线服务，可以不交全部源代码，但仍应明确数据导出、配置导出、接口说明、账号移交和服务终止后的支持期。否则客户被系统锁住，供应商也会在退出时承受更大争议。

三、第二张表：知识产权许可边界

代码不是一个单一物品。里面可能包括供应商自研通用框架、客户定制业务模块、开源组件、第三方 SDK、前端模板、图片素材、算法规则和接口适配。合同应分别写清著作权归属、使用范围、是否可修改、是否可转授权、是否可用于关联公司、是否可交第三方维护、是否允许离线部署。

如果客户需要买断特定模块或取得源码托管安排，应写明范围、价款、触发条件和交接流程。比如供应商停服、严重违约、破产清算、服务中断达到一定天数时，是否触发源码托管或接管机制。

供应商也可以明确保留通用框架、基础组件和其他客户经验，但要给客户足够的项目使用和业务连续性保障。边界越清楚，后续越不容易把商业秘密保护和客户接管需求混在一起。

四、第三张表：数据退出边界

SaaS 项目最容易被低估的是数据退出。客户数据、用户个人信息、业务日志、订单记录、文件附件、配置参数、统计报表、操作痕迹和备份文件，退出时怎么导出、多久完成、什么格式、是否可校验、是否保留备份、是否删除、谁签收，都应提前写清。

只写“数据归客户所有”不够。还要看个人信息处理关系、委托处理义务、访问权限、日志留存、境外接口、供应商能否使用数据改进产品或训练模型、客户要求删除时备份和测试环境是否同步处理。

如果系统里有客户名单、交易记录、售后工单、合同附件或员工信息，退出安排更不能只靠口头承诺。数据不能导出，业务就可能被卡住；数据删除没记录，后续又可能产生合规和争议风险。

五、第四张表：运维接管边界

很多项目平时运行正常，没人关心账号和权限。真正出问题时，企业才发现没有服务器账号、云资源清单、域名解析权限、数据库权限、接口密钥、短信服务账号、支付通道账号、日志访问权限和应急联系人。

运维接管边界要写清：谁保管最高权限，谁能变更配置，故障响应时限是多少，漏洞修复如何处理，第三方服务费用谁承担，服务终止时账号如何移交，历史日志如何导出，备份如何校验。

如果系统承载订单、会员、客户资料、供应链或核心生产数据，接管不是可选项，而是业务连续性要求。没有接管方案，服务费争议、供应商人员流动、股权变动或系统故障都可能变成业务停摆。

六、场景拆解：一句“系统归甲方”为什么不够

假设一家企业采购 CRM SaaS，合同写“系统及数据归甲方所有”。上线一年后，企业准备更换供应商，要求原供应商交源代码、数据库结构、接口文档、全部客户数据和操作日志。供应商只愿意导出 Excel 客户表，拒绝交代码和数据库结构。

这个争议不能只靠“归甲方所有”解决。要看当初报价是否包含源码交付，部署方式是否支持私有化，客户是否取得修改和再部署权，数据库结构是否列入交付物，日志中是否含个人信息或其他客户数据，供应商通用代码能否拆分，第三方组件许可是否允许交付。

如果四张表一开始就存在，双方至少知道哪些是必须交、哪些要另行付费、哪些只能提供接口或托管安排。没有这些表，退出时就很容易变成互相指责。

七、客户方可以立刻做什么

第一，把系统拆成交付物清单，不要只写“系统一套”。第二，把必须掌握的业务连续性材料列出来，包括数据导出、接口文档、账号权限、备份方案和第三方接管支持。第三，把源码诉求分层：全部源码、定制模块源码、源码托管、部署包、接口文档，分别对应不同价格和风险。第四，把数据退出条款写成可执行动作：格式、时间、校验、删除、备份、签收和违约责任。

如果已经上线但合同没写清，也不要等到终止时才谈。可以在续约、功能升级、安全审计或数据合规整改时补充交付和退出安排。

八、供应商方也要提前保护边界

供应商不能只靠一句“源码不交”解决所有问题。客户需要合理的接管和业务连续性保障，否则项目越核心，争议越大。供应商可以把底层框架、通用组件、算法工具和其他客户经验列为保留范围，同时明确客户对项目配置、定制模块、接口文档、数据导出和运维资料的使用权。

供应商还要管理开源组件和第三方 SDK。客户要求源码交付时，如果里面混有授权不清的组件、第三方代码或不能转授权的素材，后续也会出现合规问题。交付边界不是只保护供应商，也是保护客户后续使用。

九、风险边界

本文仅作一般法律信息参考，不构成针对具体项目或案件的法律意见，也不替代正式咨询。具体项目应结合合同文本、报价单、交付清单、部署方式、数据类型、个人信息处理关系、开源组件、第三方服务和业务连续性要求判断。

十、今天可以先做的清单

今天先做四件事：列交付物清单，标出哪些必须拿到；列权利许可清单，区分使用、修改、再部署和转授权；列数据退出清单，写明格式、时间、删除和备份；列运维接管清单，确认账号、权限、接口和应急联系人。关注本号，后续继续拆解 SaaS、软件著作权、数据合规和企业知识产权合同中的高频风险。