オープンソース企業はどのように収益を上げているのか

著者: Brian Tr · 更新日: 2026年10月2日

オープンソース企業は、中核となる製品を無償で提供しながら、それでも従業員に給与を支払わなければなりません。矛盾しているように聞こえますし、このモデルについて創業者も投資家も最初に抱く疑問です。答えは、売っているのはコードそのものではないことがほとんどだ、という点にあります。顧客が対価を払うのは、コードの周りにあるもの、つまり運用してくれる人、サポート、認定、拡張、あるいは法的責任の引き受けです。

本記事では、「オープンソース」が実際に何を意味するのか、企業がそれを収益に変える主な方法、そして2021年から2026年にかけて著名な企業がいくつもライセンスを変更するに至った緊張関係を解説します。ビジネスモデルに関するリファレンスであり、法的助言ではなく、各ベンダーの現在の価格比較もしていません。スタートアップが収益を上げる方法をより広く知りたい方は、SaaSの価格モデルをご覧ください。

「オープンソース」が実際に意味するもの

「オープンソース」は、「無料」や「コードが公開されている」の言い換えではありません。Open Source Initiative（OSI）は、ライセンスが満たすべき10の基準を定めたOpen Source Definitionを管理しています。ビジネスモデルにとって特に重要なのは、次の3つです。

• 自由な再頒布。 ライセンスは、誰かがそのソフトウェアを販売したり無償で配布したりすることを妨げてはなりません。
• 派生物。 ライセンスは、改変と派生物を認めなければなりません。
• 利用分野に対する差別の禁止。 ライセンスは、特定の分野でプログラムを利用することを制限してはならず、実際には商用での運用も含まれます。

最後の基準は、ビジネスモデルと定義が衝突するところです。「誰でも使ってよいが、競合するホスティングサービスとして販売することは除く」というライセンスは、利用分野を制限していることになります。商業上の選択としては十分に合理的かもしれませんが、OSIの解釈ではオープンソースではありません。OSIは、Server Side Public License（SSPL）について2021年1月の声明でまさにこの点を述べ、そのようなソフトウェアをオープンソースと称する行為を欺瞞と呼びました。

つまり、実際には2つの陣営があります。

本記事の以降の部分では、この2つを区別して扱います。この区別は、顧客（何をしてよいのか）、コントリビューター（自分の成果はオープンなままか）、創業者（何を約束できるのか）にとって重要です。

中核を無料で提供するというパラドックス

誰でも無料でダウンロードし、改変し、実行できるなら、なぜ誰かが対価を払うのでしょうか。オープンソース企業は、次の4つのいずれかで答えます。

1. 負担を減らす。 ソフトウェアをうまく運用するのは難しいものです。顧客は、他者に運用を任せるために支払います。
2. リスクを減らす。 大企業は、問い合わせ先となるベンダー、セキュリティ対応チーム、法的な保証を求めます。
3. 無償版にないものを加える。 主に大規模なチームにとって重要な機能（アクセス制御、監査ログ、シングルサインオン）は、別売りされます。
4. 課金する権利を守る。 コードは読めるように公開したまま、再販できる相手を制限する企業もあります。

中核を無償で提供することは、ディストリビューション（流通経路）としても機能します。開発者は、調達プロセスを経ずに試せるものを採用し、その採用を勝ち取った企業はインバウンドの販売チャネルを手にします。これはプロダクト主導型成長やフリーミアムのビジネスモデルの論理に近いものですが、1つ違いがあります。オープンソースソフトウェアの無料ユーザーは、コードをフォークし、自分でホスティングして、顧客にならないこともできるのです。

主な収益化モデル

1. サポートとサブスクリプション（Red Hatモデル）

最も古いモデルは、無料のソフトウェアの周りに保証を売るものです。Red Hatが代表的な例です。IBMが2018年10月に発表した、1株あたり190ドル、企業価値約340億ドルでRed Hatを買収する合意の発表では、同社をLinux、ハイブリッドクラウド、コンテナ、Kubernetes技術などを含む、エンタープライズ向けオープンソースソフトウェアの大手プロバイダーと説明しています。

Red Hatの顧客は、何に対して支払っているのでしょうか。同社自身のサブスクリプションFAQには、パッチ、バグ修正、アップデートとアップグレード、24時間365日対応の技術サポート、ハードウェア、ソフトウェア、クラウドプロバイダーによる認定が挙げられています。また、サブスクリプションを失効させた顧客は、セキュリティ情報（errata）、バグ修正、技術サポートを受けられなくなるとも明記しています。つまり、製品とはソースコードそのものではなく、保守され、認定され、サポートされるバージョンなのです。

向いている場面： 大企業が本番環境で運用し、障害を許容できないインフラ系ソフトウェア。 苦手な場面： 営業は遅く負担が重く、このモデルはダウンロード数ではなく、人と信頼によってスケールします。

2. オープンコア

オープンコアの企業では、基本となる製品はオープンソースで、追加の機能群はプロプライエタリで有料です。追加分は通常、大企業が求めるもの、つまり高度なセキュリティ、ガバナンス、スケーラビリティのためのツール、公式のインテグレーション、専任のサポートです。

戦略上の問いは、どこに線を引くかです。無償版に入れるものが少なすぎると、コミュニティには採用する理由がなくなります。入れすぎると、誰にも支払う理由がなくなります。創業者は、単純な基準を使うことがよくあります。個々の開発者を助ける機能は無料のままにし、組織の調整を助ける機能（権限、コンプライアンス、管理）は有料にするというものです。

リスクは信頼です。企業が機能を無償ティアから有料ティアへ移すと、コミュニティはそれを裏切りと受け取ることがあり、フォークにつながることもあります。

3. マネージドクラウド（ホスティングサービス）

現代のオープンソース収益の大半は、顧客のためにソフトウェアを運用することから生まれています。企業がホスティングし、アップグレード、バックアップ、スケーリングを担い、利用量や容量に応じて課金します。これはオープンソース製品に適用されたSaaSモデルであり、価格設定の仕組みは従量課金型プライシングで扱っています。

MongoDBは、この規模がどこまで大きくなりうるかを示しています。2026会計年度の決算発表（2026年1月31日終了の会計年度）で、MongoDBは総収益24億6,000万ドルを報告し、そのうちクラウドサービスのAtlasがおよそ18億1,000万ドル、約73％を占めました。これは1社の会計年度の数字であり、業界のベンチマークではありません。またMongoDBの中核となるデータベースはオープンソースではなくソース公開型です（詳しくは後述します）。

向いている場面： 運用が大変な製品で、利便性に対価を払う価値があるもの。 苦手な場面： クラウドのアカウントを持つ誰もが、最大手のクラウドプロバイダーを含め、同じサービスを提供できること。これが、後述するライセンスをめぐる争いの根っこにあります。

4. デュアルライセンス

デュアルライセンスでは、同じコードが2つのライセンスで提供されます。1つは無償で、多くの場合コピーレフトのライセンスであり、その上に構築する者に、自分のソースコードも同じ条件で共有することを求めます。もう1つは有償の商用ライセンスで、その義務を負わずにソフトウェアをクローズドな製品に組み込みたい企業向けです。

他社が自社製品に組み込むライブラリやコンポーネントに最も適しています。コピーレフト条項の免除を誰も必要としないエンドユーザー向けアプリケーションには、あまり向きません。また通常、企業がライセンスを変更する権利を保有している必要があり、そこでコントリビューター契約が関わってきます（後述）。

5. ソース公開型とライセンス変更

現在、成長しているグループの企業が、商用利用を制限するライセンスの下でソースコードを公開しています。多くは、競合他社が製品をホスティングサービスとして再販するのを防ぐためです。代表的な例は、SSPL、Business Source License、フェアコード型のライセンスです。これらのライセンスは、顧客がコードを読み、実行し、改変することを認めつつ、サービスとして販売する独占的な権利をベンダーが保持できるようにします。

こうしたライセンスの中には、一定期間の後に完全なオープンライセンスへ移行するものもあります。今の先行者利益を守りながら、いずれはオープンにするという約束をする方法です。

6. 寄付、スポンサーシップ、財団

すべてのオープンソースプロジェクトが企業というわけではありません。多くはボランティアが保守し、スポンサーが資金を提供し、あるいは財団に所属しています。たとえばApache Software Foundationは、ソフトウェアをめぐって法的な紛争が起きた際にプロジェクトを防御できるよう、主要なコントリビューターに個人のコントリビューターライセンス契約への署名を求めています。財団はプロジェクトに中立的なガバナンスと法的な保護をもたらしますが、創業者に報酬を支払うわけではありません。財団のプロジェクトの周りに商用の企業が育ち、サポートやホスティングを販売することが多く、それがモデル1から3に還元されます。

モデルの比較

実際の企業の多くは、複数のモデルを組み合わせています。典型的な製品には、無償のオープンコア、ホスティング版、エンタープライズ向けティア、そしてサポートの選択肢があります。

ハイパースケーラー問題と2021年から2026年のライセンス変更の波

マネージドクラウドは最も収益性の高いモデルですが、より大きな競合が最も簡単に真似できるモデルでもあります。ライセンスが許せば、クラウドプロバイダーはオープンソースのデータベースやツールをホスティングし、それで課金して、ほとんど還元しないことができます。オープンソースのベンダーは、これを「ストリップマイニング（収奪的な採掘）」と呼びます。

複数の企業が、ライセンスの変更で対応しました。以下の発表は、いずれも各社自身によるものです。

これらの発表をまとめて読むと、いくつか目立つ点があります。

理由には一貫性がある。 Elasticは、プロバイダーが還元せずに自社ソフトウェアをサービスとして提供するのを止めるための変更だと述べました。HashiCorpは、オープンソースの成果から恩恵を受けながら貢献しないベンダーがいると主張しました。Redisは、商用の売上の大半が最大手のクラウドサービスプロバイダー経由だったと述べました。

呼称に対する誠実さが問われる。 Redisは、新しいライセンスがOSIの定義を満たさないことを明言し、無償版をオープンソースではなく「Community Edition」と呼ぶとしました。OSIもSSPLについて同じ見解を示しています。

巻き戻しも起きる。 ElasticとRedisはいずれも、後からOSIが承認したAGPLを選択肢に加えました。Redisは以前の変更がコミュニティとの関係を損なったと述べ、Elasticは自社の動きがAmazonの慣行への懸念によるものだったが、状況はその後変わったと述べています。創業者にとっての教訓は、1つのライセンスが正解だということではありません。ライセンスの変更は、数年にわたって続きうるコミュニティへのコストを伴う経営判断だということです。

時間の制限を組み込んだライセンスもある。 Directusは、同社のソフトウェアのすべてのバージョンが4年後にGPLv3の下で完全なオープンソースになり、しきい値として、年間売上500万ドル未満かつ従業員50人未満の組織は無償で利用できると説明しています。時間差で移行するライセンスは、今はベンダーを守りつつ、のちにオープンソースの約束を果たそうとするものです。

コミュニティと収益：中核となる緊張関係

商用オープンソース企業は、常に対立を抱えています。コミュニティは、安定した、無償で、寛容にライセンスされたソフトウェアを求めます。投資家と従業員は、成長する収益を求めます。収益化に関するあらゆる判断が、このバランスを動かします。

実務上の圧力がかかる点は、次のとおりです。

• 機能の制限（ゲーティング）。 既存の機能を有料の壁の向こうに移すことは、ユーザーとコントリビューターに対する暗黙の約束を破ることになります。
• ガバナンス。 1社がロードマップを握ると、外部のコントリビューターが離れていくことがあります。財団は中立的な管理を提供しますが、企業の手から一部の権限を奪います。
• フォーク。 ライセンスの変更がコミュニティの相当数を怒らせると、寛容なライセンスの下でフォークが登場することがあります。フォークは古いコードを引き継ぎ、企業が締め出そうとしたクラウドプロバイダーを引き寄せる可能性があります。
• 商標。 コードを自由にコピーできる場合でも、名称は通常そうではありません。たとえばRedisは現在、商標ポリシーにより、他の製品名での「Redis」の使用を制限しています。

コントリビューターライセンス契約

コントリビューターライセンス契約（CLA）とは、コントリビューターが自分の貢献を利用するために必要な権利をプロジェクトに付与する文書です。Apache Software FoundationのICLAの趣旨説明が示すように、財団は法的な明確さのためにこれを利用しています。

企業にとってCLAには、もう1つの目的があります。必要な権利を企業が保有するため、のちにライセンスを変更したり、商用ライセンスの下でコードを販売したりできるようになることです。たとえばRedisは、貢献を検討する前に、コントリビューターにCLAへの同意を求めていると述べています。

コントリビューターは、CLAを一方通行の取り決めと感じることがあります。コミュニティの好意を保ちたい企業は、なぜCLAを求めるのか、その見返りに何を約束するのかを明確にすべきです。

スタートアップにとっての意味

オープンソースのビジネスモデルを検討しているなら、早い段階で検討しておくべき問いがいくつかあります。

1. コードが無料なら、顧客は何に対して支払うのか。 利便性、リスクの低減、機能、あるいは許諾です。名前を挙げられないなら、まだビジネスモデルがありません。
2. 誰があなたの製品を再販できるか。 答えが「どのクラウドプロバイダーでも」なら、後から変更するのは高くつくため、最初からそれを念頭にライセンスを選んでください。
3. コミュニティの信頼をどう得るか。 有料の壁の向こうには決して移さないものを決め、それを書き残しておきます。
4. 経済性を理解しているか。 無料ユーザーにも提供とサポートのコストがかかります。ダウンロード総数ではなく、有料セグメントのユニットエコノミクスを追跡してください。
5. コード以外に堀はあるか。 ブランド、ホスティングの専門性、エコシステム、データは、ライセンスよりも重要になることがあります。経済的な堀の記事でこの考え方を詳しく扱っており、大規模な開発者コミュニティが製品の価値を高める場合には、ネットワーク効果が働くこともあります。

特に初期段階のチームは、決める前に、このモデルをプラットフォームのビジネスモデルなど他の選択肢と比較してください。

ライセンスやコントリビューター契約に関する慣行は、国や投資家によって異なります。創業者は、自身の状況について法律の専門家の助言を受けてください。特に東南アジアにおけるオープンソースのビジネス慣行について、信頼できる比較資料は見つかっていません。

重要なポイント

• OSIのOpen Source Definitionには10の基準があり、最後の改訂は2007年です。そのうちの1つが、利用分野に対する制限を禁じています。
• OSIは2021年1月に、SSPLはオープンソースのライセンスではないと表明しました。
• IBMは2018年10月、1株あたり190ドル、企業価値約340億ドルでRed Hatを買収すると発表しました。
• Red HatのサブスクリプションFAQは、パッチ、アップデート、サポート、認定を、サブスクリプションが提供するものとして挙げています。
• MongoDBのAtlasは、2026会計年度の収益24億6,000万ドルの約73％を生み出しました。
• Elasticは2021年1月にSSPLへ移行し、2024年8月にAGPLを追加しました。
• HashiCorpは2023年8月にBSL 1.1を採用しました。
• Redisは2024年3月にソース公開型へ移行し、2025年5月にAGPLv3を追加しました。
• NocoDBとDirectusは、いずれも2026年にソース公開型のライセンスへ移行しました。
• ソース公開型のライセンスは、コードが公開されていても、OSIが定めるオープンソースではありません。

関連記事

• フリーミアムのビジネスモデル
• プロダクト主導型成長
• 経済的な堀
• ハードウェアスタートアップのビジネスモデル
• SaaSの価格モデル
• プラットフォームのビジネスモデル