ソースコードを公開したまま収益を守る｜非競合ライセンスの設計

ソフトウェアを無料で公開しながら会社として売上を立てる方法は、長いあいだ「無料の本体で広めて、有料の機能やサポートで回収する」と説明されてきました。ところが2023年以降、海外のソフトウェア企業がもっと直接的な手を打っています。売る商品を変えるのではなく、配布するときの条件文そのものを書き換えました。HashiCorpは2023年8月10日に Business Source License 1.1 を採用し、Sentryは同年11月17日に Functional Source License を公開しています。Redisは2024年3月20日にBSDライセンスをやめ、Elasticは2024年8月29日にAGPLを選択肢へ戻しました。

これらは値上げでも機能制限でもありません。コードは誰でも読めるまま、特定の使い方だけを止めるという設計です。止めているのは「誰が使うか」ではなく「第三者へどう提供するか」で、社内で本番運用する分にはほとんど影響しません。逆に、他社のコードを載せてサービスを売る側は、条文を読まずに進めると契約違反になります。

この記事では、各社の公式発表と実際のライセンス条文に書かれている範囲だけを使い、3点を整理します。何が「競合」として止められているのか。期限が来ると何が起きるのか。そして「オープンソース」と名乗れる線はどこに引かれているのか。金額や利用者数は各社が公表していないため扱いません。確認日は2026年9月14日です。

配布条件は、いま3つの型に分かれている

ライセンスという言葉で一括りにすると見えなくなりますが、いま使われている配布条件は、第三者による再提供の扱いで3つに分かれます。

型	代表的なライセンス	第三者が競合サービスとして提供できるか	時間が経つとどうなるか	OSIの承認
承認された開かれた条件	AGPLv3、Apache 2.0、MPL 2.0	できる（各条件を満たす限り）	変わらない	あり
ソース利用可能（非競合）	RSALv2、SSPLv1	できない、または条件つき	変わらない	なし
期限つきで開く	BUSL 1.1、FSL 1.1	期限までは、できない	指定した開かれた条件へ切り替わる	切り替わった後は該当

3つとも、ソースコードそのものは公開されています。読むこと、手元で動かすこと、直すことは、どの型でもできます。分かれるのは、直したものを第三者へ売るときの扱いだけです。

画面に表示されたプログラムのソースコードの接写 — どの型でも、コードそのものは公開されていて読めます。制限がかかるのは読むことではなく、第三者への提供のしかたです。写真はイメージで、特定の製品の画面ではありません。写真: Daniil Komov（Pexels）

ここを混同すると、社内の検討がねじれます。「オープンソースではないから使えない」と判断して見送った製品が、実際には自社の用途では何の制限もかからなかった、ということが起こります。読むべきなのはライセンスの名前ではなく、自社がやろうとしている提供の形が、その条文のどの行に当たるかです。

2021年から2025年までの5年間で、条件は行ったり来たりしている

変更は一方向ではありません。厳しくする動きと、戻す動きが同時に起きています。

2021年1月のElasticの二重ライセンス化から、2023年8月のHashiCorpのBusiness Source License採用、2023年11月のSentryによるFunctional Source License公開、2024年3月のRedisのBSD離脱、2024年8月のElasticのAGPL追加、2025年2月のIBMによるHashiCorp買収完了、2025年5月のRedisのAGPLv3追加までを時期順に並べた年表 — 薄い黄色の行が、開かれたライセンスを選べるようにした変更です。厳しくした年と、戻した年が交互に並んでいます。出典：HashiCorp公式ブログ、Elastic公式ブログ、Redis公式ブログ（確認日 2026-09-14）

きっかけとして各社が公式に挙げているのは、クラウド事業者の存在です。Redisは2024年3月の発表で、自社の商用売上の大半が大手クラウド事業者の経路を通っており、そこでRedisの投資とコミュニティが汎用品として扱われている、という趣旨の説明を出しました。Elasticは2021年1月の発表で、Amazonが提供していた競合サービスによって市場で混乱が生じたことを理由に挙げています。

理由の書き方は各社で違いますが、共通しているのは自社が書いたコードを、自社と同じ売り方で第三者が提供する状態を問題として名指ししている点です。開発者個人や導入企業の使い方を問題視した発表は、確認した範囲では見当たりません。

非競合条項が止めているのは、提供の形だけ

では条文は何を禁止しているのか。実際の文言を見ると、対象はかなり狭く書かれています。

Terraform のリポジトリにある LICENSE ファイルは、BUSL 1.1 のパラメータを埋めた形になっています。Additional Use Grant の欄には、本番利用を認めたうえで、IBM の有償版と競合する目的でホスティングまたは組み込みの形で第三者へ提供する場合を除く、という条件が書かれています。Licensor の欄は International Business Machines Corporation です。

Redisは2024年3月の発表に付けたFAQで、「競合するオファリング」を、Redisのコードベースから派生し、Redisの商用製品の機能と大きく重なる形で第三者へ販売される製品だと説明しています。同じFAQには、組織内での本番利用は可能であること、系列会社や部門間での提供も組織内に含まれること、導入や運用を支援する専門サービスの提供を妨げる意図はないことが、それぞれ書かれています。

FSL 1.1 の条文では、許される目的を「競合利用以外のすべて」と定め、競合利用を、当該ソフトウェアの代替となる商用の製品やサービス、提供元が既に出している製品の代替、または実質的に同等の機能を提供するもの、と定義しています。あわせて、社内利用、非営利の教育と研究、すでに同条件の許諾を受けている顧客への専門サービスは明示的に認められています。

ソース利用可能ライセンスのコードを使う3つの場面と判定を示した分岐図。自社の組織内での本番運用と、導入支援や受託開発などの専門サービスは許可され、第三者へホスティングや組み込みで提供して提供元の商用版と重なる場合だけが許可されないことを示している — 3社の条文とFAQに共通する判定の分かれ目です。使う人の属性ではなく、第三者へ再提供するかどうかで分かれます。出典：Redis公式ブログのFAQ、FSL 1.1 の条文（確認日 2026-09-14）

自社の判断に落とすと、確認すべきことは1つに絞れます。そのコードを載せた成果物を、社外の第三者へ渡して対価を得るのか。渡さないなら、影響は小さく収まります。渡すなら、渡し方が提供元の商用版と重なっていないかを条文の言葉で照合し、重なるなら商用の許諾を別途取る、という順番になります。判断に迷う範囲は条文だけでは決まらないため、進める前に法務へ相談してください。この記事は条文の所在と読み方を整理したもので、個別の契約適合を判断するものではありません。

期限つきで開くという第三の設計

非競合条項をずっと残す設計とは別に、期限が来たら自動的に開かれた条件へ切り替える型があります。

BUSL 1.1 の条文は、Change Date か、そのバージョンが最初に公開されてから4年目の応当日のどちらか早い日に、Change License として指定した条件が有効になると定めています。Change License には GPL バージョン2以降、または GPL と互換性のある条件を指定することが求められます。Terraform の LICENSE では、Change License に MPL 2.0、Change Date に公開から4年が入っています。

FSL 1.1 は、この考え方をより短い期間で実装したものです。条文には、ソフトウェアを公開した日の2年目の応当日に発効する追加の許諾として、Apache 2.0（もう一方の版ではMIT）のもとで利用する権利を取り消し不能な形で与える、と書かれています。

期限つきで開くライセンスの時間経過を示す横棒図。FSL 1.1 は公開から2年でApache 2.0またはMITへ、BUSL 1.1のTerraformの設定は公開から4年でMPL 2.0へ切り替わることを、0年から5年の目盛りの上に示している — 横軸は、そのバージョンを公開してから経過した年数です。黒い区間だけが非競合の制限がかかる期間で、その先は転換先の条件でも使えるようになります。出典：Business Source License 1.1 の条文、Terraform の LICENSE（確認日 2026-09-14）

この設計を、Sentryは Fair Source という名前で定義にまとめています。fair.io に載っている定義は3つの条件で、公開されていて誰でも読めること、提供元の事業を守るための最小限の制限のもとで利用・改変・再配布を認めること、そして遅延つきのオープンソース公開（DOSP）を行うこと、です。同サイトによると、この取り組みは2023年にChefの共同創業者Adam Jacobが出した呼びかけを受けて、2024年にSentryが始めたものです。Fair Source として挙げられているライセンスは FSL、Fair Core License、Business Source License の3つです。

守られているのは「いま売っている最新版」だけだ、という点が重要です。4年前や2年前のバージョンは、期限が来た時点で誰でも競合サービスに使えます。開発を止めた瞬間に、守りが年単位で消えていく設計でもあります。継続して新しい版を出し続ける体力がある会社でなければ成立しません。

「オープンソース」と名乗れるかどうかは、定義側で決まっている

ここまでの型のうち、非競合条項が残っているものは、Open Source Initiative（OSI）が公開している The Open Source Definition の条件を満たしません。

定義の6番目は、特定の活動分野での利用を制限してはならないと定めており、例として、事業での利用を制限したり、遺伝子研究での利用を制限したりしてはならない、と書かれています。5番目は、個人や集団を差別してはならないと定めています。「クラウド事業者が競合サービスとして提供する場合を除く」という条件は、この行に当たります。

この判定を、変更した側自身が明記しています。Redisは2024年3月のFAQで、今回の変更によりRedisはOSIの定義におけるオープンソースではなくなることを率直に認める、と書きました。2025年5月の発表でも、SSPLは真のオープンソースではなく、OSIが必要な要件を欠くと明確にした、と説明しています。

名乗りの問題は、体裁だけの話ではありません。配布の可否、社内の調達基準、Linuxディストリビューションへの収録など、後続の判断が「OSI承認かどうか」で自動的に分かれる場面があります。だからこそ、2024年から2025年にかけて、承認済みの条件を選択肢として戻す動きが出ています。

戻す判断も、同じ理由の裏返しで起きている

Elasticは2024年8月29日の発表で、AGPLを ELv2 と SSPL の隣にもう1つの選択肢として追加すると書きました。同じ発表の中で、これは単に選択肢を追加するものであって、何かを取り除くものではない、と明言しています。理由として挙げられているのは、Amazonが自らのフォークに投資したこと、市場の混乱が解消したこと、AWSとの関係が以前より強くなったことです。AGPLを選んだ理由については、OSIが承認したライセンスであることと、MongoDBやGrafanaが使ってきた実績が挙げられています。

Redisは2025年5月1日、Redis 8 からAGPLを追加の選択肢とすると発表しました。同じ記事で、2024年3月のSSPLへの移行は、AWSとGoogleが自前のフォークを維持するという当初の目的を達成した一方で、コミュニティとの関係を損ねた、と振り返っています。2024年11月にRedisの原作者であるSalvatore Sanfilippo氏が同社へ復帰したことも、判断の背景として説明されています。

現在の各社の状態を並べると、次のようになります。

企業・製品	いまの配布条件	時期	承認された条件を選べるか
HashiCorp（IBM）／Terraform	BUSL 1.1。Change License は MPL 2.0、Change Date は公開から4年	2023年8月	期限が来た版から該当
Elastic／Elasticsearch・Kibana	AGPL・ELv2・SSPL から選択	2024年8月	選べる（AGPL）
Redis／Redis Open Source	RSALv2・SSPLv1・AGPLv3 から選択（Redis 8 以降）	2025年5月	選べる（AGPLv3）
Functional Source License	公開から2年で Apache 2.0 または MIT へ転換	2023年11月	転換した版から該当

Redisの案内によれば、7.2以前はBSD 3-Clause、7.4はRSALv2かSSPLv1、8.0以降はそこにAGPLv3が加わった3択です。古い版の条件は後から取り消されていません。Redisは2024年3月のFAQで、ライセンス変更は遡及しないこと、変更前のソースコードとリリースはBSD 3-Clauseのまま残ることを明記しています。

条件を採用する側・使う側が確認する順番

読者の立場が「使う側」なら、確認は次の順で足ります。まず、自社の用途が社内利用か、第三者への再提供かを決めます。社内利用なら、ここまで見た3社の条文とFAQの範囲では制限はかかりません。再提供なら、そのサービスが提供元の商用版と機能面で重なるかどうかを条文の定義に当てて確認します。重なるなら、商用の許諾が別に要ります。

もう1つ、買収の影響も見ておいてください。Terraform の LICENSE の Licensor 欄は、いま International Business Machines Corporation です。IBMは2025年2月27日にHashiCorpの買収完了を発表しました。ライセンスの条件は、提供元の資本が変わってもそのまま引き継がれます。相手が誰になるかは変わりうるので、長期に依存する部品ほど、転換先と転換時期を控えておく価値があります。

「採用する側」、つまり自社のコードを公開しようとする立場なら、決めることは2つです。守りたいのは最新版だけでよいのか、それとも将来にわたって競合提供を止めたいのか。前者なら期限つきで開く型が候補になり、後者ならソース利用可能の型になります。そして、OSI承認を名乗れるかどうかが、自社の顧客の調達要件に効くのかどうかを先に確かめてください。ここが効く相手を売り先にしているなら、承認された条件を選択肢として残す設計が現実的です。

収益の受け取り方そのものは、この記事の範囲ではありません。請求が立つ瞬間を後ろへずらす設計はAIエージェントの成果課金の記事で、自分でホストできる製品の費用と条件の見え方はPlausibleの料金と自己ホストの記事で扱っています。

確認できなかったこと

公表されていないため、この記事では扱っていない項目があります。

ライセンスの変更が各社の売上や契約数にどう影響したかは、今回確認した公式ページには記載がありません。非競合条項を根拠に結ばれた商用契約の件数も同様です。Sentryが自社の製品のどこまでにFSLを適用しているかについても、確認した範囲のページでは判断できませんでした。FSLを公開した事実と条文の内容までが、確かめられた範囲です。

各社が条文で使う「競合」の定義が、具体的にどの製品まで及ぶのかも、条文の文言以上のことは分かりません。Redisは判断に迷う場合の問い合わせ先を案内しており、個別の事案は各社との確認事項として扱われています。推測で線を引かないでください。

要点の整理

海外のソフトウェア企業は、ソースコードの公開をやめずに、配布条件のほうを書き換えて収益を守る設計へ動きました。止めているのは、第三者が提供元の商用版と重なる形でホスティングまたは組み込みの提供を行うことで、社内での本番運用や、導入支援・受託開発などの専門サービスは、各社の条文とFAQの範囲では対象外です。

期限つきで開く型は、BUSL 1.1 が Change Date か最初の公開から4年目の早いほうで転換し、FSL 1.1 が公開から2年目に Apache 2.0 または MIT の許諾を加えます。Fair Source は、公開されていること、最小限の制限であること、遅延つきのオープンソース公開を行うことの3条件で定義されています。

非競合条項が残るものは、OSIの定義における活動分野の制限に当たるため、オープンソースとは呼べません。Redisは自らそれを明記しました。そのうえでElasticは2024年8月にAGPLを、Redisは2025年5月にAGPLv3を、それぞれ選択肢として追加しています。

自社で判断するときは、ライセンスの名前ではなく、第三者への再提供の有無から見てください。そこが「なし」なら、多くの場合は条件の外側にいます。

出典と注記

本記事の記載は、HashiCorpの2023年8月10日の公式ブログ、MariaDBが公開する Business Source License 1.1 の条文、Terraform リポジトリの LICENSE ファイル、Elasticの2021年1月14日および2024年8月29日の公式ブログ、Redisの2024年3月20日および2025年5月1日の公式ブログとライセンス案内、Sentryの2023年11月17日の公式ブログ、Functional Source License 1.1 の条文、fair.io の定義ページ、Open Source Initiative の The Open Source Definition、IBMの2025年2月27日のニュースリリースにもとづきます（確認日 2026年9月14日）。

ライセンスの条件は改定されることがあり、各社が将来さらに変更する可能性があります。実際に採用・利用する際は、その時点の条文を各社の公式ページで確認してください。本記事は条文と公式発表の内容を整理したものであり、個別の利用が契約や法令に適合するかを判断するものではありません。判断が必要な場面では、事前に法務の確認を取ってください。