ソフトウェア主権の尺度

この記事は Dries Buytaert の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

デジタル主権は、ソフトウェアがどこから来たかよりも、誰がそれを制御するかに依存します。この記事では、決して奪われることのない技術を示す尺度を紹介します。

「欧州製を買おう」は、デジタル主権に関する欧州の合言葉になりつつあります。その論理は直感的です。アメリカの技術からの独立を望むなら、代わりに欧州企業から購入すべきだと。

しかし、私は「欧州製を買おう」は一つの点で正しく、一つの点で間違っていると思います。欧州がより強力な技術産業から恩恵を受けるという点は正しいです。しかし、欧州製を買っても主権は保証されません。

主権とは、企業の本社がどこにあるか、ソフトウェアがどこで最初に書かれたかということではありません。それは最終的に誰が技術を制御するかということです。

あらゆる技術について尋ねるべき正しい質問は、誰かがそのソフトウェアを私から奪い取ることができるか、ということです。

主権を評価する際、今日どれだけの制御権を持っているかを問うだけでは不十分です。その制御権のどれだけが構造的に保護されており、法的およびコミュニティの基盤に組み込まれているため、明日奪われることがないかも問う必要があります。

提案された尺度は構造的保護を測定します。これは開放性のランキングではなく、主権のあらゆる側面を捉えているわけでもありません。オープンソースライセンスは主権にとって非常に有益ですが、それだけでは十分ではありません。この尺度はまた、あるライセンスが常に別のライセンスより優れていることを意味するものでもありません。

この尺度における最も重要な区別は、オープンソースとプロプライエタリの間にあります。3つの緑色のグレードはすべて、ソフトウェアを独立して使用、修正、維持する自由を与えます。A、B、Cの違いは現実的ですが、比較的軽微です。それらは、その自由が買収、再ライセンス、または重要な資金の喪失に対してどれだけ構造的に保護されているかを反映しています。

欧州でおなじみのAからEのエネルギー効率や食品栄養ラベルをモデルに、5つのレベルを使用しました。構造的に主権を持つものから完全に依存するものまでです。欧州委員会のクラウド主権フレームワークのような枠組みは、まだこれらの構造的な違いを明確にしていません。この尺度は、現存し今日使用されているものを改善することを目的としており、精査とフィードバックを通じてさらに改善されることを期待しています。

所有権とともに管轄上の義務が変わる

最下位のグレードEは、外国のプロプライエタリソフトウェアです。ソースコードなし、修正する権利なし、ベンダーが条件を変更した場合の代替手段もありません。あなたのベンダーはその本国政府の管轄に服し、延いてはあなたのデータもそうなります。

グレードDは欧州のプロプライエタリソフトウェアで、通常「欧州製を買おう」が当てはまるのはここです。これには本当の利点があります。欧州の管轄権、GDPR準拠、地域の説明責任、そして投資が欧州のエコシステム内で循環し続けることです。企業を立ち上げスタートアップに投資している者として、私はより多くの技術企業が成功することを望んでいます。しかし「欧州」は企業の一時的な属性に過ぎず、単一の取締役会の会議で変わる可能性があります。

Skypeは、スウェーデン人とデンマーク人によって設立され、エストニアのエンジニアによって構築され、ルクセンブルクに本社を置いていました。eBayは2005年にそれを買収し、Microsoftは2011年にそれを買収しました。eBayの取引により、世界をリードする欧州の技術はアメリカの技術に変わり、Microsoftの取引でそれは確固たるものになりました。

したがって、所有権と管轄権は重要ですが、それだけでは十分ではありません。欧州企業は明日買収される可能性があります。オープンソースはより重要なものを提供します。コードを単一の企業や国から分離するのです。

すべてのオープンソースが等しく主権的であるわけではない

オープンソースこそが、真の主権を可能にするものです。同時に、オープンソースの主権はスペクトラム上に存在します。保護のレベルは2つの法的レバーに帰着します。ライセンス自体と、ライセンスを変更する権限を決定する著作権の所有です。

グレードCは、BSD、MIT、Apacheのような許容型ライセンスの下でのオープンソースです。コードを見てフォークすることはできますが、ライセンスは改良がオープンのままであることを要求しません。企業がコードを取得し、それを基に構築し、プロプライエタリバージョンをリリースすることができます。

閉鎖的な商用バージョンがブランド、ホスティングサービス、またはエンタープライズ機能を通じて標準になると、それに依存する政府は再び法的・運用的にロックインされる可能性があります。彼らはグレードEに戻るのです。

Redisは、このダイナミクスがどのように展開するかを示しています。15年間BSDライセンスの下でオープンソースでした。2024年3月、Redis Ltd.は制限的な条件の下で再ライセンスし、オープンソースイニシアチブはそれをオープンソースとして承認しませんでした。

幸いなことに、コミュニティは最後のオープンバージョンをValkeyとしてフォークし、Valkeyは繁栄しています。これが許容型オープンソースの強みです。条件が変わったときに逃げることができます。政府はRedisがフォークされたことで幸運でしたが、構造的リスクは残っています。

グレードBは、単一著作権保有者を持つGPLのようなコピーレフトライセンスの下でのオープンソースです。

コピーレフトは、許容型ライセンスにはない保護を追加します。リリースされたコードの派生物もオープンソースのままでなければなりません。政策立案者にとって、これは意味のあるアップグレードです。

このレベルがMySQLを救いました。MySQLの背後にあるスウェーデンの企業MySQL ABはそれをGPLでリリースしたため、OracleがSun Microsystemsの取引を通じてMySQLを買収したとき、GPLがコードをオープンのままに保ちました。MySQLのオリジナルクリエイターであるMichael Widenius氏は、コードを持ち出してMariaDBを構築しました。Oracleはブランドを手に入れましたが、世界はコードを守りました。

そして、MariaDBはMySQLのGPLライセンスを継承したため、オープンのままでなければなりません。将来の買収者がMariaDBをプロプライエタリにすることはできません。これがコピーレフトと許容型ライセンスの違いです。コピーレフトは誰かがフォークすることを許し、かつすべてのフォークをオープンのままにすることを強制します。

しかし、グレードBにはまだ1つの制限があります。単一著作権保有者は、将来のバージョンを異なるライセンスでリリースできます。既存のコードはGPLによって保護されていますが、プロジェクトの将来のライセンスは著作権を保有する人によって制御されます。

一部のプロジェクトは、貢献者にコントリビューターライセンス契約（CLA）への署名を求めることで、このリスクを増幅させています。これは、プロジェクト所有者に貢献されたコードを再ライセンスする権利を与えます。アムステルダムで設立されたElasticsearchは、1,500人以上の貢献者がいるにもかかわらず、2021年にCLAを使用してApache 2.0から非オープンソースライセンスに再ライセンスしました。

最後に、グレードAは、分散著作権所有を持つコピーレフトオープンソースです。何百、何千もの貢献者がそれぞれコードの一部を所有している場合、再ライセンスにはそれら全員の同意が必要です。拒否する人がいれば、プロジェクトはその貢献をゼロから書き直さなければなりません。独立してコードの一部を所有する貢献者が多いほど、再ライセンスは困難になります。

Drupalは25年間にわたって何万人もの人々から貢献を受けてきており、再ライセンスは構造的に不可能です。買収も、取締役会の投票も、戦略の変更も、これらのプロジェクトを構築し依存する人々からそれらを奪うことはできません。独立した貢献者が少ないコピーレフトプロジェクトは、再ライセンスが容易な場合があります。Drupalのコードは設計上、構造的に主権を持っています。

主権は長期的なコミットメントである

EからDへの移行は進歩です。DからCへの移行が本当に重要なのです。Cより上では、この尺度はより小さいながらも依然として重要なトレードオフを浮き彫りにするため、政府がより低いグレードを選択する際には、知らずにではなく知った上でそうすることになります。

重要な資金を失ったオープンソースプロジェクトは、存続可能であり続けるために投資を必要とすることがよくあります。しかし、買収や再ライセンスとは異なり、資金リスクは政府調達と公共投資を通じてEUがほぼコントロールできるものです。

欧州委員会への提言

主権には多くのことが関わります。データの所在地、サプライチェーン、技術人材、標準規格。ライセンスと著作権は構造的基盤を形成します。なぜなら、それらが法的独立がそもそも可能かどうかを決定するからです。

欧州委員会のクラウド主権フレームワークは、この広範な視点を反映しています。それは、「オープンライセンスの下でアクセス可能」かどうかを問う技術主権を含む、8つの主権目標にわたってクラウドソフトウェアを評価します。これは最も重要なステップですが、オープンライセンシングを二値的なものとして扱っています。ソフトウェアがオープンであるか、そうでないかのどちらかです。

私は、委員会が技術主権の目標を2つの方法で強化することを勧めます。

1. ライセンスタイプを区別すること。許容型ライセンス（BSD、MIT、Apache）は、派生物がオープンのままであることを義務付けません。コピーレフトライセンス（GPL、AGPL）は、派生作品を同じオープン条件でリリースすることを要求します。

2. 著作権の集中度と再ライセンスリスクを評価すること。単一著作権保有者またはコントリビューターライセンス契約を持つプロジェクトは、現在のライセンスに関係なく再ライセンスされる可能性があります。分散著作権所有を持つプロジェクトは再ライセンスできません。これが、開放性への取り消し可能な約束と取り消し不可能な約束の違いです。

フォローアップの投稿で、委員会のフレームワークに対してさらに2つの提言を共有します。1つは8つの主権目標間の関係について、もう1つはインフラストラクチャの管轄権についてです。これら3つの投稿を合わせて、すでに真剣で歓迎すべき取り組みを強化することを目指しています。よろしければ、購読してご覧ください。

私は、ソフトウェア主権尺度が欧州の調達政策の一部であるべきだと考えています。政府が公共ウェブサイトのためのコンテンツ管理システムや国民健康記録のためのデータベースを選択する際、依存する技術の構造的主権グレードを知るべきです。

重要なソフトウェアについて、質問はシンプルです。誰かが私たちからソフトウェアを奪い取ることはどれだけ簡単か、ということです。

Sachiko Muto氏とBert Boerlandに、このブログ記事のレビューと貢献に対して特別な感謝を。

By Dries Buytaert

追伸：LinkedInでのディスカッションにもご参加ください。

この記事は「The Software Sovereignty Scale」（投稿日：2026-02-10）の翻訳記事です。