根据荷兰法律进行的软件托管

如果你的业务依赖于并非由你编写的软件，那么你就依赖于编写该软件的公司。你拥有目标代码和许可证；供应商则拥有源代码、构建流程和相关技术。当供应商偿付能力和资质良好时，这种不对称性尚可接受；但一旦供应商出现问题，这种不对称性便无法容忍。软件托管是标准的解决方案，但前提是必须按照荷兰破产法制定——而大多数协议并未遵循这一原则。

什么是第三方托管以及它能解决哪些风险

供应商将源代码和支持材料存放在独立的第三方机构，该机构负责保管这些材料，直到特定事件发生后才将其交付给客户。客户可以使用并修改代码，以确保软件持续运行。风险在于业务连续性，而非所有权：如果客户使用某个供应商的产品来处理订单、患者记录或进行生产计划，则无法在一夜之间完成切换，因为迁移需要数月时间，而且通常需要原供应商的协助。托管机制为有序退出提供了时间保障。以下三种情况尤为重要：

• 破产。 供应商被宣告破产，指定了破产管理人，员工离职，支持服务停止。这种情况需要设立第三方托管账户，而荷兰法律在此发挥了主要作用。
• 停止运营。 供应商撤回产品、停止支持您的版本，或者被一家对您的部署毫无兴趣的公司收购。这种情况比破产更常见，而且通常不在免责条款中。
• 持续维护失败。 供应商仍然存在，也仍然开具发票，但不再修复缺陷、发布安全补丁或保持产品与其依赖项的兼容性。

两方和三方安排

双边协议是指主合同中供应商承诺在特定事件发生时移交源代码。这种协议成本低廉但保障薄弱：没有人独立核查款项是否已存入或是否按时到账，而且——至关重要的是——一旦破产，你实际上是要求破产管理人履行其没有义务承担的财产义务。

三方安排中增加了一名第三方托管代理人作为合同方。代理人负责保管、核查定金、保管资金，并直接向您承担释放资金的义务。这正是支付托管费用的全部意义所在：资金释放由有偿付能力的第三方根据其自身合同履行，而非由破产财产管理人履行。代理人还负责决定资金释放事件是否发生，从而剥夺了受托人（他们没有动力帮助您）的这项权力。

实际沉积的是什么？

最常见的错误是代码不合法​​。它指的是只提交源代码，除此之外别无其他。单凭源代码无法编译：如果将庞大的代码库交给开发人员，却没有构建说明和依赖项列表，那么可能需要数周的逆向工程才能生成可运行的二进制文件——而对于已经停止支持的系统来说，你根本没有那么多时间。没有构建说明的代码库毫无价值。

增加更新义务。一次性支付的保证金会在一到两个版本周期内过期。将保证金与版本发布计划挂钩——例如每次主要版本发布或固定间隔——并赋予客户在保证金逾期时收到通知的权利。

验证：您所支付的费用包含哪些内容

建议购买下方中间选项作为标准配置，并进行全面测试，以应对可能造成生存危机的故障。仅进行文件级检查几乎等于没买。

• 文件级检查。 代理人确认存款文件可读、无病毒且与文件列表相符。这证明物品已送达，但并不能证明物品能够正常使用。
• 完整性及文件审核。 代理程序会将构建指令和依赖项与提交的文件进行比对，并报告任何不符之处。这种折衷方案适合大多数客户：它能以远低于完整测试的成本，捕获常见的错误——例如缺少构建步骤、依赖项文档缺失、使用了您无权使用的组件等等。
• 完整构建并运行测试。 代理程序在干净的环境下编译存款模型，并使用测试数据进行测试。这是唯一能够验证存款模型有效性的方法，但速度较慢、成本较高，并且由于软件会不断更新，因此需要重复执行。

发布会流程经过精心设计，不容任何争议。

解除条款是托管代理人在压力下且无法获得法律咨询时必须启动的机制。每一项事件都应能通过文件或时间推移来证实，而非仅凭对供应商行为的判断。

两点至关重要。首先，将举证责任放在供应商身上：客户向代理商提供证据，供应商在规定的短时间内提出异议，若供应商未提出异议，代理商则解除合同。其次，预先确定争议解决途径——专家裁定或短期仲裁——这样，异议只能争取几天时间，而不是几个月。

荷兰破产问题

以上内容均为合同设计。接下来的内容决定了供应商破产时合同是否仍然有效。

受托人可以拒绝

根据《破产法》第37条，如果在破产令颁布时，双方均未完全履行互惠合同，则对方当事人可以给予破产管理人一段合理的书面期限，以表明其是否履行合同；如果对方当事人未作出决定，则丧失要求对方履行合同的权利。但《破产法》第37条并未终止合同或赋予破产管理人终止合同的权力。合同仍然有效；破产管理人只是没有义务履行合同，而对方当事人仍然可以根据《破产法》第37a条在破产程序中享有债权。

对于软件而言，这意味着受托人可以拒绝维护、支持、更新、托管和后续充值：这些服务都会给遗产带来经济负担。做好被拒绝的准备。问题在于，受托人是否还能进一步阻止你使用你已有的软件。

Nebula、berzona 和 Credit Suisse/Jongepier

十年来，情况确实一直不明朗。在Nebula 案（荷兰最高法院，2006 年 11 月 3 日，ECLI:NL:HR:2006:AX8838）中，最高法院裁定，虽然破产本身并不终止现有协议，但持有使用权的交易对手方不能继续像破产从未发生一样，对破产管理人行使该权利；否则，将允许一方债权人无视破产，损害其他债权人的利益。这一裁决被广泛解读为允许破产管理人撤销先前存在的使用权，这令被许可方感到担忧。

这种解读并未被采纳。在ABN AMRO/Berzona案（荷兰最高法院，2014年7月11日，ECLI:NL:HR:2014:1681）中，最高法院裁定，破产对现有的互惠协议或由此产生的义务没有影响，并且破产管理人无权行使法律或合同未赋予的任何权力——例如，破产管理人无权终止仍在有效期内的租赁合同。

该立场已在Credit Suisse/Jongepier qq 案（荷兰高等法院，2018 年 3 月 23 日，ECLI:NL:HR:2018:424）中得到确立。破产管理人可以消极地拒绝履行义务，但破产并不赋予其撤销债务人在破产前已履行的义务的权力，也不赋予其终止持续履行义务（只要该履行义务包含容忍或不作为）的权力。

对于软件而言，这句话至关重要。许可协议实质上是权利人承诺容忍原本会侵犯版权的使用行为——一种持续的容忍行为。因此，根据现行法律，破产前有效授予的许可协议在破产后仍然有效，受托人无权撤销该协议。受托人可以拒绝所有已生效的许可协议，但不能终止您持有的使用权。

这对你的安排意味着什么

接下来有两点需要注意。首先，解除义务应由托管代理人而非供应商承担：由于托管是由第三方独立保管，解除义务即为代理人自身的履行，而根据《联邦财产法》第37条，受托人的权力适用于遗产所欠的款项，而非有偿付能力的代理人；而双边承诺则要求遗产履行，受托人可以拒绝履行。其次，应预先授予许可，而非在解除托管时授予——这是最重要的起草要点，下文将详细讨论。

在重组而非破产程序中，《破产法》第373条限制了对“当然终止条款”（ipso facto clauses）的依赖——该条款允许交易对手仅因重组程序启动而修改、中止或终止合同。这项限制适用于重组方案程序，而非破产程序，而解决之道同样在于结构性问题：如果安排是由第三方独立托管，则解除触发条件基于代理人自身的义务，并不构成可被撤销的“当然终止条款”，无论是在重组程序中还是在破产程序中。

许可证的结构应该如何安排

托管服务提供的是源代码副本，而非任何使用权。源代码是受保护的作品；编译、修改和运行源代码均属受限行为。如果没有相应的许可，已交付的托管文件就如同一个您无法打开的文件夹。因此，应将托管服务与一份明确允许客户在交付后使用、编译、修改和进一步开发源代码的许可协议结合使用，并允许第三方完成这些工作——实际上，您自己无需进行任何操作。

接下来是时机问题。在破产程序结束后获得的许可非常脆弱。如果破产本身就是破产事件，那么许可必须由债务人本人授予，而债务人自破产令颁布之日起就失去了处置破产财产的权力；《破产法》第23条和第35条对此构成障碍，受托人不会为您授予许可。瑞士信贷/Jongepier案意味着受托人不能撤销您已经拥有的许可——但如果您从未拥有过许可，也就无从撤销。

在合同本身中，于破产发生之前授予该权利，但须附加先决条件：该权利即刻授予，并在债务解除事件发生时生效。该权利自合同签订之日起即已存在，仅其效力被延后。荷兰法律通常认可这种结构。在Rabobank/Reuser 案（荷兰最高法院，2016 年 6 月 3 日，ECLI:NL:HR:2016:1046）中，荷兰最高法院认可，如果一项附条件权利在破产前已设立，则该条件的履行在破产后无需债务人采取任何进一步行动即可生效。该案涉及有条件的货物转让以及对该附条件权利的质押。将其应用于有条件授予的版权许可，是一种法律文献支持的推断，而非法院判例所确立的原则，应如此表述。

还要确认，使用已发布的材料无需供应商或其受托人的进一步同意，并且允许将材料再许可给后续开发者。

SaaS 和云计算：源代码还不够。

对于自行运行的软件，源代码、构建说明和许可证几乎就构成了一个完整的解决方案。但对于服务而言，这远远不够。如果供应商的平台宕机，您将丢失应用程序、其运行环境以及所有数据——而源代码只能缓慢地恢复应用程序。SaaS 连续性方案必须包含以下三点：

• 运行环境。 容器镜像、基础设施即代码定义、配置、网络和安全设置、运行时依赖项——足以在其他地方搭建该平台。
• 数据。 定期以文档化、非专有格式导出您自己的数据，并保留数据模式。您无法读取的数据不属于您拥有的数据，导出操作应贯穿整个合同期，而不仅仅是在发布时。
• 主办关系。 进入供应商与其托管服务提供商之间的合同，或者通知该服务提供商您可以接管帐户并直接付款。

替代方案，以及谁来支付费用

托管并非总是最佳选择，尤其对于标准产品而言，您只是成千上万个客户中的一个，实际风险在于服务终止而非彻底失败。以下三种更轻量级的方案往往更为实用：数据导出权——定期以文档化格式导出数据，并至少进行一次测试——几乎零成本地覆盖大部分风险；运行副本权——一个可部署的镜像，您可以在过渡期内运行，恢复服务的速度远超重建；以及直接向托管服务提供商付款，在迁移过程中保持环境运行——这是成本最低的云服务连续性方案，却也最常被忽视。

如果您使用第三方托管服务，预计会收取一次性设置费、年度托管费，以及每次核实的额外费用，费用会根据核查的深度而定。费用通常由需要保障的一方承担，通常是客户；不过，如果供应商将第三方托管作为卖点，则可能会自行承担费用；而涉及多个客户购买同一产品的多受益人安排则会分摊费用——这通常是供应商不愿接受第三方托管服务的原因。务必规定，如果发生未付款情况，代理人必须通知您，并有权代为支付。

协商托管安排的核对清单

• 这是真正的三方协议，其中独立代理人对您负有直接解除责任的义务吗？
• 是否授予使用、编译、修改和进一步开发源代码的许可 现在是在满足先决条件的前提下，而不是在发布时就承诺？
• 交付清单是否包含构建说明、依赖项、许可证密钥和文档（而不仅仅是源代码），并且每次发布时都进行更新？
• 合同约定的验证级别是什么？验证频率如何？
• 发布事件能否通过文件或时间推移来确定，并设有较短的异议期和快速的争议解决途径？
• 对于 SaaS 服务：是否涵盖环境、数据和托管关系，还是仅涵盖代码？
• 谁来付款？如果供应商停止付款会发生什么？托管协议是否符合主合同的适用法律和知识产权条款？