オランダ法に基づくソフトウェアエスクロー

もしあなたのビジネスが、あなたが開発していないソフトウェアに依存しているなら、あなたはそれを開発した会社に依存していることになります。あなたはオブジェクトコードとライセンスを保有していますが、サプライヤーはソースコード、ビルドパイプライン、そしてノウハウを保有しています。この非対称性は、サプライヤーが支払い能力と能力を備えている間は許容できますが、そうでない瞬間に許容できなくなります。ソフトウェアエスクローは標準的な解決策ですが、オランダの倒産法を念頭に置いて作成された場合にのみ有効であり、ほとんどの契約はそうではありません。

エスクローとは何か、そしてそれが対処するリスクとは何か

サプライヤーはソースコードと関連資料を独立した第三者に預け、第三者は特定のイベントが発生するまでそれらを保管し、その後顧客に引き渡します。顧客はソフトウェアを稼働させ続けるためにコードを使用および変更できます。リスクは所有権ではなく継続性です。注文処理、患者記録、または生産計画をあるサプライヤーの製品で実行している顧客は、移行に数か月かかり、通常は既存のサプライヤーの協力が必要となるため、一夜にして切り替えることはできません。エスクローは、秩序ある方法で撤退するための時間を確保します。次の3つの状況が重要です。

• 倒産。 供給業者が破産宣告を受け、管財人が選任され、従業員が退職し、サポートが停止する。これはエスクロー制度が想定しているシナリオであり、オランダ法が最も効果を発揮する場面である。
• 中止。 サプライヤーが製品を撤回したり、あなたのバージョンをサポート終了にしたり、あるいはあなたの導入に関心のない企業に買収されたりするケース。倒産よりもよくあるケースであり、免責条項から除外されることが多い。
• 維持管理の継続的な失敗。 供給業者は今も存在し、請求書も発行しているが、欠陥の修正、セキュリティパッチの配布、製品の依存関係との互換性の維持はもはや行っていない。

二者間協定および三者間協定

二者間契約とは、特定の事象が発生した場合に供給者がソースコードを引き渡すことを主契約で約束するものです。これは安価で脆弱です。誰も独立して、実際にコードが預けられたか、最新の状態に保たれているかを確認することはなく、そして決定的に重要なのは、破産時に管財人に財産の義務を履行するよう求めることになり、管財人にはその義務がないということです。

三者間契約では、エスクロー代理人が契約当事者として加わります。代理人は預託金を預かり、確認し、保管し、あなたに直接その預託金を返還する義務を負います。これが、代理人に費用を支払う最大の理由です。つまり、預託金の返還は、破産財団ではなく、支払い能力のある第三者が自身の契約に基づいて履行することになるのです。また、代理人は返還事由が発生したかどうかも判断するため、あなたを助けるインセンティブのない管財人がその判断を下す必要がなくなります。

実際に預金されるもの

最もよくある失敗は、法的問題ではありません。それは、ソースコードのみを含む預託物です。ソースコードだけではコンパイルできません。ビルド手順や依存関係リストがない状態で開発者に渡された場合、大規模なコードベースでは、実行可能なバイナリを生成するまでに数週間のリバースエンジニアリングが必要になる可能性があります。システムが既にサポート対象外となっている場合、そんな時間はありません。ビルド手順のない預託物は無価値です。

更新義務を追加する。署名時に一度支払われた保証金は、1～2回のリリースサイクルで期限切れとなる。保証金をリリーススケジュール（主要なリリースごと、または一定の間隔）に連動させ、支払いが遅れた場合は通知を受ける権利を設ける。

検証：あなたが支払っているもの

標準オプションとして下記の真ん中のオプションを購入し、システム障害が発生した場合に事業継続が不可能となるような完全なテストを実施してください。ファイルレベルのチェックだけでは、ほとんど意味がありません。

• ファイルレベルのチェック。 担当者は、入金されたデータが読み取り可能で、ウイルスに感染しておらず、ファイルリストと一致していることを確認します。これはデータが到着したことを証明するものであり、正常に動作することを保証するものではありません。
• 完全性と文書レビュー。 エージェントは、ビルド手順と依存関係をデポジットと照合し、不備を報告します。この中間的なオプションは、ほとんどのお客様に適しています。ビルド手順の欠落、ドキュメント化されていない依存関係、使用権限のないコンポーネントなど、よくある不具合を、本格的なテストのわずかなコストで検出できます。
• 完全なビルドと実行テスト。 エージェントはクリーンな環境でデポジットをコンパイルし、テストデータに対して実行します。これはデポジットが正しく機能することを証明できる唯一の段階ですが、処理速度が遅く、コストも高く、ソフトウェアの変更に伴って繰り返し実行する必要があります。

リリースイベントは、議論の余地がないように作成されている。

解除条項は、エスクロー代理人が法的助言なしに、プレッシャーの下で適用しなければならないトリガーです。すべての事象は、供給者の行為に関する判断ではなく、文書または時間の経過によって立証できるものでなければなりません。

主な解決策は2点です。まず、矛盾が生じた場合の責任を供給業者に負わせることです。顧客は証拠を添えて代理店に通知し、供給業者は短期間の固定期間内に異議を申し立てる必要があります。異議申し立てがなければ、代理店は契約を解除します。次に、紛争解決の手続きを事前に定めておくことです。専門家による裁定または短期間の仲裁を選択することで、異議申し立てによって数ヶ月ではなく数日の猶予が得られます。

オランダの倒産問題

上記はすべて契約書の設計に関するものです。以下は、供給業者が倒産した場合に契約が有効となるかどうかを規定するものです。

受託者が拒否できるもの

破産法第37条に基づき、破産宣告時にいずれの当事者も相互契約を完全に履行していない場合、相手方は管財人に対し、履行するか否かを表明する合理的な書面による期間を設定することができる。相手方が表明しない場合、相手方は履行を要求する権利を失う。破産法第37条は、契約を終了させることも、管財人に終了させる権限を与えることも規定していない。契約は存続し、管財人は単に履行義務を負わないだけであり、相手方は破産法第37条aに基づき破産における債権を有することになる。

ソフトウェアの場合、これは受託者が保守、サポート、アップデート、ホスティング、および追加の預託金を拒否できることを意味します。これらは遺産から費用が発生する積極的なサービスです。拒否されることは覚悟しておきましょう。問題は、受託者がさらに踏み込んで、既に所有しているソフトウェアの使用を停止できるかどうかです。

ネビュラ、ベルゾナ、クレディ・スイス/ヨンゲピアー

10年間、この点は本当に不確実だった。ネビュラ事件（最高裁判所、2006年11月3日、ECLI:NL:HR:2006:AX8838）において、最高裁判所は、破産自体は既存の契約を終了させるものではないものの、使用権を有する相手方は、破産がなかったかのように管財人に対して使用権を行使し続けることはできないと判示した。これは、ある債権者が他の債権者を犠牲にして破産を無視することを許すことになるからである。この判例は、管財人が既存の使用権を無効にできると広く解釈され、ライセンシーを不安にさせた。

その解釈は定着しなかった。ABN AMRO/Berzona事件（最高裁判所、2014年7月11日、ECLI:NL:HR:2014:1681）において、最高裁判所は、破産は既存の相互協定やそこから生じる義務に影響を与えず、法律や契約で認められていない権限を管財人に与えるものではないと判示した。例えば、管財人はまだ有効なリース契約を解除することはできない。

この件については、Credit Suisse/Jongepier qq (Hoge Raad、2018年3月23日、ECLI:NL:HR:2018:424) で解決済みである。管財人は受動的に履行を拒否することはできるが、破産は、破産前に債務者が行った履行を取り消す権限、または何かを容認したり控えたりする継続的な履行を終了させる権限を管財人に与えるものではない。

ソフトウェアにとって重要なのは、まさにそのフレーズです。ライセンスとは、本質的には、著作権を侵害する可能性のある使用を権利者が容認するという約束、つまり容認という継続的な履行を意味します。したがって、現行法では、破産前に有効に付与されたライセンスは破産後も存続し、管財人はそれを取り消すことはできません。管財人は有効なものをすべて拒否することはできますが、あなたが保有する使用権を無効にすることはできません。

それはあなたの契約にとって何を意味するのか

2つの点が重要になります。まず、解除義務は供給者ではなくエスクロー代理人に負わせることです。第三者が保有する独立した保管として設定されている場合、解除は代理人自身の履行となり、第37条Fwに基づく受託者の権限は、支払い能力のある代理人ではなく、遺産が負う履行に及ぶことになります。一方、二者間の約束は遺産による履行を必要とし、受託者はこれを拒否することができます。次に、ライセンスは解除時ではなく、事前に付与すること。これは最も重要な起草上のポイントであり、後述します。

破産ではなく再建手続きにおいては、第373条Fwは、再建手続きが開始されたという理由だけで相手方が契約を修正、停止、または終了できるという規定である、当然解除条項への依拠を制限している。この制限は再建手続きにおいて適用され、破産においては適用されない。そして、その解決策はやはり構造的なものである。すなわち、第三者による独立した保管として取り決めが作成された場合には、解除のトリガーは代理人自身の義務に基づいて作動し、WHOA再建手続きにおいても破産手続きにおいても、取り消し可能な当然解除条項には当たらない。

ライセンスの構成方法

エスクローはソースコードのコピーを提供するものであり、それを使って何かをする権利を与えるものではありません。ソースコードは著作権で保護された著作物であり、コンパイル、修正、実行は制限された行為です。ライセンスがなければ、公開された預託物は開けることができないフォルダのようなものです。エスクローには、顧客がソースコードの使用、コンパイル、修正、およびさらなる開発を、公開時に第三者に委託することを明示的に許可するライセンスを併せて締結してください。実際には、顧客自身が作業を行う必要はありません。

次に、タイミングの問題です。免責時に付与されるライセンスは不安定です。免責事由が破産そのものである場合、ライセンスの付与は、破産宣告の日から財産の処分権を失った債務者によって行われなければなりません。破産法第23条および第35条がこれを阻み、管財人はあなたのためにライセンスを付与しません。Credit Suisse/Jongepier判例は、管財人が既に取得したライセンスを取り消すことはできないことを意味しますが、そもそもライセンスを取得したことがなければ、取り消すものはありません。

破産前に契約書自体の中で、条件付き権利を付与し、その条件は「現在付与され、解除事由が発生した時点で効力を生じる」とする。権利は契約締結日から存在し、効力発生が延期されるだけである。オランダ法は一般的にこの構造を受け入れている。Rabobank /Reuser事件（最高裁判所、2016年6月3日、ECLI:NL:HR:2016:1046）において、最高裁判所は、条件付き権利が破産前に設定されていた場合、その後条件が満たされれば、債務者による更なる行為なしに効力を生じることを認めた。この事件は、条件付き物品譲渡と、条件付き権利に対する質権に関するものであった。これを条件付きで付与された著作権ライセンスに適用することは、裁判所によって確定された論点というよりは、法学文献で支持されている推論であり、そのように提示されるべきである。

また、公開された資料の使用には、供給者またはその受託者からの更なる同意は不要であり、後継開発者へのサブライセンスが許可されていることを確認してください。

SaaSとクラウド：ソースコードだけでは不十分

自分で実行するソフトウェアの場合、ソースコード、ビルド手順、ライセンスがあればほぼ完全な解決策となります。しかし、サービスの場合はそうではありません。サプライヤーのプラットフォームが停止すると、アプリケーション、実行環境、そしてデータが失われます。ソースコードから復元できるのは最初のものだけで、しかも復元には時間がかかります。SaaSの継続性確保には、次の3つの要素を追加する必要があります。

• 運用環境。 コンテナイメージ、インフラストラクチャ・アズ・コードの定義、構成、ネットワークおよびセキュリティ設定、ランタイム依存関係など、プラットフォームを他の場所で立ち上げるのに十分な情報。
• データ。 スキーマを含む、文書化された非独占的な形式で、自社データを定期的にエクスポートしてください。読み取れないデータは、所有しているデータとは言えません。エクスポートは、リリース時だけでなく、契約期間全体を通して実行されるべきです。
• ホスティング関係。 サプライヤーとホスティングプロバイダーとの契約に介入する方法、またはプロバイダーに対してアカウントを引き継いで直接支払う可能性があることを通知する方法。

代替案、そして誰が支払うのか

エスクローは必ずしも最良の選択肢とは限りません。特に、何千もの顧客のうちの1人であり、現実的なリスクがサービス終了であって失敗ではないような標準的な製品の場合はなおさらです。より手軽な3つの選択肢の方が多くの場合便利です。1つ目は、データ出口権（文書化された形式で定期的にエクスポートし、少なくとも1回はテストする）で、ほとんどコストをかけずにリスクの大部分をカバーできます。2つ目は、実行中のコピーの権利（移行期間中に実行できるデプロイ可能なイメージで、再構築よりもはるかに迅速にサービスを復旧できます）。3つ目は、ホスティングプロバイダーへの直接支払いで、移行中も環境を稼働させ続ける方法です。これは最も安価なクラウド継続性であり、最も見落とされがちな方法です。

エスクローを利用する場合は、初期設定手数料、年間保管手数料、および小切手の金額に応じて変動する検証ごとの手数料が発生することを想定してください。費用は保護を希望する者（通常は顧客）が負担しますが、エスクローをセールスポイントとして提供するサプライヤーが負担する場合もあります。また、1つの製品の複数の顧客を対象とする複数受益者契約では費用が分散されますが、これはサプライヤーが抵抗する典型的なケースです。支払いが滞った場合は、代理人があなたに通知し、代わりに支払う権利をあなたに与えるようにしてください。

エスクロー契約交渉のためのチェックリスト

• それは、あなたに対して直接的な免責義務を負う独立代理人を含む、真の三者間契約ですか？
• ソースコードの使用、コンパイル、変更、およびさらなる開発のライセンスは付与されていますか？ 今リリース時に約束するのではなく、前提条件付きで提供されるということでしょうか？
• リポジトリリストには、ソースコードだけでなく、ビルド手順、依存関係、ライセンスキー、ドキュメントも含まれており、リリースごとに更新されますか？
• 契約されている検証レベルはどの程度で、どのくらいの頻度で繰り返されますか？
• リリースイベントは、文書または時間の経過によって判断可能であり、異議申し立て期間が短く、迅速な紛争解決経路が確保されているか？
• SaaSの場合、環境、データ、ホスティング関係も対象となりますか、それともコードのみですか？
• 誰が支払うのか、供給業者が支払いを停止した場合どうなるのか、そしてエスクロー契約は主契約の準拠法および知的財産権条項に適合しているのか？