今日は技術の話ではなく、少しゴシップをしたいと思います。最近、情報システムインフラのローカライゼーションの波が押し寄せ、多くの国内ITインフラベンダーが恩恵を受けています。しかし、一部の反対意見として、国産ITインフラの大部分はオープンソースコードに依存しており、「偽国産」になっているという意見もあります。ゼロから開発されていないソフトウェアは国産とはみなされないようです。たとえコードの大部分が自社開発であっても、盗作とみなされ、認められないのです。最近、「オープンソースプロジェクトがクローズドソースになったら、ローカライゼーションは完全に台無しになる」という声もよく聞きます。オープンソースを使うべきかどうか、そしてオープンソースプロジェクトを活用することがローカライゼーションに該当するかどうかについては、以前にも私の見解を述べたことがあるので、ここでは詳しく述べません。この問題に対する見方は人それぞれですが、それは当然のことです。多くのことが明らかになるまでには数十年かかるため、今結論を出すのは時期尚早です。

国内のITインフラがオープンソースコードを多用しているのは事実です。私たちはこの分野で後発で追い上げてきたため、ゼロから始めると差が開いてしまう可能性が高いため、比較的時代に合わせやすい方法を選ぶことは避けられないかもしれません。オープンソースの多用は避けられないので、オープンソースコミュニティがクローズドソースになったらどうなるでしょうか？実は、当社は何年も前にこの問題に直面しました。Nanda Generalの分散型データウェアハウスシステムGBASE 8Aは、ストレージエンジンにInforbrightのオープンソースコードの標準バージョンを使用していました。しかし、2015年頃、Inforbrightはオープンソースライセンスを変更し、製品はクローズドソースになりました。しかし、GBASE 8Aは消滅したわけではなく、近年隆盛を極めており、国内のデータウェアハウス分野でのシェアを着実に伸ばしています。実際には、Nanda GeneralがInforbrightのオープンソースコードを採用するだけでは、分散型データウェアハウス製品を組み立てることはできません。これは、オープンソースのInforbrightが単一マシン版であり、クラスタリングをサポートしていないためです。長年の開発を経て、Nanda GeneralはInforbrightストレージエンジンの主要コードをほぼ習得したと考えています。

オープンソースプロジェクトはライセンスを頻繁に変更しますが、近年このような状況に遭遇したのはInforbrightだけではありません。2019年のRedisのライセンス変更は大きな騒動となりました。一部の高度なコンポーネントのみが独自のRSAライセンスに変更され、RedisのコアコンポーネントはApache V2のままだったことが判明しました。オープンソースライセンスを繰り返し変更してきたこの企業は、それぞれの変更を資金調達などの商業活動と結び付けているようです。実際、近年のMongoDBやElasticsearchのより商業的なライセンスへの変更も、資金調達やIPOに関連しています。これらの企業はユーザーを搾取しているわけではなく、株主のために利益を上げることが彼らの主な責任であり、これは通常のビジネス慣行です。

オープンソースライセンスは変更される可能性があるため、オープンソースプロジェクトの選択には細心の注意が必要です。オープンソース製品が大企業のリーダーシップの下で開発され、コアコードをその企業が保有している場合、その企業は商業的利益のためにオープンソースライセンスを変更する可能性が高くなります。企業による明確な支配がないコミュニティ内のオープンソースプロジェクトは、リスクが低くなります。

これまで焦点を当ててきたLinuxを振り返ると、最も有名なオープンソースのLinuxディストリビューションがGNU/Linuxであることをすっかり忘れていました。このディストリビューションは、今日のほとんどのLinuxディストリビューションのソースとなっています。GNUはGPLオープンソースライセンスの略だと思っている人もいるかもしれませんが、そうではありません。GNU/Linuxは2つのソフトウェアパーツを組み合わせたものです。LinuxはUNIXライクなカーネルで、コードベースは他のLinuxディストリビューションに比べて非常に小さく、GNUはLinuxカーネル以外のオペレーティングシステム全体です。GNUは最も初期のオープンソース組織でもあり、GPLはそのオープンソースライセンスです。LinuxカーネルはGNUと統合された後、GNUの粗悪なHURDカーネルに取って代わり、それ以降、LinuxカーネルもGPLオープンソースライセンスに従うようになりました。

これまで、数万もの組織や個人がLinuxコードベースに貢献してきました。各貢献者は、貢献するコードに適用するオープンソースライセンスを独自に決定できますが、コードがGPLと互換性のあるものでなければなりません。実際、現在使用されている多くのLinuxディストリビューションは、GPLオープンソースライセンスに準拠していません。現在、GNU/Linux全体のオープンソースライセンスが変更される可能性は極めて低いです。仮にコンポーネントがGPLと互換性のないオープンソースライセンスに変更されたとしても、オープンソースコミュニティは即座に代替ライセンスを選択するでしょう。したがって、GNU/Linuxがクローズドソース化される可能性は極めて低いと言えます。

GNU/Linuxのような主要なオープンソースプロジェクトがクローズドソース化する可能性はすぐにはないでしょうが、企業は利益をそれらだけに頼るべきではありません。オープンソースコミュニティに積極的に参加し、高品質なオリジナルコードを提供することは、オープンソースプロジェクトの商用版をリリースするすべての企業の責任です。貢献度が高ければ高いほど、コミュニティ内での影響力は高まります。同時に、オープンソースプロジェクトの商用版をリリースする企業は、ライセンスを厳格に遵守する必要があります。例えば、GNU/Linuxコードを使用している企業は、引き続きコードをオープンソース化する必要があります。オープンソースコミュニティから完全に離脱し、コードをリファクタリングして独自のクローズドソース製品を開発する覚悟がない限り、オープンソースライセンスを厳格に遵守する必要があります。そうでなければ、オープンソースコミュニティのブラックリストに載せられるリスクがあります。

さらに、現在、一部の国内ソフトウェアベンダーに対する最大の不満は、オープンソースコードを利益のためにパッケージ化し、本来の製品メーカーに期待されるサービス責任を果たさないことにあります。ユーザーは、問題発生時に実質的にアフターサポートを受けられない状況に置かれています。Red HatのRHELを購入すれば、Red Hatのウェブサイトで解決策を見つけるか、問題を報告してパッチを待つしかないことは周知の事実です。Red HatもRHELも、収益源をオープンソースコミュニティに依存しています。Red Hatがそうできるのであれば、国内ソフトウェアベンダーにもそうできると期待しています。こうして初めて健全なエコシステムが形成され、国内ソフトウェアベンダーが真に「形骸」というレッテルを脱ぐことができるのです。