简介：面向软著申请与多方协作开发场景的《合作开发协议模板》，能够帮助软件开发者、高校团队及初创企业提前界定合作各方权责，避免因成果归属、职责不清产生纠纷。协议围绕具体开发项目展开，逐条明确合作宗旨、项目范围、合作期限、分工方式、知识产权共有规则、协议变更限制、禁止行为及违约责任、合作终止情形、纠纷解决途径等，尤其强调源代码、技术文档由合作方共同享有著作权，并包含技术困难互助、不得私自以团队名义开展业务等操作细节，设置签署栏便于直接填写使用。模板从合作启动到终止全流程设计了风险防控条款，可有效减少协作中途分歧。资源包为1个docx格式文档，大小约14KB，轻量易用。已有11740人浏览学习，适合正在筹备软著申请或联合研发项目的团队作为法律参考模板，帮助降低协作风险、提升项目合规性。
1. 为什么合作开发必须有一份"看得见"的协议
先说个真实场景，我见过不止一次：两个关系很好的朋友，一个懂技术、一个懂业务，一拍即合决定一起做一款软件。前期所有沟通都在微信和饭桌上完成，技术选型聊得热火朝天，功能规划已经细化到了每个页面。然后项目做了三个月，代码写了上万行，突然有一个人开始问：这个软件将来软著写谁的名字？收益怎么分？如果我要退出，代码归谁？
这时候再回头补协议，已经不是"签个字"那么简单了。因为真正的问题不是有没有协议，而是双方对"合作"这两个字理解得完全不一样。
从软件著作权登记的角度看，合作开发涉及两个层面的权属问题：一是著作权本身归谁，二是著作权怎么行使。这两个问题如果不在项目启动前说清楚，后面每走一步都是隐患。所以我一直建议，凡是两个人以上一起开发软件，第一件事不是写代码，而是把协议模板拉出来，把权属、分工、成本、收益、退出机制这些条款逐条过一遍。
这篇文章想做的，就是把我手里这套经过多个项目检验的"软著合作开发协议模板"拆开讲透——每一份协议应该包含哪些板块，每个板块为什么必须写清楚，哪些措辞在真正发生分歧时会让双方哑口无言，哪些条款看起来合理但实际上是个坑。不是把模板丢给你让你自己抄，而是让你知道你在签的到底是什么。
适合谁看？准备和朋友合伙做软件的人，公司之间要联合开发一个系统的人，以及那些已经在合作开发、但发现自己手上只有聊天记录的兄弟，都该看看。
2. 协议里最容易扯皮的三大板块：权属、分工、成本
一份可执行的合作开发协议，绝不是在网上随便下一份，改个公司名就叫合作开发协议了。它至少要回答三个核心问题：做出来的东西算谁的，中间谁干什么活，钱由谁来出。
2.1 著作权权属：为什么"共同享有"四个字反而是最危险的表述
很多人在写协议时会顺手写上"著作权归双方共同享有"，觉得这句话公平。但实际这套表述在软著登记时会出现问题。
先说法规层面。中国计算机软件保护条例里对合作开发的默认规则是：合作开发的软件，著作权由合作开发者共同享有。但"共同享有"分两种情形——如果各方贡献无法区分，就是共同共有；如果贡献能够区分出模块边界，则各自对自己开发的模块单独享有著作权，对整体是共同享有。这个差别在登记和后续维权时非常关键。
实务中，"共同享有"这四个字真正的问题在于：它没有定义"怎么行使"。比如一方想把软件授权给第三方使用收取授权费，另一方不同意怎么办？比如一方想把软件做二次开发，另一方觉得这动了核心代码、拒绝配合，怎么办？这些都叫"著作权行使规则"，必须在协议里提前约定。
我自己的习惯是，在协议里至少写清三件事：第一，整个软件整体的著作权登记以谁的名义申报，另一方是否配合签字；第二，如果有模块划分，各模块分别归属哪一方，哪些属于公共底层代码、由双方共同维护；第三，对外授权、转让、许可使用必须经过双方书面同意，且收益分配按约定比例执行，而不是默认"平均分"。
2.2 分工与交付标准：没有验收标准的合作，等于没分工
光写下"甲方负责前端开发，乙方负责后端开发"是不够的。我见过最典型的翻车案例：双方各自说"我那块早就做完了"，然后一联调发现接口字段对不上，再往深了问，发现双方对"完成"的理解差了十万八千里——甲方觉得页面能打开就算完成，乙方觉得性能指标不到位不能算完成。
所以协议里的分工条款，不能只写"谁做哪一块"，至少要包含四个维度：具体的工作范围和边界，交付物形式（源码、接口文档、测试报告、部署脚本），交付时间节点，以及验收标准。
验收标准这块容易被忽略，但它恰恰是软著申请的基础。因为软著登记需要提交源代码和软件说明书，如果双方分工时没有约定清楚"谁负责汇总源代码、谁负责编写软件说明书"，到了申请阶段就开始互相推脱。
写协议时建议直接把"软著申请材料工作分配"作为一个独立条款写进去，明确约定：由哪一方负责汇总完整源代码，由哪一方负责撰写软件说明书和操作手册，申请费用由双方共同承担还是某方单独承担。这一点很多协议模板都漏了，但这才是"软著合作开发协议"和普通合作开发协议的根本区别。
2.3 成本分担：研发投入和申请费用不是一回事
成本条款在合作开发协议里往往写得最简单，也最容易留下隐患。
研发成本包括人力投入、服务器费用、第三方SDK授权费用、字体图片素材购买费用等等。人力成本最不好量化——两个朋友合伙创业，没人给彼此发工资，代码都是下班后熬夜写的，这个时候谈"成本"很伤感情。我的建议是：人力投入可以不折算成具体金额，但其他所有现金支出必须记账并双方确认。
至于软著申请相关费用，包括官方登记费、代理服务费（如果委托代理机构）、软件说明书打印装订费用等，这些金额一般不大，但属于必须明确的事项。协议里最好写明：登记申请由谁办理、费用由谁承担、如果委托第三方代理机构则选任需经双方同意。这一条不写清楚，等到真要申请软著的时候，容易因为百八十块钱伤了和气，那才是真不值当。
3. 这套协议模板的章节架构和起草思路
现在我把自己实际在用的那套协议模板的骨架列出来，并解释每一章的设计意图。它不是法律条文堆砌，而是按项目推进的时间线来组织的，方便非法律背景的人边看边理解。
3.1 模板总览：八章结构为何这样搭
第一部分是定义条款，把"软件""源代码""文档""交付""验收"这些词的含义固定下来。这个部分看着枯燥，但必不可少。比如"源代码"到底含不含第三方开源组件的源码？"文档"包含哪些文档？不定义清楚，后面所有条款都会产生歧义。
第二部分是合作范围和目标。用一小段话概括项目要做什么，这看似简单，实际上是在给整个合作协议划定边界。防止合作过程中"顺手多做一个功能""顺便帮我改个BUG"这类凭交情加需求、最后算不清账的情况。
第三部分是权力与分工，这是协议的主体，我在2.2节的框架就是这一章的细化。写明各方角色、工作任务、时间节点、质量标准。
第四部分是知识产权归属和软著登记，这是"软件"这份协议区别于其他合作协议的关键，我在2.1节的框架就放在这一章。
第五部分是收益分配和商业化使用。合作开发的软件如果上线后的运营产生收益，或者对外授权收取费用，怎么分、由谁收款、什么时候结算，这些都在这一章。
第六部分是保密条款。合作期间会接触对方的代码、业务数据、商业计划，保密范围、保密期限、违约责任需要写清楚。
第七部分是退出机制和终止条款。中途一方退出，代码怎么处置，已产生的份怎么归属，未完成部分怎么交接，这是朋友合作最容易谈崩的地方。
第八部分是违约责任和争议解决。约定不住的情形要承担什么责任，争议解决方式是仲裁还是起诉，哪个法院管辖。
3.2 起草时如何把控"软件"气质的差异化条款
通用合作协议的模板网上一大堆，但软著合作开发协议有它独特的几个点，单独拿出来重点说。
第一个是源代码的交付形式。通用协议不会写源码长什么样，但软著登记和后续合作维护，必须在协议里明确源代码的存放位置、版本管理工具、代码注释规范，甚至约定定期把代码快照提交到一个双方都能访问的仓库。我曾经遇到过，合作方做完一期功能，把自己电脑上的代码打成一个压缩包发给对方就算"交付"了，结果三个月后，这个压缩包里的代码版本和运行环境根本对不上，维护起来像考古。
第二个是第三方开源许可的合规性。现在做软件开发，谁不用开源库？但用了什么协议的开源库，会直接影响软著登记和后续商业化，尤其是GPL这类传染性强的协议。协议里应该约定：各方引入的第三方代码必须向对方披露，并保证不会导致整体软件的许可证冲突。这一条对后续想上架应用市场或做SaaS服务至关重要。
第三个是软著申请被驳回或出现异议时的应对机制。软著申请一般不涉及实质审查，驳回概率低，但万一出现补正、异议等情况，由谁负责跟进、相关费用怎么分担，最好事先有约定，避免到时候手忙脚乱。
4. 那些协议模板不会告诉你的实操注意事项
模板上面的条款都覆盖了之后，我在实际项目里还踩过一些模板覆盖不到的坑，这些经验写下来供你参考。
4.1 签名页之前的"最后三分钟检查"
协议打印出来准备签之前，我建议花三分钟从头到尾做一次"代入式检查"。把自己代入到六个月后、两个人已经撕破脸的场景里，看每一条约定还能不能推导出一个确定的结果。
比如你看到"收益按约定比例分配"这一条，往下翻，应该能找到"约定比例"到底是多少；看到"乙方负责后端开发"，往下翻，应该能找到"后端开发"具体包含哪些模块。模板不是合同，模板给你的是文字，文字背后是否能指向一个确定的结果，才是合同真正的意义。
4.2 软著申请时著作权人信息要能对应上协议
这是个特别容易踩的坑。协议里写了"著作权由双方共同享有"，但软著登记申请表的著作权人信息只能填一个或多个明确的主体。如果两方都是个人，就填两个个人；如果有一方是公司，就得填公司名称。这时登记信息必须和合作协议里的主体保持一致。
有一次帮一家公司审协议，他们在协议里约定著作权归"项目组"共同享有，但"项目组"既不是自然人也不是法人，根本没有资格作为著作权人申请软著。等到申请时才发现，只能临时改协议。
4.3 版本管理和技术文档也是权属的一部分
再强调一次：软著申请要交60页源代码和软件说明书，这个"源代码"和"说明书"本身的选择和编排也体现了独创性，属于著作权保护的一部分。所以合作协议里关于代码汇总人、说明书撰写人的约定，不只是行政分工，还直接影响哪些材料能被认定为"合作开发成果"的一部分。
实际操作中，最好指定一个人负责从版本管理工具里导出完整的源代码目录，并保持目录结构完整。另一个人负责按照软著申请的规范编写说明书（包括软件名称、版本号、开发环境、运行环境、主要功能、操作流程图等）。两个人之间要有一个交接确认的动作，例如通过邮件确认最终提交的版本。这些细节写在协议里，能省掉大量申请阶段的口头沟通成本。
5. 从一份协议到一套合作规则：模板之外还需要做的事
协议签完不等于合作就稳了，它只是把合作规则定下来了。想让这份"软著合作开发协议"真正发挥作用，还需要把协议里的承诺落到日常开发流程中去。
我建议在项目启动时同步建立三份配套文档。第一份是技术架构说明，记录系统整体结构、模块划分、技术选型及其原因，这份文档既是软著说明书的素材，也是日后分工界定的依据。第二份是接口约定文档，前后端如何联调、字段如何定义。第三份是版本发布记录，每次发版说明都记录日期、内容、参与人，形成客观的合作过程档案。
这三份文档不需要多精美，但必须有。因为它们解决的是协议里"谁干了什么"的问题——真实记录比任何口头回忆都可靠。日后如果出现分歧，这些过程文档能证明各自的贡献，和协议条款互相补充。
最后分享一个我的个人习惯：协议签完，我不建议直接塞进文件夹吃灰。把其中关于里程碑、交付时间、验收标准、收益分配比例的几页拍个照片存在手机里。不是不信任对方，而是合作开发这件事，沟通成本本来就高，把大家说好的事情可视化、随时能翻到，本身就是在降低合作摩擦。等你自己做过一次从签约到开发再到软著登记的全流程，你就会明白，那份协议不是给律师看的，是给你们两个人共同看的。
本文还有配套的精品资源，点击获取
