很多企业主有个朴素的想法："我出了钱，软件当然是我的。"但法律默认规则恰恰相反。委托开发软件的著作权，不写清楚，默认归受托方（开发方）。这一条认知差，在换供应商、自建团队或融资尽调时，会突然变成大问题。本文把这条规则讲透，并给出三种可行的约定写法。
法律默认规则：不写，就归开发方
《计算机软件保护条例》第十一条：接受他人委托开发的软件，其著作权的归属由委托人与受托人签订书面合同约定；无书面合同或者合同未作明确约定的，其著作权由受托人享有。
注意三个关键词：书面合同、明确约定、受托人。口头约定不算，合同里没写不算，只写"提供使用权"也不算。只要这三点缺一个，著作权就默认落在开发方手里。
"我付了钱"为什么不够
著作权与付款是两件事。付款买的是"开发这项服务"，不是"这项成果的著作权"。除非合同写明转让或归属，否则开发方仍可能持有著作权，甚至在其他项目里复用你这套定制代码。
最常见的三个坑：
- 合同只写"开发某系统"，对著作权只字不提；
- 写"乙方授予甲方使用权"，而不是"著作权归甲方"；
- 只在邮件或微信里口头承诺，没有落到合同文本。
这三类情况在争议时都很难举证，最终吃亏的多是甲方。
三种可行的约定写法
写法一：直接归属。写明"本项目开发成果（含软件著作权、源代码、设计源文件、数据库结构文档）的著作权归甲方所有"。这是最干净、最推荐的一种。
写法二：归属 + 通用组件例外。若开发方希望保留自己的通用框架或组件权利，就要求其逐项列明通用组件清单及授权范围，其余定制部分仍归甲方。切忌用"乙方保留必要权利"这类笼统表述——笼统即等于没写。
写法三：分阶段交付 + 托管。若开发方坚持不交付源码，至少约定代码托管（第三方托管或阶段性同步），并写清触发交付的条件，例如"甲方付清款项后 N 日内交付完整仓库"。
别只写"著作权"，这几样也要一起约定
- 源代码：完整可编译的仓库，含提交历史
- 设计源文件：分层可编辑的 UI 源文件与设计规范
- 数据库结构与接口文档
- 依赖清单、构建脚本、部署与运维文档
- 是否允许开发方在其他项目复用本项目定制部分（通常约定：不允许）
已经签了合同、但没写著作权，还能补吗？
可以，但越早越好。三种常见的补救方式：
- 签补充协议：就著作权归属与交付形式单独签一份补充协议，效力与原合同一致；
- 在后续变更单中追加：若项目仍在进行，把著作权条款并入下一次变更单；
- 在验收环节约定：把"交付源码与著作权归属"写成验收的前置条件，未完成不付尾款。
需要注意的是，若开发方已经离职或失联，补救会变得非常困难。这也是为什么这件事必须在签约阶段解决——补救的成本，永远高于事前约定的成本。
另外，著作权之外还有一类容易被忽略的权利：数据库结构与业务数据的归属。数据是长期资产，建议在合同里与源码一并约定清楚。
著作权之外，还有哪些权利要一起约定
很多人只盯着"软件著作权"，却忽略了同样重要的几项：
- 设计成果：UI 源文件、设计规范的使用权与所有权；
- 数据库结构：表结构与字段设计的归属，直接影响后续换团队；
- 域名与品牌：域名所有权、商标使用权是否随项目一并归属；
- 文档与素材：需求文档、测试用例、购买的图库与字体授权。
这些"周边资产"加起来，往往比代码本身更难替换。 建议在合同里用一句总括条款兜住："本项目产生的全部成果与资料，除已列明的通用组件外，均归甲方所有。"
著作权不是一句口号，而是一组可交付的物件。建议在合同里同时约定"归属"和"交付形式"两层：归谁、怎么给、什么时候给。签约前请法务确认条款措辞，别让"默认归受托人"成为你项目的默认结局。