IT研发外包，这NDA和代码所有权协议到底怎么谈才不被坑？
说真的，每次看到那些大段大段、全是法律术语的合同模板，我就头疼。对于咱们搞技术或者做项目管理的人来说，跟外包团队谈合作，最怕的不是代码写得烂，而是最后代码归谁、这事儿能不能保密，扯得一地鸡毛。这事儿我踩过坑，也帮朋友填过坑。今天不说那些虚头巴脑的，就用大白话聊聊，怎么把NDA（保密协议）和代码所有权协议这俩玩意儿给签明白了，让你既能安心搞外包，又能保护好自己的核心资产。
先搞清楚，咱们到底在怕什么？
在动手写协议之前，你得先想明白自己真正的担忧是什么，针对性地去堵漏洞。
怕创意被偷
这种事儿太常见了。你把一个绝妙的点子、还没上线的App原型，一股脑儿地发给外包团队，结果过几个月，市场上出来一个跟你功能、界面极其相似的东西。这时候你想找人哭都没地儿哭去。所以，NDA（非 disclosure agreement） 是第一道防线。
怕代码不是你的
这个是最核心的。你花了真金白银，让外包团队开发，结果最后人家说：“代码是我们写的，所有权归我们，你可以用，但不能改，也不能拿去给别的人做。” 这不等于你花钱给自己请了个“爹”吗？以后想迭代、想二开，都得被他捆绑。所以，代码所有权后续协议（IP Assignment） 才是重中之重。
怕人员流动，知识断层
外包团队今天张三做，明天李四走，代码写得跟屎一样，文档也没有。项目一结束，人家团队解散，你拿着一堆谁也看不懂的代码，想自己招人维护，发现难如登天。这其实也是合同里该管的事，虽然不完全是法律问题，但一个好的协议会约定文档和交接标准。
NDA到底怎么写才有效？不是签个字就行
很多人以为NDA就是个形式，随便下载个模板填填就完事了。其实，NDA写得越具体，保护效果越好。
保密信息的定义要“宽进严出”
条款里写“保密信息”是什么的时候，别只写“技术文档”“源代码”这些。要写得宽泛点，比如：
- 任何形式的商业信息：包括但不限于我们的用户数据、市场策略、开发计划、财务预算。
- 未公开的功能描述：哪怕只是个笑话一样的脑洞，只要是我们透露给你的，都算。
- “口头”或“暗示”的也算：很多团队会说“我没拿到书面文档”。所以条款要写上，“所有以书面、口头、电子形式或其他形式透露的信息，只要接收方能合理识别出这是保密信息，都受本协议约束。”
“免责清单”别忘了加
有一些信息，就算你透露了，也算不上是保密信息。为了公平（也为了避免麻烦），通常会加上这几条：
- 在你透露之前，接收方已经知道的（得有证据证明）。
- 不是因为接收方的过错，而是从第三方那里合法搞到的。
- 接收方自己独立开发出来的，没用过你的信息。
- 法律法规要求披露的（这种要提前通知你）。
保密期限是个坑
很多外包团队会拼命想缩短保密期，说“我们签个2年保密期就行了”。但对于技术秘密和商业机密来说，2年哪够？
通用的做法是：
- 对于NDA本身的-breaching（违约）责任，通常时效是3-5年。
- 对于技术源代码、算法、架构设计这种东西，保密期应该是“无限期”，或者至少是“直到该信息进入公有领域”为止。因为技术的生命周期可能很长，一旦泄露，影响是永久的。
违约条款要够痛
如果违反了NDA，罚什么？光说“赔偿损失”太虚了。可以考虑加上“违约金”（Liquidated Damages）。比如约定一个具体的金额，或者约定“鉴于损失难以计算，违约方需支付合同总金额的X%作为违约金”。这样对方在动歪脑筋之前，会先掂量掂量成本。
代码所有权：这才是真正的战场（这里要用表格，为了清晰）
NDA只是前菜，代码所有权才是主菜。这是最容易产生纠纷的地方，一定要在合同里白纸黑字写清楚。通常在合同正文后面，会有一个大章节叫“知识产权归属”（Intellectual Property Ownership）。
我们先看一下几种常见的模式，以及它们分别适合什么场景：
| 归属模式 | 简单描述 | 外包方（甲方）成本 | 适用场景与风险 |
|---|---|---|---|
| 完全归属于甲方 | 外包团队写的每一行代码、画的每一张图，所有权都归你。他们没有任何权利再使用。 | 最高（通常需要支付溢价，或者单独的知识产权转让费）。 | 强烈推荐用于核心业务、自研产品、涉及核心算法的项目。这是行业标准做法。 |
| 宽松的“可使用权” | 代码所有权还是归外包公司，但授予你永久、不可撤销的使用权。允许修改和分发，但不允许“卖代码本身”。 | 中等 | 适用于一些标准化的组件开发。风险在于：如果外包公司倒闭或把代码卖给竞争对手，你会很被动。 |
| 基于开源协议 | 代码是开源的（如MIT, Apache 2.0），双方共享。外包方甚至可以复用。 | 低 | 仅适用于你自己也打算开源的项目，或者非核心外围功能。商业闭源产品绝对不要用这个。 |
| 共有知识产权 | 双方共同拥有所有权。 | 模糊 | 这是个大坑！除非是合资公司，否则尽量避免。这意味着你要授权给别人使用，可能需要对方同意。极其麻烦。 |
从上表可以看出，对于绝大多数做外包研发的公司或个人，我的建议是：
不惜一切代价，争取“完全归属于甲方”。 哪怕多加点钱，或者在合同里专门写一条“Work for Hire”（委托创作）条款。这在法律上能更彻底地把所有权锚定在你身上。
核心条款怎么写？
在SOW（Statement of Work，工作说明书）或者主合同的IP条款里，你应该要求包含以下类似的话（不用背，理解意思，找律师润色）：
“Pre-existing IP（既有知识产权）： 外包方保证，交付的成果不包含任何第三方的受版权保护的代码，除非你明确授权。如果是用了开源组件，必须列出清单，并且要符合你的商业发布要求（比如不能是GPL这种具传染性的协议）。”
“Assignment（转让）： 外包方同意，所有在本项目中产生的代码、设计、文档及相关知识产权，自完成之日起，自动、完全地转让给甲方。外包方保留署名权（如果甲方允许的话），但放弃所有其他权利。”
警惕“背景技术”（Background Technology）
外包公司通常会有一些自己开发的通用框架或底层代码。在给你交付的项目里，他们可能会嵌入这些代码。
这时候你要问清楚：
- 这个背景技术是他们独有的吗？
- 你以后使用这部分代码要付钱吗？
- 如果他们以后把这个技术开源了，会不会影响你的商业独家性？
最好是让外包方承诺：项目中使用到的所有第三方代码和自有框架，必须符合“无版权负担”或者“永久免费授权给你使用”的条件。
那些合同里容易被忽略的“软条款”
写了硬碰硬的NDA和IP归属，还有一些细节决定了执行的顺滑度。
离职交接与“Bus Factor”
技术圈有个词叫“Bus Factor”（巴士因子），意思是如果核心开发人员突然被公交车撞了（或者离职了），项目会不会完蛋。在外包里，这事儿太常见了。
你得在合同里加上：
“外包方应确保项目核心人员的稳定性。如需更换人员，必须提前X周书面通知甲方，且接替人员的资历不得低于原人员，并需免费提供至少X小时的知识转移（Knowledge Transfer）时间，确保代码和文档顺利交接。”
别怕麻烦，这就叫“后事条款”。
审计权（Audit Rights）
外包团队用了你付钱开发的代码，转头卖给了别人，你怎么知道？合同里要加一条“审计权”：
“甲方有权在提前通知的情况下，检查外包方在相关项目中使用的代码库和分发记录，以确认没有违反知识产权转让条款。”
虽然你未必真的会去查，但有了这条，对方心里会有个忌惮。
源代码托管（Escrow）
如果项目金额比较大，或者外包公司规模很小，你担心他跑路。可以签一个源代码第三方托管协议。
简单说就是：把最终的源代码交给一个第三方机构保管。如果外包公司倒闭、失联、或者拒绝履行维护义务了，你就可以向第三方机构申请，拿到源代码。这就相当于给你的项目上了一道保险。
实操中的几个小建议（省流版）
- 不要只发一个模板： 每个项目情况不同。核心业务模块，必须签严格的NDA和完全转让IP；外包个小插件、改个UI，可以适当放宽。
- 口头承诺不值钱： “放心吧，代码肯定给你，我们是大公司。” —— 别信，落笔为安。特别是涉及到新功能的创意，发原型图之前，先让NDA生效。
- 验收标准与IP挂钩： 比如可以在合同里约定：“只有当所有源代码、文档、测试用例已完整交付并验收通过，且知识产权转让文件签署完毕后，尾款才予支付。” 用钱压着，对方动作会快很多。
- 找个懂技术的法务（或者懂法务的CTO）： 律师不懂代码，可能会写错字（比如把“Object-C”写成“Objection-C”）。最好让技术负责人和法务一起过一遍合同，确保技术细节没漏洞。
跟外包团队打交道，本质上是人与人的博弈，也是信任的建立。合同不是为了这就准备打官司，而是为了定义底线，避免误会。把丑话说在前面，把该拿的东西握在手里，合作起来反而更顺畅。希望下次你再面对那一堆法律文件时，能心里有底，不慌不忙。
企业周边定制