欧州連合、オープンソースを欧州テック主権の中心に据える。当社はその準備ができていた。
すべての欧州CIOが注目すべき数字
最近、欧州委員会は欧州テクノロジー主権パッケージを発表しました。この中にはChips Act 2.0、Cloud and AI Development Act、エネルギー分野のデジタル化とAIに関する戦略的ロードマップ、そしてEUデジタル政策史上初となるEUオープンソース戦略が含まれています。
ファクトシートの見出しとなっている数字は、年間2,640億ユーロが第三国の製品やサービスに支出されているというものです。この数字こそ、すべての欧州CIOや調達担当者が立ち止まり、慎重に文書を読むべき理由です。2億6,400万ユーロではありません。2,640億ユーロです。毎年です。その多くが、少数の大手プロプライエタリクラウドおよびソフトウェアベンダーに流れています。これらの組織は、サービス利用規約や価格設定、製品ロードマップ、データアクセス方針を、欧州の機関や市民に対して何の責任も負わない取締役会で決定しています。
欧州委員会のウルズラ・フォン・デア・ライエン委員長は明言しています。「私たちは、病院を動かし、エネルギー網を安定させ、サービスを安全に保つ技術について、他者に依存する余裕はありません。これは市民を守り、私たちの利益を防衛し、自ら選択するためのものです。」
これは単なる技術政策の声明ではありません。地政学的な宣言です。そして、GDPR以降で最も高まった欧州のデジタルインフラへの地政学的圧力の中で発表されました。
オープンソースはもはや脚注ではない
従来のEUデジタル戦略文書では、オープンソースは簡単に触れられる程度でした。箇条書きや、FOSS（フリー＆オープンソースソフトウェア）エコシステムへの言及程度です。しかし、テクノロジー主権パッケージは異なります。EUオープンソース戦略は、オープンソースをEUのテクノロジー主権の中心に据えています。Cloud and AI Development Actも、オープンで協調的かつレジリエントなデジタル環境の実現に向けた欧州委員会のコミットメントを再確認しています。
欧州委員会は、ベンダーロックインと戦略的脆弱性を明確に区別し、EUのデジタルインフラが少数の支配的なプロプライエタリプロバイダーに集中していることを、単なる競争上の懸念ではなく、戦略的な脆弱性として位置付けています。これは大きな転換です。長年、公的調達におけるオープンソースの議論は、経済的（TCOの低減）またはイデオロギー的（デジタルコモンズ）なものでした。しかし、テクノロジー主権パッケージはこれを戦略的なものと位置付けています。自らがコントロールできないベンダーのプロプライエタリソフトウェアへの依存は、デジタル主権を妨げます。これが、公開された政策文書における欧州委員会の立場です。
ファクトシートでは、欧州に3百万人のオープンソース貢献者がデジタルソリューションを提供していることにも触れています。これが労働力です。戦略、貢献者、そして政治的意志が、今やすべて一致しています。
「主権」に本当に必要なものとは
ここで正確に述べたいのは、「デジタル主権」という言葉が、あらゆるクラウドベンダーがフランクフルトのデータセンターに貼り付けて済ませているラベルになっているからです。
本当の主権には4つの要件があります。テクノロジー主権パッケージは、そのすべてに対応しています。
- 自分自身でソフトウェアを運用できること。
「主権クラウド」と称しながら、コードがプロプライエタリで、ベンダーがライセンスを終了したり、条件を変更したり、自由にデータへアクセスできるのであれば、それは主権ではありません。マーケティング用語を使った賃貸に過ぎません。これはベンダーの本社所在地に関係なく当てはまります。フランクフルトのデータセンターであってもプロプライエタリロックインはロックインです。自己ホスティング可能なオープンソースが最低条件です。Cloud and AI Development Actが主権評価フレームワークを導入したのは、まさにこの違いを欧州委員会が理解しているからです。 - ソフトウェアの中身を理解できること。
サプライチェーンセキュリティは流行語ではありません。自分のインフラでどのサードパーティコードが動いているか、それがどこから来たのか、監査されているかどうかを把握できるかが問われます。SBOM（ソフトウェア部品表）、署名付きビルド、脆弱性開示ポリシーは、ソフトウェアにおける主権の運用的な表現です。 - 検証可能なガバナンスがあること。
「オープンソースにコミットしている」と言いながら、公開されたガバナンス憲章も、コミュニティ諮問委員会も、意思決定プロセスも定義されていないベンダーは、構造的なコミットメントではなくマーケティング上の約束をしているだけです。オープンソース戦略は、オープンソースプロジェクトを持続的に支える組織的・ガバナンス的な能力を求めています。 - 法的な明確性があること。
オープンソースライセンスはすべて同じではありません。Apache 2.0ライセンスは、寛容で調達上も安全、欧州のエンタープライズや公共部門の要件にも幅広く適合します。AGPLはコピーレフトライセンスであり、これを組み込んだソフトウェアは同じ条件で公開が求められる場合があり（公共部門のプロプライエタリ調達では障壁となることが多い）、自社のライセンス構成を理解することは主権的な調達の基本です。
政策が登場する前に私たちが築いたもの
ownCloudは2010年にドイツで設立されました。欧州の学校、政府機関、研究機関、パブリックセクタークラウドで16年間導入されてきました。何百万人ものユーザーがoCISを利用しています。
このパッケージが発表される1か月前の5月5日、私たちはKiteworks Open Source Program Officeを立ち上げました。OSPOローンチで掲げたすべてが、今テクノロジー主権パッケージが政策レベルで求めている内容と直接対応しています：
デフォルトでApache 2.0。
oCISはApache 2.0ライセンスを採用しています。新しいリポジトリはデフォルトでApache 2.0。調達時のコピーレフトリスクなし。ライセンスの曖昧さを商業的な交渉材料にしません。これをマニフェストで明記しています。
CLA廃止、DCO採用。
貢献者の著作権は貢献者自身に帰属します。これは主権にとって重要です。なぜなら、単一ベンダーがコードベース全体を所有することがなくなるからです。コードは書いた人のものであり、Apache 2.0のもとで世界にライセンスされます。
公開されたガバナンス憲章。
理想論ではなく、役割や意思決定プロセス、紛争解決、コミュニティ諮問委員会のタイムライン、ポリシー変更のための30日間のパブリックコメント期間などを明確に定義した文書です。Kiteworksがロードマップを主導すること、そしてコミュニティがその方向性に影響を与える仕組みが明確に記載されています。これこそ、オープンソース戦略が求めている構造的コミットメントです。
SBOM、署名付きビルド、VDP。
サプライチェーンセキュリティは、私たちにとって理論ではありません。脆弱性開示ポリシーを公開し、YesWeHackでバグバウンティプログラムを運営し、リリースごとにSBOMを生成し、コンテナイメージに署名し、パッチ管理記録を公開しています。今年初めには、サプライチェーンの侵害（CVE-2026-33634、Trivy）にも対応し、公開インシデントレポート、各国語での影響顧客への通知、エクスポージャ期間内でのイメージ更新を実施しました。これはマーケティング資料だけでなく、実際のプレッシャー下での主権の実践です。
12の公開文書。
ビジョン、ミッション、マニフェスト、ガバナンス憲章、AI貢献ポリシー、セキュリティ開示ポリシー、貢献ガイド、教訓、行動規範、エンゲージメント、エンパワーメント、プロダクトビジョン（詳細はOSPOページをご覧ください）。私たちのすべてのコミットメントは文書化され、公開検証可能です。
なぜOSPOが最適な組織なのか
テクノロジー主権パッケージは、政策レベルでオープンソースに取り組んでいます。OSPO（Open Source Program Office）は、企業や公共機関の内部で政策を実装するための組織構造です。
欧州委員会のオープンソース戦略は、オープンソースを活用して主権的かつレジリエントなデジタル未来を実現するための、これまでで最も重要な一歩です。しかし、実装のない戦略は単なる文書に過ぎません。Kiteworks OSPOは、ownCloudの実装を具体化するために存在します。公開されたセキュリティポリシー、明確な貢献者の道筋、コミュニティガバナンス構造、そしてオープン性を損なうことなくオープンソースプロダクトを経済的に持続可能にする商業サポートモデルを備えています。
私たちの商業モデルの4つの要素は、欧州の公共部門顧客がオープンソースを責任を持って導入するために必要なポイントに直接対応しています。
- サポートとSLA。
コードは無料です。しかし、仮想データルームがダウンした際に午前2時に対応する人材は無料ではありません。サポート階層により、公共部門組織が重要インフラに必要な契約上の対応を得られます。 - 強化ビルドとSBOM。
監査人はGitHubリンクには関心がありません。署名付きSBOM、パッチ管理記録、ベンダー証明が必要です。私たちはそのすべてを提供します。 - コンプライアンス文書。
ドイツやEU全域の公共部門組織は、これらのフレームワークの下で運用されています。Kiteworksのサブスクリプション階層には、コンプライアンスマッピング、監査サポート、規制下でownCloudを可監査にする専任コンプライアンス担当が含まれています。 - 法的保護。
Apache 2.0は寛容なライセンスです。私たちのサポートサブスクリプションは、ライセンスの背後に立つベンダーによる知的財産補償を必要とする組織に対してIP補償を追加します。
本当に重要な数字
2,640億ユーロ。毎年。欧州の組織がロードマップや価格、契約条件に実質的な影響を及ぼせないベンダーに流れています。
テクノロジー主権パッケージがこの数字を一夜にして変えることはありません。法制化には時間がかかります。調達サイクルも長く、組織の慣習も根強いものです。
しかし、方向性は定まりました。EUは、半導体、AI、クラウド、オープンソース分野で欧州の能力を強化しようとしています。オープンソース戦略、Cloud and AI Development Actの主権要件、公共部門のオープンソース義務化――これらは、オープンでガバナンスされ、可監査な代替手段がデフォルトとなるための構造的条件です。
問題は、ベンダーの本社所在地ではありません。コードを監査できるか、必要に応じてフォークできるか、サプライチェーンを検証できるか、自社の法的枠組みのもとで自社インフラ上で運用できるかどうかです。ベンダーロックインはこの4つすべてで不合格です。正しく実践されたオープンソースは、この4つすべてを満たします。
ownCloudは2010年からその代替手段であり続けています。OSPOは、ガバナンスとコミュニティへのコミットメントを単なる言葉ではなく構造として実現しています。そして、最近発表されたテクノロジー主権パッケージは、私たちがこれまで築いてきたものこそ、今欧州のデジタル政策が求めているものであることを証明しています。
このタイミングは偶然ではありません。この問題は何年も前から顕在化していました。私たちはその答えを追い求めてきました。
—
EUテクノロジー主権ファクトシートを読む：ec.europa.eu/commission/presscorner
ownCloud OSPO: kiteworks.com/opensource · owncloud.com/blogs
oCISを試す：github.com/owncloud/ocis · owncloud.dev
David WalterはKiteworksのOpen Source Program Office担当VPであり、ownCloudのオープンソースガバナンス、ライセンス、コミュニティエンゲージメントをリードしています。2014年からownCloudエコシステムに携わっています。