変化する「オープンソース企業のオープンソースに対する姿勢」――その背景と今後の動きとは？ | 東京エレクトロンデバイス

Linuxをはじめとする様々なオープンソースソフトウェアは、ソフトウェア業界にとってなくては
ならない存在です。さらに言えば、いまや社会基盤と言えるクラウドそのものも多くのオープンソースに依存していることを考えると、オープンソースは社会にとって必要不可欠な存在なのです。そして、オープンソースは様々な企業によって支えられてきました。

しかし今、そうしたオープンソースを推進してきた企業のいくつかが、これまでとは異なる姿勢を見せています。その代表的な例をいくつか紹介しつつ、オープンソースのあり方が以前よりも変化してきている状況を考察しましょう。

オープンソースソフトウェア業界をリードしてきた筆頭格と言っても過言ではないRed Hatは2023年
6月、同社の「Red Hat Enterprise Linux」（以下RHEL）のクローンOSを提供しているベンダーに対して「オープンソースに対する脅威だ」と非難する内容のブログ（https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes）を公開しました。

そこには「単にコードをリビルドするだけで何ら付加価値や変更を加えることをしないのであれば、
それはあらゆるオープンソース企業にとって脅威に他ならない。まさにオープンソースに対する真の
脅威であり、オープンソースをホビイスト やハッカーだけの活動に逆戻りさせてしまうかもしれない」と記されています。

RHELはオープンソースであり、そのソースコードはパブリックなリポジトリで公開されていました。
そしてRHELのクローンOSベンダー、例えば国産のRHELクローンとして知られるMiracle Linuxを
はじめ、Alma Linux、Rocky Linux、Oracle Linuxなどはすべて、公開されているRHELのソースコードをリポジトリからコピーしてRed Hatの商標などに関する部分を取り除くといった変更を加え、さらにOSとして使えるようにするためのリビルドを行うことで、RHELのクローンOSをつくってきました。

しかしRed Hat は、ソースコードの公開をRHELの正規ユーザーのみに限るとし、前述のようにクローンOSベンダーを非難する声明とともに、ソースコードの一般公開を止めてしまったのです。

RHELは企業向けLinuxディストリビューションのデファクトスタンダードと言うべき存在であり、
それがオープンソースであるが故に、多数のRHELクローンとともに大きなエコシステムを形成してきました。しかし今回のRed Hatの動きにより、これまでクローンOSベンダーが行ってきた方法ではRHEL
クローンがつくれなくなりました。現時点では各クローンOSベンダーとも何らかの方法でクローンOSの開発を維持していますが、今後もこのエコシステムが現状と変わりなく続くかどうかは注意深く見守っていく必要があります。

これまで先陣を切ってオープンソースの普及を後押ししてきたRed Hatの姿勢からすると、その変貌ぶりは意外とも言えます。その本意は推測するしかありませんが、やはりRHELのビジネスをクローンOS
から守りたいということなのかもしれません。

創業以来、オープンソースとして製品を開発してきたHashiCorpは2023年8月、今後リリースする全製品のライセンスを商用利用制限がある「Business Source License v1.1」に変更すると発表しました。

これにより同社製品は今後、オープンソースではなくなることになります。その理由として同社は、
オープンソースを利用するだけで実質的な貢献がないベンダーが存在すると指摘。オープンソースの
精神に沿わないベンダーがオープンソースモデルを利用してイノベーションをコピー販売できてしまうことが、今回のライセンス変更に結びついたと説明しました。

同社のソースコードに新たに設定されたライセンスは、競合サービスの提供を牽制する内容となって
おり、クラウドプロバイダーなどがTerraformやVaultのソースコードを用いてサービス提供を行い同社の競合になることを未然に防ぐものとなっています。

というのも、オープンソースとして開発されたソフトウェアを使ってクラウドベンダーなどがサービスを構築し、多額のお金を儲けていると指摘するソフトウェアベンダーがすでに存在するのです。その
代表例がElasticsearchを開発するElasticです。

オランダに本社を置くElasticは2021年、オープンソースで開発してきたElasticとKibanaのライセンスをそれまでの「Apache License 2.0」から、商用サービス化を制限する「Server Side Public License」（SSPL）と「Elastic License」のデュアルライセンスに変更すると発表しました。

その目的は、AWSが勝手にElasticsearchとKibanaをマネージドサービスとして提供できないようにするためであると、同社CEOのShay Banon氏がブログで明らかにしています。

オープンソースソフトウェアの開発元がAWSなど大手クラウドベンダーに対して、オープンソースを
基にしたマネージドサービスで大儲けしていると反発を表明するケースはElasticだけではありません。2019年の時点でRedis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更を
行い、大手クラウドベンダーが勝手にマネージドサービスを提供できないようにしたのです。

クラウドの時代になり、クラウドベンダーはオープンソースソフトウェアを基にしたサービスによって大きなビジネスを展開してきました。しかも、その売上げがオープンソースの開発に還元されることはほとんどありません。そうしたことが、オープンソースソフトウェアの開発元をライセンス変更へと
走らせているわけです。

ただし、オープンソースから商用利用を制限したライセンスに変更した場合も、商用利用が制限されているだけで、ソースコードは公開された状態であることがほとんどです。つまり、こうしたライセンス形態はソースコードが閲覧可能であることから「ソースアベイラブル」と呼ばれています。

クラウドベンダーへの対抗策として、今後、オープンソースからこうしたソースアベイラブルな
ライセンスへ切り替える企業は少しずつ増加していくのではないでしょうか。

このように、オープンソースソフトウェア開発企業がオープンソースに対してこれまでと異なる姿勢を示すことが目立ち始めています。もちろん、こうしたケースはまだ少数派ではありますが、オープン
ソースを基にしたビジネスとしてオープンソースソフトウェアの開発元がマネージドサービスを提供することが一般化しつつあるため、大手クラウドベンダーがマネージドサービスを提供できないような
ライセンスにしておくことは今後増えていくのかもしれません。

一方、こうしたライセンス変更に対抗して、オープンソースコードをフォーク（ソースコードを元に
新たな開発プロジェクトを立ち上げること）することで、オープンソースを維持する動きもあります。

具体的には、HashiCorpがライセンス変更したTerraformはフォークしてオープンソースのOpenTofuになり、ElasticsearchもフォークしてOpenSearchになるといった例があります。

これらの場合、オリジナルのソフトウェア開発とフォーク後のオープンソース開発がそれぞれ別々に
進められることになるため、非常に似たソフトウェアが複数存在することになります。そのどちらを
選ぶかは悩ましい問題となりそうです。

これまでソフトウェアのライセンスは大まかに言うと、ソースコードが非公開のプロプライエタリー
ソフトウェアか、もしくはソースコードが公開されているオープンソースかに二分されていました
（細かくはそれ以外のライセンスも存在しましたが）。

今後はこの2つの中間に位置するソースアベイラブルなソフトウェアがさらに増えるであろうと
見ています。それと同時に、オープンソースコードをフォークすることによって元のオープンソースと似たソフトウェアの出現も増えていくことでしょう。

いずれにしても、こうした選択肢が増える中でユーザーは適切なソフトウェアの選択を行うことが
ますます重要になっていくのではないでしょうか。