オランダ法およびEU法に基づくオープンソースソフトウェアライセンス

ほぼすべての商用ソフトウェア製品には、開発者が弁護士ではなく選定した数百ものオープンソースコンポーネントが含まれています。どのライセンスが適用されるのか、ライセンスの内容は何か、製品がそれらの要件を満たしているかどうかが誰にも分からない場合、問題が生じます。この記事では、オランダ法およびEU法におけるオープンソースライセンスの仕組み、リスクの所在、そして必要な対策について解説します。

オープンソースライセンスとは、法律用語で言うとどのようなものか？

オープンソースライセンスは、条件付きで付与される著作権ライセンスです。権利放棄でも、パブリックドメインへの提供でも、権利の放棄でもなく、その点ではオランダ法に基づく他のソフトウェアライセンスと同様です。著作者は、コンピュータプログラムを著作物として保護するオランダ法第1条および第10条に基づき著作権を保持し、このライセンスは、そうでなければオランダ法第12条および第13条に基づく排他的権利を侵害する行為を許可します。

定義よりも結果が重要です。ルールを遵守すれば、複製と配布は合法です。ルールを遵守しなければ、許可は適用されず、使用は契約違反ではなく著作権侵害となります。ほとんどのコピーレフトライセンスは、違反があった場合に自動的に終了することでこの点を強化しています。GPLv2は是正期間を設けず、GPLv3とAGPLv3は、通知後一定期間内に違反が是正されれば権利を回復します。

オランダの裁判所はこの論理を適用します。Rb. Amsterdam 2020年9月22日、ECLI:NL:RBAMS:2020:4717において、フォークしたコードベースからライセンス条項と著作権表示を削除したディストリビューターは、許可を失い、著作権を侵害していると判断されました。大量の新しいコードを追加しても、独立した著作物が作成されたわけではなく、元のコードが認識可能な形で残っているため、義務もそれと共に引き継がれるとされました。

2つの家族：寛容型とコピーレフト型

MITライセンス、BSDライセンス、Apache 2.0などの寛容なライセンスは、著作権表示とライセンス条項を保持することを条件に、クローズドソース製品内を含め、使用、変更、再配布を許可します。

コピーレフトライセンスでは、ソフトウェアまたはそれを基に作成されたものを配布する際に、同じライセンスの下で配布し、対応するソースコードを公開することが義務付けられています。両者は適用範囲が異なります。

コピーレフトのトリガーとリンクに関する問題

コピーレフトの義務は配布時に適用され、使用時には適用されません。GPLソフトウェアを社内で運用している企業は、たとえ大幅に改変したとしても、何も配布しておらず、何の義務も負っていません。「配布したことがあるか？」が常に最初の質問であり、だからこそコンテナ、アプライアンス、ファームウェア、SDKは社内ツールよりも重要なのです。

2つ目の問題はより難しい。GPLは「プログラムに基づく著作物」という表現を用い、アメリカの派生著作物の概念を取り入れている。オランダの法律にはそのような用語はなく、複製権と翻案権を検証し、オリジナル作品から保護された表現が複製されたかどうかを問うことになる。

実務上の問題はリンクです。プロプライエタリなモジュールをGPLライブラリにリンクすることで、コピーレフトの対象となる単一の著作物が作成されるかどうかは、オランダの裁判所で判断されたことはなく、EUにも拘束力のある判例はありません。リンクによって結合された著作物が作成されるというフリーソフトウェア財団の見解は、ライセンス管理者の解釈であって法律ではなく、反対の見解も同様に検証されていません。インターネットでよく見られる「動的リンクは安全、静的リンクは危険」という回答は、コンパイラの動作を問わないオランダの著作権法には根拠がありません。より妥当な分析は、コンポーネントがどれほど密接に結合されているかを問うものです。つまり、アドレス空間やデータ構造を共有しているか、結合されたコンポーネントが単一の製品として出荷されているか、どちらかが単独で機能できるか、プロプライエタリ側がコピーレフト側からヘッダー、マクロ、またはインラインコードを複製しているか、といった点です。これらの質問は通常、リスクを解消します。解決しない場合は、コンポーネントをプロセス境界の背後に隔離するか、置き換えるか、商用ライセンスを取得する必要があります。

AGPLとネットワークの使用

AGPLが存在する理由は、コピーレフトは配布によって発動されるものであり、SaaSプロバイダーは配布を行わないためです。そのネットワーク条項では、ソフトウェアを改変してリモートで操作するユーザーに提供する場合、改変版のソースコードをユーザーに提供することが義務付けられています。

よく見落とされがちな点が3つあります。まず、この義務はサービスの利用者に及ぶため、オープンサインアップ型の製品ではほとんど意味がありません。次に、変更によって義務が発生するため、変更されていないコンポーネントでは適用されませんが、パッチが適用されたビルドでは適用される可能性があります。そして、スタック全体のGPLと同様に、共同作業の問題が生じます。これが、多くの企業が本番コードでのAGPLの使用を禁止している理由です。

ライセンスの互換性

互換性とは、ライセンスによって義務が課せられているコンポーネントを、1つの配布物で両方を満たすことができない場合に、それらを組み合わせようとする問題です。寛容なライセンスはほぼすべてのものと互換性がありますが、コピーレフトライセンスは、そのライセンス条項で許可されているものとのみ互換性があります。典型的な例は、Apache 2.0とGPLv2です。Apache Software FoundationとFree Software Foundationは、Apache 2.0の特許終了条項と補償条項はGPLv2では認められていない追加の制限であるため、この組み合わせは許可されていないという点で一致しています。GPLv3は、これらの条項を受け入れるように作成されました。互換性には方向性もあります。ApacheのコードはGPLv3プロジェクトに取り込むことができますが、その逆はできません。GPLコンポーネントが間違った場所にあると、ライセンスの変更、再設計、または削除のいずれかを選択せざるを得なくなる可能性があります。リリース前に行う方が、リリース後よりもはるかに安価です。

帰属表示および通知義務

最も頻繁に違反される義務は、最も些細なものです。それは、配布物に付属する資料に著作権表示、ライセンス条項、免責事項、そしてApache 2.0ライセンスの場合はNOTICEの内容を記載することです。MITライセンスやBSDライセンスを含め、どのライセンスファミリーもこれらの義務を課しています。これらの義務が違反されるのは、所有者が不明確であるためであり、修正も最も簡単です。通常は、製品に同梱される帰属表示ファイルを生成することで解決できます。上記のオランダの事例は、まさにこの不備が原因となっています。

特許付与と特許報復

MITライセンスとBSDライセンスは特許について何も規定しておらず、特許ライセンスが黙示的に認められるかどうかは未解決である。Apache 2.0は、各貢献者からの明示的な無償特許ライセンスを追加し、報復条項を併記した。すなわち、作品が特許を侵害しているとして訴訟を起こせば、特許ライセンスは終了するという条項である。GPLv3も同様の許諾と独自の特許条項を含んでいる。

特許ポートフォリオを持つ企業にとって、2つの重要な意味合いがあります。エンジニアがApacheライセンスまたはGPLv3ライセンスのプロジェクトに貢献している場合、自社の特許に基づいてライセンスを付与していることになります。また、自社が使用しているApacheライセンスのコンポーネントに依存している企業に対して特許を主張した場合、報復措置によって、依存しているライセンスを失う可能性があります。

EUPLとオランダの公共部門

欧州委員会が2017年5月に実施決定によって承認した欧州連合パブリックライセンスバージョン1.2は、OSIが承認したコピーレフトライセンスであり、3つの特徴があります。

• 言語。 EUの公用語で存在し、承認されたすべてのバージョンは同一の効力を持つため、オランダ当局はオランダ語で契約を結ぶことができる。
• 適合。 付録には、互換性のあるライセンス（GPLv2およびv3、AGPLv3、LGPL、MPL 2、EPL 1.0、OSL、CeCILLなど）が一覧表示されており、EUPLコードと一覧に挙げられたライセンスに基づくコードを組み合わせた派生作品を、代わりにそのライセンスの下で配布することが認められています。
• リーチ。 その定義する配布には、作品をオンラインまたはオフラインで利用可能にすることが含まれる。 または、その必須機能へのアクセスを提供するEUPL第5条は、同じ機能が提供されるリモートインタラクションにもコピーレフトの義務を適用します。したがって、GPLとは異なり、サービスとして提供されるソフトウェアにも適用されます。

オランダの公共部門の顧客は、法令ではなく政策上の理由からEUPLを要求する場合があります。欧州相互運用法（規則（EU）2024/903）は、公共部門の機関に対し、同等の場合にはオープンソースなど、制限的なライセンス条件のない相互運用ソリューションを優先するよう指示しています。国内では、オープンソースの原則は法令ではなく、閣議決定と政策方針に基づいています。デジタル法はデジタルIDインフラストラクチャを促進しますが、すべてのソースコードを公開する強制力のある義務を課していません。入札書類をよく読んでください。EUPLの要件は納品物を拘束し、再利用を意図していた独自のコードと互換性がない場合があります。

実際の執行

誰が訴訟を起こせるのか。権利保有者、つまり個々の貢献者、または譲渡された著作権を保有する財団や企業である。断片的な著作権が実際的な障害となる。つまり、原告は問題となっているコードの所有権を証明しなければならない。この点が、最も有名な欧州GPL訴訟で、カーネル開発者が仮想化ベンダーに対して起こした訴訟で、著作権の証明が不十分であったために敗訴した事例である（ハンブルク地方裁判所、2016年7月8日、310 O 89/15；ハンブルク高等裁判所、2019年2月28日、5 U 146/16で支持）。

判例法が確立していること。ドイツの裁判所は、最初のGPL差止命令（LG München I 19 May 2004, 21 O 6123/04）以来、オープンソースライセンスが有効であり、違反すると配布が違法になることを繰り返し認めてきた。米国連邦巡回控訴裁判所も、Jacobsen v Katzer 535 F.3d 1373 (Fed. Cir. 2008) で同じ結論に達した。ライセンス条項は、単なる契約ではなく、付与の範囲に関する条件であるため、違反は著作権侵害の主張と差止命令による救済を裏付ける。米国の訴訟では、下流の受領者が第三者受益者としてGPLを執行できるかどうかが検討されている。カリフォルニア州上級裁判所におけるSoftware Freedom Conservancy v Vizioの中心的な問題は、消費者が第三者受益者としてGPLv2に基づいてソースコードの公開を要求できるかどうかである。 2025年12月23日、裁判所は略式判決で1つの論点を決定し、GPLv2とLGPLv2.1は、デバイスに機能を損なうことなく再インストールできるソースコードではなく、入手して他の場所で使用できるように改変できるソースコードを要求すると判断した。第三者受益者の問題自体は、複数回延期された裁判官審理に残された。いずれにせよ、これはカリフォルニア州の契約法の問題であるため、オランダでは拘束力を持たない。変更されるのは、苦情を申し立てることができる人の数である。

オランダの裁判所がどのように対処するか。著作権法（Auteurswet）に基づく著作権侵害の場合、原告は所有権と複製または伝達を立証し、被告はライセンスを主張する。原告はライセンスの条件が満たされていないと反論し、被告の抗弁は棄却される。民法第6条265項に基づく契約上の救済措置も並行して存在するが、著作権の方がより強力な手段となる。

救済措置。通常は罰金支払いを伴う、略式手続きで可能な、民法第3:296条に基づく差止命令。第27条に基づく損害賠償、第27条に基づく利益の返還。第28条に基づく回収、返還または破棄。第1019h条に基づく合理的かつ比例的な訴訟費用の全額回収。ソフトウェアが無償で配布された場合、損失を定量化することは困難であり、ドイツの控訴裁判所は差止命令を支持しつつ損害賠償を認めなかった（OLG Hamm 2017年6月13日、4 U 72/16）。問題となるのは損害賠償ではなく、差止命令、回収、費用命令、そして公開するつもりのなかったソースを公開しなければならないことである。

コンプライアンス上の問題を発見した場合

発見は通常、顧客のセキュリティ質問票、デューデリジェンス中のスキャン、または権利者からの書簡によって行われます。その後、修復は次のように実行されます。深刻なリスクがある場合は、影響を受けるビルドの配布を停止します。どのコンポーネント、どのバージョン、どのライセンス、どの製品とリリース、どの期間に影響があったかを特定します。ライセンスが実際に何を要求しているかを調べます。多くの場合、ソースリリースではなく帰属ファイルが必要です。通知、ライセンステキスト、ビルドスクリプトを含む完全な対応するソース、および使用された場合の書面によるオファーなどの成果物を準備します。準拠したリリースを出荷し、権利者に対して、実行した内容を伝え、実行する必要があったかどうかについて議論しないようにします。

GPLv3およびAGPLv3では、是正期間が設けられることで迅速な法的価値が認められますが、GPLv2では是正権がないため、ほとんどの執行は交渉による遵守の約束で終わります。また、弁護士からの助言には特権が適用されるのであって、社内技術報告書には適用されない点にも注意してください。

M&Aおよびデューデリジェンスにおけるオープンソース

ソフトウェア買収において、オープンソースは標準的なデューデリジェンスの作業工程であり、コア製品に未公開のコピーレフト要素が含まれていることは、取引を実際に前進させる数少ない発見の一つである。つまり、ソースコードを公開せずに製品を配布できない場合、買い手は提示価格とは異なる資産を取得することになる。

コードベースのスキャン、ライセンスを含むコンポーネント一覧、貢献者および請負業者との契約に関する質問などが予想されます。典型的な結果としては、特定の補償、是正措置が完了するまでの保留、削除を必要とする前提条件、または特注のオープンソース保証などが挙げられます。売り手はまずスキャンを行うべきです。売り手が開示する調査結果は交渉材料となり、買い手の顧問が行う調査結果は交渉材料となります。買い手は「会社が知的財産権を所有している」という主張ではなく、独自のソースコードの開示を必要とするオープンソースを組み込んだ製品が存在しないという表明を求めるべきです。

部品表、スキャン、サイバーレジリエンス法

ソフトウェア部品表とは、製品の構成部品とそのバージョンおよびライセンスを一覧にしたものです。つい最近まで純粋に契約上の要件でしたが、現在では規制上の要件にもなっています。

サイバーレジリエンス法（規則（EU）2024/2847）は、2024年12月10日に発効し、段階的に施行される。これは、製品ではなく組織を対象とするオランダのサイバーセキュリティ法と並行して存在する。サイバーレジリエンス法第14条に規定される、悪用された脆弱性および重大なインシデントに関する報告義務は、2026年9月11日から適用される。適合性評価機関への通知に関する規定は、2026年6月11日から適用される。規則全体は、2027年12月11日から適用される（サイバーレジリエンス法第71条）。サイバーレジリエンス法附属書Iでは、製造業者に対し、製品の構成要素を特定し文書化することを求めており、これには、少なくとも最上位の依存関係を網羅した、一般的に使用され機械可読な形式のソフトウェア部品表を作成することが含まれる。公開する必要はないが、市場監視当局が要求する可能性がある。

商業活動以外で提供されるフリーソフトウェアおよびオープンソースソフトウェアは、CRA の対象外です。規則では、商業活動を目的としたオープンソースソフトウェアの開発を継続的にサポートする法人であるオープンソースソフトウェア管理者を導入し、CRA 第 24 条でより軽い義務を課しています。文書化されたサイバーセキュリティ ポリシー、市場監視当局との協力、および報告です。オープンソースを商業化する場合、または他者が商業化するプロジェクトに資金を提供する場合は、自分がどの役割を担っているかを明確にしてください。欧州委員会は、2026 年 7 月 27 日に最初のガイダンスを採択しました。これは、通信 C(2026) 5252 に付属するサイバーレジリエンス法 (CRA) の適用に関する欧州委員会ガイダンスであり、フリーソフトウェアおよびオープンソースソフトウェアがいつ範囲に含まれるかなどを扱っています。ソフトウェア部品表のフォーマットを規定する実施法は採択されていないため、規則独自の標準 (一般的に使用されている機械可読フォーマット) が当面の間、基準となります。

CI（継続的インテグレーション）で実行されるソフトウェア構成分析は、コンプライアンス、ライセンスレビュー、デューデリジェンスに同時に役立つインベントリを生成します。このようなツールは、ベンダー提供のコードを見落としたり、デュアルライセンスのプロジェクトを誤って識別したり、ライセンス条件を読み取ったりすることができません。そのため、出力はレビューの開始点として扱い、レビューの完了とはみなさないでください。

独自のコードを公開する場合：CLAsとDCO

コードを公開し、外部からの貢献を受け入れる企業は、統合するコードに対する権利を確実に保有していなければなりません。貢献者ライセンス契約は、プロジェクトと貢献者間の契約であり、通常は広範な著作権ライセンスと明示的な特許ライセンスを付与し、独創性と権限に関する保証を付記します。これにより、企業は後日プロジェクトのライセンスを再設定したり、オープンソースライセンスと並行して商用ライセンスを提供したりすることが可能になります。ただし、そのコストは摩擦です。

Linuxカーネルをはじめとする多くのプロジェクトで使用されている開発者証明書は、ライセンスの付与ではなく、各コミットに署名行として追加される、貢献者がプロジェクトのライセンスに基づいてコードを提出できることを証明する簡素な証明書です。負担は少なく、保護も限定的です。特許ライセンスも、再ライセンスもありません。

二重ライセンスや将来的な再ライセンスが考えられる場合は、CLA（共有ライセンス契約）を使用してください。プロジェクトが真の共有資源である場合は、通常、DCO（開発許可契約）で十分です。いずれの場合も、雇用契約や請負契約において、従業員が作成したコードの著作権を譲渡する旨を明記してください。

実用的な政策チェックリスト

• ビルドパイプライン内で、製品およびリリースごとにコンポーネントインベントリを生成してください。手動で生成する必要はありません。
• 社内規定を公開する：許可リスト、禁止リスト、およびその他すべての事項に対する承認ルートを明記する。
• 配布物として何が含まれるかを文書で定義してください。オンプレミスインストール、アプライアンス、コンテナ、SDK、モバイルアプリ、ファームウェアなどが含まれます。
• すべての製品に、生成された帰属情報ファイルを同梱してください。
• ライセンスの選択は、コンポーネントが選択される設計段階で承認されるべきであり、リリース時ではない。
• 関連する特許付与を考慮して、外部プロジェクトへの貢献に承認が必要かどうかを判断し、最初の外部貢献を行う前にCLAまたはDCOを選択してください。
• 知的財産権に関する保証、補償、およびエスクローの条件を、製品に実際に組み込まれているオープンソースの内容と整合させる。
• 資金調達や販売プロセスの最中ではなく、その前にレビューを実施してください。

Law & More ソフトウェア企業とその投資家にアドバイスを提供する Eindhoven (NAIST) と Amsterdam 取引におけるオープンソースのコンプライアンス、ライセンスレビュー、貢献者との契約、およびオープンソースのワークストリームについて。