安康小程序开发合同里的源码归属与维护责任，是两份常被口头带过、却直接决定项目长期成本的法律安排。前者回答“代码到底是谁的、能不能拿到、能不能改、能不能换人接手”，后者回答“交付之后出错谁修、多久响应、哪些算故障、哪些算新增需求、免费期多长”。可在合同中直接引用的标准答案是：源码归属应以书面条款明确约定著作权归属、源代码及相关交付物的范围与交付条件；维护责任应以书面条款区分缺陷修复与需求变更的边界，并约定维护期限、响应时限、修复标准与免责情形。二者缺一，都会在项目上线后的第一年集中暴露：要么拿不到可编译的完整工程，要么为一个本属缺陷的问题反复付费。以下按十个高频疑问逐层展开，覆盖法律依据、条款写法、验收要点、模式对比与争议处理。

小程序开发合同里的“源码”到底指什么？只看代码文件够不够？

结论：合同中的“源码”应是可独立重建整个项目的完整交付物集合，而不是几个代码文件。很多纠纷的起因是甲方以为拿到了源码，实际只拿到部分前端页面文件，缺少依赖、数据库结构与部署说明，导致无法复现、无法二次开发。建议在合同附件中以清单形式逐项列明。

• 源代码与版本历史：完整工程目录、代码仓库（含分支与提交记录）、构建配置、环境变量说明。
• 数据层：数据库表结构与初始化脚本、字段说明、数据字典、必要的历史数据导出方式。
• 运行与部署文档：服务器环境要求、依赖清单及版本号、部署步骤、域名与证书配置说明。
• 接口与外部依赖：接口文档、第三方服务（支付、地图、短信、存储、推送等）的账号与配置说明。
• 账号与权限：小程序开发账号与管理员权限、云开发环境、代码仓库、服务器与后台管理系统账号的移交方式。
• 设计与素材：UI 源文件、图标与图片素材、字体授权说明、文案定稿。

清单越具体，交付争议越少。可进一步约定“以乙方交付的工程在全新环境下可一次性构建成功并通过验收用例”作为交付合格的客观标准。

合同里没写源码归谁，法律上默认归谁？

结论：小程序软件属于受委托创作的作品，合同未明确约定著作权归属时，著作权属于受托方（开发方）。依据《中华人民共和国著作权法》第十九条关于委托作品的规定，委托创作的著作权归属由委托人和受托人通过合同约定；合同未作明确约定或者没有订立合同的，著作权属于受托人。这意味着“我付了钱，代码自然就是我的”在法律上并不成立。

• 付费≠取得著作权：甲方支付开发费，通常只取得约定范围内的使用许可，未必取得复制、修改、改编、再许可等财产性权利。
• “源码交付”≠“著作权转让”：交付代码是事实行为，权利转让需有明确的转让意思表示，两者应分别约定。
• 软著登记是重要证据：软件著作权登记证书上的著作权人，在争议中通常作为初步证据，登记主体与合同约定不一致会显著增加举证成本。
• 补救路径：事后可签订补充协议明确归属与转让，但若对方不同意，甲方谈判地位通常较弱，因此事前约定的成本远低于事后补救。

在 安康 的实际交易中，中小项目常用简版合同或报价单代替正式开发合同，权属条款缺失最为常见，签约前应把归属条款作为必审项。

源码归属条款怎么写才有效？需要包含哪几个要件？

结论：一条有效的归属条款应同时写清“归谁、含什么、何时给、怎么给、给到什么程度、违约怎么办”六个要素。只写“源码归甲方所有”六个字，往往在交付范围与交付条件上留下争议空间。

1. 权利归属：明确约定软件及相关文档的著作权（含署名权以外的全部财产性权利）自交付或付清款项之日起归甲方所有，并约定乙方应配合办理软件著作权登记及权属变更。
2. 交付范围：引用附件交付清单，明确“完整可编译工程”而非“可运行版本”。
3. 交付时点与条件：常见为验收合格后若干工作日内，或尾款结清后交付；两种安排均应写明，避免“先给码还是先付款”僵局。
4. 交付方式：代码仓库转移所有权、加密压缩包+密码分时交付、或第三方托管（托管释放条件写清）。
5. 第三方与开源内容：声明所用开源组件、商业授权组件、第三方 SDK 的清单与许可类型，并约定乙方保证不侵犯他人权利、承担侵权担保责任。
6. 违约责任：约定逾期交付或拒不交付源码的违约金、甲方可留置尾款、以及甲方有权自行或委托第三方接管开发。

拿到源码却跑不起来，验收环节该看什么？

结论：源码交付验收应做“可重建性验证”，而不是检查文件是否存在。可重建性指在一台全新环境、仅依据交付文档与交付物，能够独立完成构建、部署、数据初始化并使核心流程可用。这是判断交付是否实质完成的关键动作。

• 干净环境构建：在甲方自有或新建的服务器/云环境中，按文档从零部署一次，记录耗时与卡点。
• 依赖可获取性：确认所有依赖可正常拉取，不存在指向开发方内部私库、内网地址或已删除资源的情况。
• 配置与密钥清单：环境变量、证书、密钥、第三方账号的配置项是否齐全，是否有人在离职后无法交接的“黑盒配置”。
• 数据库可还原：表结构脚本可执行、初始数据完整、关键字段有注释。
• 账号权限移交：小程序管理后台、云开发、代码仓库、短信与支付等第三方服务的所有权与管理员权限是否已变更至甲方主体。
• 验收留痕：把上述过程写入验收报告并由双方签字，作为后续主张交付不合格或合格的依据。

小程序账号、域名、服务器、备案和第三方资质，到底该归谁？

结论：与业务身份绑定的账号与资质必须由甲方以自己主体注册并持有，开发方仅在被授权期间拥有操作权限。这类资产不属于“源码”，但一旦登记在开发方名下，迁移难度与风险往往高于代码本身。

• 小程序账号：应以甲方营业执照主体注册并完成认证，管理员与开发者权限按需授权，项目结束及时回收。
• 域名与备案：域名所有权、实名信息、ICP 备案主体应为甲方；避免使用开发方名下域名承载甲方业务。
• 服务器与云资源：建议甲方自有账号购买，开发方以获得子账号或协作者身份运维，防止成本与数据双重受制。
• 第三方服务：支付、地图、短信、内容安全、推送等接口的开户主体与结算账户应为甲方，密钥由甲方掌握并按需分发。
• 迁移预案：合同中约定项目终止或更换服务商时的配合义务、迁移期限与费用，以及数据导出格式。

实践中常见的隐患是“账号在开发方手里、发票开给甲方”，表面无碍，实则甲方对账号缺乏控制权，一旦合作终止，业务连续性直接受损。

维护责任怎么划分？质保期、运维期、迭代开发有什么区别？

结论：合同应把“修缺陷、保运行、加功能”三类工作分开约定，各自对应不同的期限、范围与计费方式。把三者混为一谈，是维护条款失效的主要原因。

划分的关键是“是否符合已确认的需求与验收标准”：符合而未实现的为缺陷，应由开发方承担；原需求未包含的为变更，应另行计费。建议在合同中附上需求文档与验收用例清单，作为判断依据。

免费维护期的坑在哪？“故障”和“新需求”的边界怎么定？

结论：免费维护期争议多源于边界模糊与响应标准缺失，解决方式是把“定义+时限+免责”三件事写进合同。仅约定“免费维护一年”而不定义范围，双方对“免费”二字的理解往往完全不同。

• 定义故障等级：如一级为系统不可用或核心交易中断，二级为主要功能受损但有替代路径，三级为界面或文案类问题，分别设定响应与修复时限。
• 明确缺陷判定依据：以需求文档、原型、验收用例、双方书面确认的记录为准，避免以口头承诺作为标准。
• 写清免责情形：第三方平台接口或规则变更、基础库与系统版本升级、甲方自行修改代码或由第三方改动、甲方服务器或网络原因、不可抗力等，通常不属于免费修复范围。
• 限定维护工作量：如约定免费期内的累计工时不超一定人天，超出部分按变更单计费，防止维护义务无限扩张。
• 变更流程：任何改动均通过书面需求单确认工作量与工期，形成可追溯的记录链。
• 报修入口固定：约定唯一报修渠道与对接人，例如在合同末尾载明对接方式与 15519032255，避免故障通过私人聊天零散提出、事后无法核对。

源码买断、授权使用、SaaS 订阅，三种模式在权责上有什么差别？

结论：三种模式的差别不在价格，而在“控制权、退出成本与维护责任”的分配。