カテゴリー: CodeLibs

Fesenとは、Elasticsearchのライセンス問題を回避するためにフォークしたプロジェクトですが、FessはFesenをデフォルトの検索エンジンとして採用することで、今までどおり組み込みFesenでお試し的な簡易実行が可能になり、信頼性が求められるような環境では検索エンジンとしてElasticsearchを利用することができるようになります。

ライセンス変更が発表されてから方針検討で1日くらい考えて、フォークしてFesenを作り、Fessに組み込むというのを行いました。結構、短期間でできたかなと。なので、codelibs/fessのmasterブランチではFesenに切り替わっています。Fess 13.11からは組み込みFesenに変わります。

Fesenは、Maven化することでビルドの仕方を変えてしまったので、現時点ではzipパッケージしか作れません…。deb/rpmパッケージはそのうち作るかもしれませんが、組み込みFesenで使う分にはdeb/rpmが必要ないので、一旦、作成を保留にしようと思っています。あとは、パッケージ名をorg.elasticsearchからorg.codelibs.fesenに変えました。この点は考慮が甘かったのですが、パッケージ名を変更することで、既存のプラグインが使えなくなる問題が発生しました…。既存資産の流用はしたいところなので、fesen-plugin installをするときにasmでjarの中身を書き換えて、パッケージ問題を解決する感じにしました。なので、少なくてもFessで使うelasticsearchプラグインは動くはず…。（AWSがelasticsearchをフォークすると言っているけど、この辺をどうするのかちょっと気になっています…）

Fesenも動いたので、FessがFesenを参照するようにして、Fesen対応が完了しました。という感じで、大きくハマることなく、作業が完了できたので良かったかなと。あとは、elasticsearch 7.11がリリースされるまで、細々調整をして、準備していく感じになると思います。

elasticsearchのライセンス変更問題でのFessの対応を始めています。elasticsearch 7.10.2をフォークして、Fess用の検索エンジンとして、Fesen (フェセン: Fess Search Engine)というのを作っています。

とりあえず、現時点ではビルドして、zipパッケージを作ると起動することができるようになりました。elasticsearchの本流は、Gradleを使っていますが、私が気持ちよくメンテできるようにしていくためにはMavenである必要があるため、Maven化しました。なので、必要なソースコードは持ってきている感じですが、ビルドの仕方は全く異なります。あとは、org.elasticsearchのパッケージですが、そこもorg.codelibs.fesenに変わります。起動するコマンドも./bin/fesenになりました。ほかには、Fess観点だとKibanaとか不要なので、いらないモジュールは外しておこうかなと思っています。

結構、ハマったのが、元のテストコードたちが循環参照している感じになっているので、そのままMavenに持ってきてマルチモジュールにするとテストを実行することができず…。その辺はプロファイルを設定して、コンパイルとテストが別々になるようにして、対応しました。ただ、一部、JarHellがどうしようもないのもあるので、そのテストなどはスキップしたりしましたが…。

あとは、rpmとdebのパッケージを作るようにすれば、一段落なので、ゴールはあと少しだと思います。Fess 13.11からはFesenがデフォルトになるように（たぶん、順調に）進行中です。

ElasticsearchのライセンスがElastic LicenseとSSPLのデュアルライセンスになるということで、Fessへの影響について考えてみます。(別に私は法律家ではないので、私の理解が完全に正しいかは置いておいて…)

まず、Fessの利用者観点から考えると、ほぼすべての利用者は気にすることはない話かなと思います。サービスプロパイダで利用者にElasticsearchまで触れるようにしてしまっているとかのケースは検討だが必要だと思いますが、Fessの利用者ではこの可能性はほぼないのかなと思います。

次に、Fessを作るという開発者の観点から考えます。まずは前提として、Fess自体は今まで同様にApache Licenseを維持するということを前提に話を進めていきます。としたときに、現状ではいくつか課題があるかなと考えています。

1. elasticsearch-moduleでMaven Centralに置けない
2. elasticsearch-cluster-runnerが作れない
3. Elasticsearchのコア機能の参照

まずは、今まで、いくつかのelasticsearchのJarファイルがMaven Centralに置かれていないので、Apacheライセンスだからelasticsearch-moduleでアップロードしていたのですが、ライセンス変更により、できるのかが怪しくなりました…（怪しいので、やらない）。

そして、それらのJarファイルがMaven Centralに置けないと、elasticsearch-cluster-runnerが作れなくなります。elasticsearch-cluster-runnerはFessで組み込みElasticsearchを動かしたり、ElasticsearchのAPIを使えるようにしてくれています。なので、これが使えなくなるとFessも作れない感じです。

ということに加えて、FessはTransportClient時代からElasticsearch APIを内部的に結構使っていたりするので、コードレベルでは依存度は高い感じで、SSPLのようなGPLから派生したライセンスだと、Fess自体もSSPLに変更しないと厳しい感じだと思います。

という感じで、開発者観点から考えると、わかっている範囲でも厳しい感じです。なので、ここ数日、どのように対応するかを検討していました。Solrに戻ることも案としては検討したのですが、結構な工数になり、短期では解決できなそうなので、現時点では

1. elasticsearch 7.10.2をフォークして、デフォルトの検索エンジンとして利用する
2. 利用者は、デフォルトの検索エンジン または elasticsearchを選択して利用する
3. elasticsearchプラグインの依存度を減らす

を軸に変更して、Apacheライセンスを維持することを考えています。elasticsearchはフォークした後は、最新のElasticsearchとインターフェースを追随する実装は必要な気はするので、Elasticsearchの外部仕様をもとにFessで必要な機能だけは対応しようかなとは思っています。(AWSのOpen Distroがもっと頑張ってくれていれば、それをベースにとも考えたのですが、そんな感じでなくて、Open Distroも消えるのではないかなという気もしたので…)

あとは、Elasticsearchプラグインの依存を減らしてメンテ工数を下げていこうとも考えています。プラグインの依存度が下がれば、SaaSのelasticsearchとかも使えるようになる可能性もふえますし。

という感じで進んでいくと思うので、Fess 13.11から変わる予定で考えています。