ElasticsearchをめぐるAWSとElasticの対立

(blog.opsnow.com)

12 ポイント投稿者 lamanus 2021-01-24 | 10件のコメント | WhatsAppで共有

最近報じられた、Elasticsearchのオープンソース放棄、SSPL宣言、そしてAWSが別途フォークしてApache License 2.0のオープンソースコミュニティを維持するという記事に触れ、過去から続いてきた両者の対立を要約してみました。

途中で不足している点や誤りがあれば、コメントをいただければ反映する予定です。

10件のコメント

kbumsik 2021-01-24

個人的には、OSIがなぜSSPLのオープンソースライセンス認定を取り消したのか、よく理解できません。AGPLをもう少し具体化したライセンスで、SaaS事業者にすべてのソースを公開させるものだと理解していたのですが、OSIがこれをSaaSを「制限」するものだと解釈しているのが、いまひとつ腑に落ちません。

OSIの立場表明 1 を見ても、ElasticがSSPLを導入した意図を問題視しているだけで、SSPLのどの条項が利用を「制限」しているのかは説明していません。内容を読んでも、AGPLに比べてどこに「制限」があるのか、よくわかりません。私がライセンスの解釈を間違えているのでしょうか……。

lamanus 2021-01-24

ライセンス申請を取り下げたのはMongoDBでした。OSIが却下したわけではありません。もちろんOSI側でも、議論の余地がある部分についてはオープンソースとして認めるのは難しいという反応ではありましたが、このような状況を事前に把握し、MongoDB側が申請を撤回してしまったのです。

kbumsik 2021-01-24

ご指摘ありがとうございます。私の説明が少し不正確でしたね。それでもMongoDBのほうが先に撤回したのは確かですが、リンク先で示されているOSIの投稿を見ても、OSIは現行版のSSPLを受け入れる考えがないことを明確にしているので……前後関係はそれほど重要ではないように見えます。

lamanus 2021-01-24

同意します。^^

galadbran 2021-01-24

私もちょっと疑問があって調べているのですが、こういう資料があったのでリンクしておきます。

https://ceart.kr/component/file/…

抜粋

まず、SSPLがAGPLと異なる点は次のとおりです。従来のAGPLは、あるソフトウェアが配布されずサーバーサイドで実行される場合でも、GPLと同様に、サービス提供者がそのソフトウェアに対して行った修正および追加部分のすべてのソースコードを公開しなければならないというもので、サーバーそのものに限定しているのに対し、

SSPLは当該コードだけでなく、As-a-Serviceの形で提供する際に付随的に必要となる管理ソフトウェア、ユーザーインターフェース、API、自動化ソフトウェア、監視ソフトウェア、バックアップおよび保存ソフトウェアなど、As-a-Serviceの利用者が実行するすべてのソフトウェアのコードを公開しなければならないという条件です。言い換えれば、クラウド事業者がMongoDBをサービス形態で提供する際、自らのサービスの競争優位を維持するために作成したあらゆるソフトウェアのソースコードまで、すべて公開しなければならないという条件なのです.

lamanus 2021-01-24

MongoDBやRedisについても調べてみようと思っていたのですが……ここにうまく説明されていたんですね！

galadbran 2021-01-24

補足として、pdfをご覧になると、OSIに準拠していない部分がどのような内容なのかという説明もあります。自由の制約と、別個の著作物に対する制限という点だそうです。

kbumsik 2021-01-24

おお…全体的によくまとまった素晴らしいPDFですね。リンクありがとうございます。

こうして見ると、AGPLとの違いや、SSPLが許可されない理由は理解できますが、OSIはややパーミッシブ寄りに偏っているのではないかという気もします。

xguru 2021-01-24

全体の経緯がよく整理されていて、気楽に読めました。ありがとうございます！

lamanus 2021-01-24

ElasticsearchをめぐるAWSとElasticの対立

関連記事

10件のコメント