AWSが、Elasticsearchのコードにはプロプライエタリが混在しているとして、OSSだけで構成される「Open Distro for Elasticsearch」を作成し公開

2019年3月19日

AWSは、オープンソースの高速な検索エンジンとして活用されている「Elasticsearch」の独自ディストリビューション「Open Distro for Elasticsearch」を公開しました。

fig

Elasticsearchはオランダに本社を置くElastic社が中心となり、オープンソースとして開発されている検索エンジンです。

検索エンジンのライブラリとして開発されているApache Luceneをコアとし、分散処理機能やマルチテナント機能、分析機能などを備えスケーラブルで高速な実行を可能とし、RESTful APIやSQLによってクエリを発行できるなど、多くの優れた特徴を備えています。

ログ解析による運用監視やセキュリティインシデントの発見、データ分析など多数の実績を持つ、この分野でもっとも人気のあるソフトウェアの1つであり、AWSもマネージドサービス「Amazon Elasticsearch Service」を提供しています。

AWSが公開した「Open Distro for Elasticsearch」は、このElasticsearchのディストリビューションおよびそのコードを納めたGitHubリポジトリで構成されるようです(記事執筆時点で、まだリポジトリはほとんどなにも入っていませんが)。

「Open Distro for Elasticsearch」はすべてApache 2.0のライセンスで提供され、ノード間の暗号化やOpenSSL/TLS 1.2のサポート、Active DirecotryやLDAP、SAMLなどによる認証、ロールベースのアクセス制御、監査ログなどに対応することでセキュリティを高めるなどのセキュリティ機能、SQL対応など多くの機能が備わっています。

Elasticsearchにはプロプライエタリなコードが相当混在している

しかし注目すべきなのはそうした特徴よりも、なぜAWSが独自にディストリビューションと、それに対応するGitHubリポジトリを作るに至ったのか、という理由です。

AWS Open Source Blogにポストされた記事「Keeping Open Source Open – Open Distro for Elasticsearch」でその理由が説明されているのですが、要約すると、GitHubで公開されているElasticsearchのコードにオープンソースとプロプライエタリが相当混在するようになってしまったためだ、ということです。

そこでAWSは、あらためてオープンソースだけで構成されるElasticsearchのコードを集めたGitHubリポジトリと、それによるディストリビューションを作った、というわけです。

もう少し細かくAWSの言い分を参照してみましょう。下記は「Keeping Open Source Open – Open Distro for Elasticsearch」の一部を引用し、翻訳したものです。

まずオープンソースのコードとプロプライエタリなコードがGitHubのリポジトリで混在していること、両方のコードが混在したElasticによる独自ライセンスのディストリビューションが、Elasticsearchのデフォルトディストリビューションとして配布されるようになったことの2つの問題を指摘しています。

Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base.

残念ながら2018年6月以来、私たちはそのコードベースにプロプライエタリなコードが相当混在していることを目撃することになりました

While an Apache 2.0 licensed download is still available, there is an extreme lack of clarity as to what customers who care about open source are getting and what they can depend on.

Apache 2.0ライセンス化されているダウンロードはまだ有効なものの、オープンソースを気に掛ける顧客にとって、なにが利用できてなにが信頼できる部分なのか、といった明確さがまったく欠けているのです。

For example, neither release notes nor documentation make it clear what is open source and what is proprietary.

例えば、リリースノートにもドキュメントにも、なにがオープンソースでなにがプロプライエタリかは一切明確にされていません。

Enterprise developers may inadvertently apply a fix or enhancement to the proprietary source code. This is hard to track and govern, could lead to breach of license, and could lead to immediate termination of rights (for both proprietary free and paid).

企業の開発者にとっては、うっかりプロプライエタリなソースコードの修正や拡張をしてしまうかもしれません。その追跡や管理は困難であり、ライセンス違反を招き、(プロプライエタリの無料部分と有料部分のどちらも)権利の即時停止につながりかねません。

Individual code commits also increasingly contain both open source and proprietary code, making it very difficult for developers who want to only work on open source to contribute and participate.

個人によるコードのコミットにも、オープンソースとプロプライエタリなコードの両方が含まれていることが増加しているため、デベロッパーがオープンソースの部分にのみ参加し貢献したいと思ってもそれは非常に難しくなっています。

そしてAWSはもう1つ、イノベーションのフォーカスがオープンソースの部分から外れているのではないか、とも指摘しています。

In addition, the innovation focus has shifted from furthering the open source distribution to making the proprietary distribution popular.

加えて、イノベーションのフォーカスがオープンソースディストリビューションから、プロプライエタリなディストリビューションの人気を高めることへと変化してしまっているのです。

AWSはこうした懸念をElasticsearchの開発元であるElasticに伝えたが、一蹴されたとも説明しています。

We have discussed our concerns with Elastic, the maintainers of Elasticsearch, including offering to dedicate significant resources to help support a community-driven, non-intermingled version of Elasticsearch. They have made it clear that they intend to continue on their current path.

私たちはこうした懸念についてElasticsearchのメンテナであるElasticと議論し、またコミュニティドリブンで混在のないバージョンのElasticsearchの開発をサポートするために専用の多大なリソース提供も申し出ました。しかし彼らは現在の方針を継続することを明確にしたのです。

Open Distro for Elasticsearchはフォークではない

こうしてAWSは独自にオープンソースだけで構成された「Open Distro for Elasticsearch」を作ることになるわけです。

AWSは「Open Distro for Elasticsearch」はオリジナルのElasticsearchのフォークではないと明確に表明しています

そのため現在のOpen Distro for ElasticsearchはElasticsearch 6.5ベース(Elasticsearchの最新版は6.6.2)ですが、引き続き最新のElasticsearchのオープンソースに追随していき、またOpen Distro for ElasticsearchへのコントリビューションはオリジナルのElasticsearchへ還元するとも説明しています。

プロプライエタリ部分も公開して顧客やコミュニティと開発する戦略

ではなぜ、Elasticsearchの開発元であるElasticはこのような、オープンソースのコードとプロプライエタリのコードを混在させているとAWSから非難されるようなことをしているのでしょうか?

ElasticにはElasticなりの戦略がそこにあります。

2018年2月にサンフランシスコで行われたElasticの年次カンファレンス「Elastic{ON} 2018」で同社CEOのShay Banon氏は、それまで商用ライセンスで提供していたElasticsearchの追加機能である「X-Pack」のコードを公開することを発表します。

これはX-Packのオープンソース化ではなく、商用ライセンスのままでコードをGitHubに公開しオープンにするというものでした。

fig Elastic CEOのShay Banon氏によるX-Packのコードを公開するという発表。スクリーン右上の部分に「OPEN」と表示された

Banon氏は、オープンソースの収益化としての2つのビジネスモデル、1つはオープンソースのサポートに専念するというモデル、もう1つはオープンソースをコアに有償のクローズドなエンタープライズ版を作るというモデルのどちらも問題を抱えており、自分たちはそれ以外の選択肢として商用ライセンスを維持したままコードを公開することを選んだと説明しています。

Elasticの日本法人が、Banon氏がこれを説明したブログの日本語訳「オープンへの新たなる挑戦」を掲載しています。ポイントを引用しましょう(記事の最後には、Banon氏による発表時の動画も埋め込んでおきます)。

X-Packのコードを公開することにより、私たちのプロダクトのある部分を公開し、そのほかの部分が非公開であるという問題を解決することができます。無償機能と有償機能の両方のための問題に関して、チケット(Issue)を作ることができ、議論を見ることができ、ソースコードを調べ、私たちと共に開発し、プルリクエストを送ることが、もうすぐできるようになります。

つまりオープンソース部分もプロプライエタリ部分も顧客やコミュニティとともにオープンに開発していくというのが、同社の狙いであることが分かります。これによって商用パッケージとしてのElasticsearchを成功させていくのが戦略の柱となるのでしょう。

ただし、同社はこれまでElasticsearchでオープンソースだった部分は引き続きオープンソースであることを守っていくことも明確にしています。

そしてオープンソース部分とプロプライエタリ部分は次のように構成されると説明しています。

  • 既存のApache 2.0ライセンスのコードは、これまで同様のライセンスで変更なくメンテナンスします。
  • X-Packの新しいフォルダーを作成し、特定の派生物や貢献を許可するElastic EULAの元にx-pack-$PRODUCTのコードをそのフォルダ配下に移行します。
  • トップレベルのライセンスをシンプルなElastic Licenseに変更します。これは、このリポジトリにApache 2.0のファイルとElastic EULAのファイルが共に存在しているということを表すものです。

また、X-Packの機能がデフォルトのディストリビューションに含まれる形で提供します。

こうした同社の戦略からすれば、オープンソースだけで構成されたリポジトリやディストリビューションを作ってほしいというAWSの要請は、とても首を縦に振れるようなものではなかったことが分かります。

クラウドベンダとオープンソースベンダの行き違い

Elasticsearchをめぐって、AWSとElasticの言い分をそれぞれ見てきました。

AWSは純粋なオープンソースのコードを維持するという言い分の一方、自社のビジネスとしてElasticsearchに依存している部分があるがゆえに、コントロールしやすい独自ディストリビューションを作ったのではないか、自己都合ではないかと指摘する声は、海外でのこの件に関する議論の中であがっています(RedisやMongoDBでも似たようなことが起きるのではないか、という指摘も見ましたが、コード全体のライセンスが変わるのと、プロプライエタリなコードが混在するのでは事情が違うのではないかと思います)。

AWSが「Open Distro for Elasticsearch」がフォークではなく、アップストリームにフィードバックし、オリジナルの最新バージョンに追随していくと表明しているのは、指摘されるような自己に都合の良いフォークを作るつもりでやっているのではないことを明確にしたかったためかもしれません。

Elasticについても、オープンソースにおけるビジネスモデルを模索するためとはいえ、プロプライエタリなコードの混在をどの程度許すべきなのか、ここまで混在させてしまうのは許容されるべきなのか、少なくともそういう議論に耳を貸すべきではないか、という見方はあるでしょう。

このところ、オープンソースベンダと、AWSをはじめとするクラウドベンダの対立あるいは行き違いのような状況が目立っています。

参考:Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発

クラウドの登場というのはオープンソースが登場した頃には想定されていなかった事態でもあり、またクラウドもオープンソースの成長を支援していくうえでどのようなスタンスを取るべきなのかコンセンサスはまだありません。

オープンソースとクラウドを両立させるためにどのようなモデルがあり得るのか、しばらくは両者の摩擦や行き違いと試行錯誤が続くことになるのでしょう。

関連記事

あわせて読みたい

AWS データベース オープンソース




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本