如何撰写源代码所有权的自由职业合同

1. 确定确切的代码所有权结果

在你写下任何条款之前，决定客户实际上在购买什么。完全转让、许可或仅在最终付款后拥有并不是同一回事，合同应与您真正想要的商业安排相匹配。如果客户希望在第一天就拥有源代码，请明确说明。如果自由职业者在最后一张发票结清之前保留权利，也请说明。一句模糊的话会导致数月的摩擦。

这就是“如何为源代码所有权撰写自由职业合同”开始变得实际的地方。初创公司的创始人可能希望整个代码库被转移，而小型机构可能只需要一个广泛的许可来运行应用程序。这是不同的交易。混淆这些内容的合同可能会让双方都感到不满，且双方都无法得到充分保护。

使用合同来回答三个直接问题：谁拥有代码，所有权何时转移，以及客户是否可以修改或转售作品。如果答案是“在最终付款后”，请明确说明在付款结清之前不会发生转让。如果答案是“从创作开始的完全转让”，请清楚且毫无戏剧性地写出这一点。简短的句子在这里有帮助。

有关谨慎使用平台的良好比较，请参见 如何安全地雇佣自由职业者。那篇文章是关于明智选择人的；这篇文章是关于在选择他们之后将交易写下来。

2. 确定范围内的具体代码资产

不要让“源代码”作为一个让人感觉良好的短语随意流传。明确资产。如果项目包括应用代码、脚本、代码库、构建文件、部署配置、文档以及在项目期间创建的任何重构或衍生代码，请列出它们。仅仅说“代码”的合同会引发后续争议。两个词是不够的。

考虑文件夹和文件，而不是抽象。例如，范围可以涵盖主要应用程序代码库、单独的管理面板代码库、CI脚本、数据库迁移文件、API封装以及解释本地设置的README。如果自由职业者在项目期间创建了现有模块的修补版本，请决定该修补是否是交付物的一部分。这个细节很重要。

这里有一个简单的方式来框定范围：“为项目X创建的所有源代码和相关项目文件，包括在代码库A中编写的代码以及在本协议期限内产生的任何衍生或重构代码。”这句话并不华丽。它有效，因为它命名了地点、工作类型和时间窗口。

如果项目有多个代码库，请附上编号列表。一个代码库，一行。两个代码库，两行。合同不应强迫某人猜测移动应用程序包是否算作源代码或仅仅是导出的工件。

3. 添加明确的知识产权转让条款

知识产权转让条款是合同的核心。它应该说明自由职业者将创建的代码的所有权利、所有权和利益转让给客户。如果转让在创建时发生，请说明。如果在付款时发生，请改为说明。该条款不应依赖于隐含假设。

一个实用的条款可以这样写：“在根据本协议全额支付所有到期款项后，自由职业者将所有专门为客户在本项目下创建的交付物的知识产权转让给客户，但不包括附录A中列出的任何现有材料。”这样的措辞提供了转让点、付款条件和例外条款。三个活动部分，一句话。

一些合同还表示转让在全球范围内有效，并在保护的整个期限内有效，包括允许的续期和延长。这种语言很常见，因为软件可能存在多年，没有人希望在应用程序已经投入生产时重新谈判所有权。如果相关司法管辖区的法律期望更多细节，一行的转让可能太简单。

有关平台条款和规则的相关信息，24freelance.pro网站的规则。页面是有用的背景资料。它不会为您撰写条款，但它提醒您正式规则和合同语言不应相互冲突。

4. 分开现有工具、模板和可重用组件

自由职业者通常会带上自己的助手来工作。在项目开始之前，可能已经存在一个模板、一个自定义工具库、一个私有API封装或一个构建脚本。合同应保护这些先前存在的工作，同时仍然给予客户最终交付物的权利。如果没有这种区分，客户可能会认为自己购买了整个工具箱。

最清晰的方法是在附件或时间表中列出排除的材料。称其为时间表A、时间表B或附件1。列出自由职业者不转让的每一个先前存在的工具、模板或可重用组件。如果客户被允许在交付物中使用其中一个项目，请说明该使用是否在许可之下，以及该许可是独占的还是非独占的。小标签可以防止大争吵。

例如：一个自由职业者使用两年前创建的私有验证库构建支付流程。合同可以说明该库仍然归自由职业者所有，而客户获得一个永久许可，仅在交付的应用中嵌入使用该库。这保护了自由职业者的早期工作，同时仍然让客户拥有一个可用的产品。“拥有”和“许可”之间的界限需要清晰可见。

这是附件语言胜过模糊承诺的一个领域。如果自由职业者说：“我有一些可重用的代码，”这还不够。将名称放在时间表中。将例外写下来。将时间表编号放在正文中，以便没有人忘记稍后打开它。

5. 设置交付、仓库访问和交接要求

如果客户无法实际获取文件，所有权条款是不够的。合同应涵盖 Git 访问、提交历史、分支交接、凭证转移、文档以及在验收时交付所有最终源文件的声明。一个完善的法律条款很好；但缺少仓库密码就不好了。

明确交付的含义。自由职业者是否将最终代码推送到客户拥有的仓库？自由职业者是否提供完整项目的压缩档案？交接是否包括数据库架构说明、环境变量和部署步骤？如果项目依赖于私有服务账户，合同应说明这些凭证何时转移给客户或何时轮换。一个遗漏的令牌可能会延迟发布。

保持仓库条款具体。例如：“自由职业者将在交付日期之前授予客户对项目仓库的管理员访问权限，除非客户要求干净交接，否则将保留提交历史，并将所有用于生产工作的分支的控制权转移。”该语言在一个地方涵盖了访问、历史和分支所有权。如果客户想要一个单独的暂存分支，也要命名它。

良好的交接条款也能减少“我发送了一切”的争议。如果接受取决于最终源文件的交付，请说明这些文件是什么。如果最终文档包括设置说明，请列出它们。如果项目包括云部署，那么即使是该环境的凭据也可能需要一个单独的交接步骤，这就是 云计算技术 可以塑造交付的实际方面。

6. 包括保密、开源和第三方代码规则

当外部代码进入项目时，源代码所有权可能会迅速变得复杂。合同应限制未披露的库，要求对开源使用进行批准，并要求披露可能影响所有权的第三方组件或依赖项。如果自由职业者在一个限制商业使用的许可证下引入一个包，客户应该在发布之前知道，而不是在支持票到达后。

为开源材料设定规则。例如，自由职业者只能在客户书面批准的情况下使用开源代码，并且只有在许可证条款不与客户的所有权期望冲突的情况下。这意味着自由职业者必须识别项目中使用的任何GPL、LGPL、MIT、Apache或类似组件，并解释其实际影响。名称很重要。

第三方代码也应得到同样的诚实。付费的SDK、前雇主的脚本或从公共库复制的代码片段可能会使所有权变得复杂。合同应要求在包含任何此类组件之前进行披露。如果需要批准，请将批准过程作为一个步骤，而不是聊天消息。Slack中的一条消息很容易被遗忘。

保密性还应涵盖库内容、凭据、架构笔记和业务逻辑。这不仅仅是法律上的清理。看到构建过程或部署流程的竞争对手可能会获得超出客户意图分享的更多信息。如果项目涉及公共案例研究或作品集使用，合同应说明自由职业者是否可以在发布后展示截图。

7. 定义验收、付款和所有权转移的时机

所有权转移通常与付款相关。这是正常的。合同应说明是里程碑批准还是最终付款触发所有权转移，并应说明如果项目提前结束会发生什么。如果转移发生在验收时，请清楚地定义验收。如果在支付最终发票时发生转移，请用简单的英语写出该条件。

不要将时间安排留给记忆。条款可以规定，如果没有拒绝通知，交付物在书面批准后或在规定的审查期后被视为已接受。然后将所有权转移与该接受事件或在接受后收到付款联系起来。一个事件，一个结果。这样的结构可以防止每个人争论操作顺序。

提前终止需要自己的规则。假设客户在里程碑2之后取消。客户是否拥有已经支付的代码？自由职业者是否保留未完成模块的权利？客户是否获得使用部分工作的许可证，还是仅获得内部审查的副本？合同应在任何人开始编码之前回答这三个问题。

对于高风险项目，一些团队将付款与所有权分开。自由职业者可能在每个里程碑时收到部分付款，而完成代码的所有权仅在最后一个里程碑关闭后转移。这是可行的，但前提是合同解释部分付款的代码在项目期间是否被许可用于内部使用。如果答案是否定的，就说不。

8. 在发送合同之前添加一个准备签名的清单

在发送合同之前，运行一个清单。使用名称、路径和日期。项目名称、仓库位置、所有权条款、排除材料、交付义务以及任何需要针对特定司法管辖区语言进行的法律审查都应在内。如果其中一项缺失，请先修复它。匆忙的签名仍然是一个风险。

这里是一个实用的发送前清单：

• 项目名称与工作声明相匹配。
• 存储库位置通过 URL 或确切路径标识。
• 所有权条款说明何时转让。
• 排除的材料在时间表中列出。
• 交付义务提到源文件、文档和访问权限。
• 开源和第三方代码规则已写明。
• 验收和付款时间是相关联的。
• 特定于管辖区的语言经过法律审查。

如果合同是针对一个也重视公共声誉的团队，审查是有帮助的自由职业者评价在分配更多工作之前。合同可以保护代码所有权，但它并不能修复糟糕的交接习惯或反复错过的截止日期。两个保障总比一个好。

最后一个实用提示：如果项目与特定平台工作流程相关，合同不应与网站自身的操作规则、付款顺序或审批路径相冲突。这就是为什么许多客户在合同草稿旁边保留一个简短的内部检查清单。听起来很简单。简单是好的。