简介面向软著申请与多方协作开发场景的《合作开发协议模板》能够帮助软件开发者、高校团队及初创企业提前界定合作各方权责避免因成果归属、职责不清产生纠纷。协议围绕具体开发项目展开逐条明确合作宗旨、项目范围、合作期限、分工方式、知识产权共有规则、协议变更限制、禁止行为及违约责任、合作终止情形、纠纷解决途径等尤其强调源代码、技术文档由合作方共同享有著作权并包含技术困难互助、不得私自以团队名义开展业务等操作细节设置签署栏便于直接填写使用。模板从合作启动到终止全流程设计了风险防控条款可有效减少协作中途分歧。资源包为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. 从一份协议到一套合作规则模板之外还需要做的事协议签完不等于合作就稳了它只是把合作规则定下来了。想让这份软著合作开发协议真正发挥作用还需要把协议里的承诺落到日常开发流程中去。我建议在项目启动时同步建立三份配套文档。第一份是技术架构说明记录系统整体结构、模块划分、技术选型及其原因这份文档既是软著说明书的素材也是日后分工界定的依据。第二份是接口约定文档前后端如何联调、字段如何定义。第三份是版本发布记录每次发版说明都记录日期、内容、参与人形成客观的合作过程档案。这三份文档不需要多精美但必须有。因为它们解决的是协议里谁干了什么的问题——真实记录比任何口头回忆都可靠。日后如果出现分歧这些过程文档能证明各自的贡献和协议条款互相补充。最后分享一个我的个人习惯协议签完我不建议直接塞进文件夹吃灰。把其中关于里程碑、交付时间、验收标准、收益分配比例的几页拍个照片存在手机里。不是不信任对方而是合作开发这件事沟通成本本来就高把大家说好的事情可视化、随时能翻到本身就是在降低合作摩擦。等你自己做过一次从签约到开发再到软著登记的全流程你就会明白那份协议不是给律师看的是给你们两个人共同看的。本文还有配套的精品资源点击获取