いいえ、Redis Labsがライセンス戦略を微調整したため、Redisはプロプライエタリではなくなりました。確かに、Redis Labsの一部モジュールは、本質的に「クラウドよ、私たちにお金を支払わない限り、このコードで利益を得ることは許可されない」という奇妙な新しいライセンスハックの対象となるでしょう。そして、オープンソースの進化という観点から見ると、このハックは全く不必要でした。
ご存知の通り、これを実現する方法は既に存在します。Open Coreのような戦略は誰もが好むわけではありませんが、確立され、広く理解されており、Redis Labsの悩みをいくらか軽減できたはずです。
参照: ソフトウェア ライセンス ポリシー (Tech Pro Research)
無駄なお金…
はっきりさせておきましょう。Redis Labsの要望は合理的であり、オープンソースベンダーに共通するものです。Redis LabsはRedis Coreのライセンスには手を加えていません（ライセンスは依然として非常に寛容なBSDのままです）。しかし、同社は本来オープンソースであるソフトウェアに「コモンズ条項」を付け加え、オープンソースではないものに仕立て上げました。その理由は何でしょうか？同社の説明にあるように、少なくとも部分的にはフリーライドをやめることです。
今日のクラウドプロバイダーは、成功したオープンソースプロジェクトを悪用し、それを競争力のある独自のサービスとして再パッケージ化することで、この「オープンソースへの貢献」の精神を繰り返し侵害してきました。クラウドプロバイダーは、これらのオープンソースプロジェクトにほとんど（あるいは全く）貢献していません。むしろ、独占的性質を利用して、数億ドルもの収益を上げています…。
Redis はこのパラダイムの一例です。現在、ほとんどのクラウドプロバイダーは、自社のインフラストラクチャ上で Redis をマネージドサービスとして提供し、自社開発ではないソフトウェアから莫大な収益を得ています。Redis の許容度の高い BSD オープンソースライセンスは、これらのプロバイダーによる合法的な提供を許容していますが、これは変更が必要です。Redis Labs はオープンソース Redis の開発を主導し、資金提供も行っており、その成果を享受するに値します。そのため、オープンソース Redis の特定のコンポーネントに Commons 条項を追加することを決定しました。クラウドプロバイダーは、これらのコンポーネントを Redis-as-a-Service の一部として使用できなくなりますが、その他のユーザーにはこの変更による影響はありません。
すべては理にかなっています。オープンソースにおける「フリーライド」の良し悪しについては意見が分かれるところですが、Redis Labsのポリシー変更は、クラウドプロバイダーによるストリップマイニングへの合理的な対応と言えるでしょう。この方針変更がうまくいくかどうかは議論の余地があります。Amazon Web Services (AWS) や Microsoft Azure が、これらの Common Cause や独自モジュールをベースにしたサービスを構築する権利を金銭で支払う可能性はゼロではないでしょう。もっとも、クラウド経由でこれらのモジュールを購入することを望んでいた企業が、Redis Labs から購入せざるを得なくなる可能性は否定できませんが。しかし、このアプローチが不器用で不必要であることは疑いようがありません。（一部の人が言うように、悪事ではありません。）
確立された道
ご存知のとおり、クラウドベンダー（あるいはその他）によるフリーライド（ただ乗り）を阻止するためのオープンソースライセンス戦略は既に確立されています。最もよく使われているのはAGPL（「AWS GPL」と呼ばれることもあります）です。AGPLはGPLの有名な「ネットワーク例外」を解消します。GPLコードを実行してネットワーク経由でサービスを提供することは可能ですが、AGPLではこの場合にはコードの貢献が求められます。
もちろん、これは Redis Labs が Commons Clause で目指していることですが、やり方はより不格好です。
Cloudera、MongoDB、DataStaxなど、多くの企業はOpen Coreモデルを採用しています。これは、コードのコア部分をオープンソースのまま維持しつつ、補完的なモジュールやツールをプロプライエタリライセンスで提供するというものです。これもRedis Labsの取り組みと似ていますが、Open Coreをありのままに表現するのではなく、BSDライセンスにCommons条項を当てはめるといった奇妙な手法を用いており、「この新しいライセンスの対象となるソフトウェアは、定義上、オープンソースではない」としています。
参照: 開発者になる方法: チートシート (TechRepublic)
なぜこれらの部分をオープンなプロプライエタリライセンスでライセンスしないのでしょうか？ ライセンスの複雑な仕組みにこだわる必要があるのでしょうか？ 企業が貢献を奨励したいのであれば（「これらのプロジェクト（コモンズ条項でライセンスされているものも含む）には誰でも貢献できます」）、それはうまくいきません。開発者がプロプライエタリプロジェクトに貢献することは非常に稀です。たまにはありますが、それは例外であり、規則ではありません。
この嵐は過ぎ去りますが、私の元 MongoDB 同僚 Jared Rosoff が Twitter で次のように示唆したのはおそらく正しいでしょう。「変更の結果が物議を醸さなくても、気まぐれに変更できるプラットフォームを信頼するのは難しい。」
ブライアン・ルルー氏はさらにこう述べた。「彼らは統合とマルチクラウドに注力すべきです。これでは、基盤となる顧客層とファネル上部を遠ざけるだけで、何も解決しません。」
Redis Labs は、収益を得ようとして、自らの信頼性をいくらか失ったかもしれない。いや、そうでもないかもしれない。
Redis Labsのアプローチは不必要に複雑だったとはいえ、それが同社の長期的な将来性に深刻な悪影響を与えるとは考えにくい。いや、真の問題は、同社がこの奇妙なアプローチから利益を得られるかどうかだ。私の経験から言うと、答えは「ノー」だが、もしかしたら彼らは新たな境地を開拓するかもしれない。
