結城です。

近年、「オープンソースからの離脱」の事例が度々観測されています。 記憶に残る大きなニュースでは、2018年から2019年にかけてのRedis、MongoDBなどのプロジェクトの相次ぐライセンス変更がありました。 最近も、HashiCorp社がTerraformを非オープンソースライセンスに変更したことが話題となりました。 オープンソースからの離脱というわけではありませんが、RedHat社がRedHat Enterprise Linux（RHEL）のソースコードリポジトリの一般公開を取りやめて、ソースへのアクセスを自社のサポートサービス契約者のみに限定した事も、この流れと無関係ではないでしょう¹。

このような状況を見ていて、「オープンソースって、もうアカンの？　これからはSource Available？」「業務でオープンソース開発プロジェクトにコミットメントしても大丈夫なの？　将来性はあるの？」といった不安を抱いている人もいるのではないかと、オープンソース開発に参加していきたい企業のお手伝いを業務で行っている筆者は憂えています。

それがただの杞憂であればいいのですが、もしかしたらそういう方が本当におられるかもしれないので、今日はそのような切り口から「企業がオープンソース開発に関わる際に今考える必要がある事」を解説してみようと思います。

オープンソースのビジネスの歴史と現状

先述の「オープンソースからの離脱」事例はいずれも、「オープンソースのマネタイズを収益源としている中小規模ベンダーによる、大手クラウドベンダーへの対抗」がキーワードとなっています。 この文脈を理解するために、まずオープンソースのビジネスにおけるマネタイズの歴史を簡単に振り返ります。

オープンソースは、「ソフトウェアのソースが開示されていれば、元の開発者でなくても改良でき²、より良くなる」という考え方に基づいて、使用者が開発元と同等のソフトウェアを自由に入手・改変・再頒布できるようにするものです³。 その定義（日本語訳）上、オープンソースのソフトウェアでは、自社で開発していないソフトウェアを使って第三者も商売を行えます。 例えば当社では、milter managerやCutter、Redmine用プラグイン、Firefox用やThunderbird用のアドオンなど、いくつかのソフトウェアをオープンソースで開発していますが、それらを収録したCD-ROMを当社以外の第三者が製造して販売したとても、当社はそれを差し止められない⁴ことになります。

それではソフトウェアの開発元は開発コストを回収できず、商売にならないようにも思えますが、実際には、いわゆる「オープンソース企業」が多数生まれました。 何故なら、「ソフトウェアの開発元である事実」がビジネス上の強みとなる場面があるからです。

オープンソースでは「開発したソフトウェア自体を売る⁵ビジネス」は成立しにくいですが、「ソフトウェアを使う上での技術的なサポートを受けられる権利を売る」ビジネスは成立します。 ユーザーが遭遇したトラブルの原因を究明したり、要望に応えるため改修したりするには、そのソフトウェアのことを熟知している必要があり、ソフトウェアの開発元であることは圧倒的な強みとなるからです⁶。

ただ、サポートビジネスは突き詰めれば「知識を持った人の労働力」が商材なので、スケールが難しい面があります⁷。 そこで次に有力なマネタイズ手段となったのが、「HTTPリクエスト経由でソフトウェアの機能を利用したり仮想サーバーを調達したりできるWebサービス」という、人よりもスケールしやすい「コンピューターのリソース」を商材とするSaaSやPaaSといったクラウドビジネスです。 クラウドでも、「ソフトウェアの開発元である」ことはサービス品質や信頼性の面でアドバンテージになります。 より良いマネタイズ手段になるとの期待から、様々な企業でクラウド事業への進出や、クラウドへの転換が進みました。

しかし、やがて大手クラウドベンダーによる「規模のビジネスの強み」が、中小規模ベンダーの「ソフトウェア開発元としての強み」を上回る状況が発生するようになってきました。

Webサービスを開発する際にバックエンドとなる様々なソフトウェアについて、ソフトウェア開発元のクラウドサービス⁸をそれぞれ個別に契約すると、開発上・管理上の煩雑さが増大します。 それに対し、ユーザーをより強くサービスに引き付けるべく様々なオープンソースソフトウェアのSaaS提供を進めた⁹大手クラウドベンダーでは、一社との契約だけで必要なSaaSが一式揃い、それらを一貫したUIで扱えます。

また、皮肉にも各OSSが成熟して品質が高まってきたことで、第三者がソフトウェアを使用していてもサポートが必要な場面はほぼ発生せず、「ソフトウェアの開発元であることの強み」を活かしにくくもなってきました。

こうして自社クラウドで利益を得にくくなってきたオープンソース企業の中小ベンダーの中には、大手クラウドベンダーにそれ以上利益を持って行かれないよう、ソフトウェアのライセンスを変更して「オープンソース」でなくすることによって、競合を排除しようとするプレイヤーが現れ始めました。 これが、昨今話題になることの多い「オープンソースからの離脱」の背景です。

「中小クラウドビジネスの崩壊」は「オープンソースのビジネスの崩壊」ではない

この件から、「自社開発のソフトウェアをクラウドで提供してマネタイズしたいのであれば、ソフトウェアにオープンソースライセンスは設定しない方が良い」ということは言えます。 開発したソフトウェアにオープンソースライセンスを設定すると、いざクラウドでマネタイズしようとしても、大手クラウドサービスにお株を奪われ、ここまでで述べた中小ベンダーのように、マネタイズが困難になってしまうリスクがあるのは事実です。

大手クラウドベンダーにお株を奪われて直接的に不利益を被ったMongoDBは、ライセンス変更に際して「オープンソースの開発コミュニティが受け取るべき利益を、充分な貢献をしていない大手クラウドベンダーが持って行っている」と主張しました。

ただ、ここで実際に起こっていることは、厳密には以下のとおりであることに注意が必要です。

• 何が困難になったのか？
  • ×（誤解）：中小規模のベンダーにとって、オープンソース製品のマネタイズ全般が困難になった
  • ○（事実）：中小規模のベンダーにとって、オープンソース製品のサーバー用ソフトウェアのクラウドビジネスによるマネタイズが困難となった
• 誰がオープンソースから離脱しているのか？
  • ×（誤解）：あらゆる分野のオープンソース企業が、オープンソースから離脱しだしている
  • ○（事実）：大手クラウドベンダーの台頭により自社クラウドビジネスから収益を上げられなくなった、一部のオープンソース企業が、クラウドビジネスでの収益を確保するためにオープンソースから離脱しだしている（少なくとも今の所は）

前項ではオープンソースのビジネスにおけるマネタイズの歴史を軽く紹介しましたが、クラウド事業へ進出するオープンソース企業は増えたものの、すべてのオープンソース企業がクラウド事業に鞍替えしたわけではありません。 クラウド市場の拡大の勢いを考えれば、その中で名を揚げたクラウドベンダー主導のプロジェクトが「オープンソースの代表者」に見えてしまうこともあるかもしれませんが、ここは冷静に物事を見る必要があります。

なお、このようにして一時は険悪な関係となった大手クラウドベンダーと中小ベンダー達でしたが、2022年にはAWSとRedis・MongoDBの間での戦略的合意が締結されるなど、共存を図る動きも行われています。 これらのベンダーはオープンソースから離脱する道を選んだため、もはや「オープンソースのマネタイズ」の事例にはあたりませんが、事の顛末として付記しておきます。

直接的なマネタイズ以外でも、企業はオープンソース開発に関われる

ここまでで述べた内容は、あくまで「オープンソース企業によるマネタイズ」についての話ですが、そもそも「企業にとって、直接のマネタイズだけがオープンソース開発との関わり方ではない」ということは、忘れてはいけない大事なポイントです。

例えば、RailsベースのWebサービスを運営する企業では、サービス開発の過程で見つけたRailsやRuby、あるいは様々なGemパッケージの不具合について、開発元に報告したり修正を提案したりといった関わり方があります。 不具合の修正や独自の機能拡張の内容を自社内で抱え込むと、それが他社に対するアドバンテージになり得る面はありますが、「フレームワークやライブラリの更新の度に追従コストが発生するリスクのある負債」になるとも言えます¹⁰ こういった物は、修正内容をオープンソース開発プロジェクトに還元することで、追従コストを削減できると期待できます¹¹。

また、それを突き詰めた、「自社の製品の開発に関わらない形で¹²、自社の依存度が高いオープンソース開発プロジェクトにフルタイムで従事する開発者を雇用する」という関わり方もあります。 Rubyのようなプログラミング言語の開発プロジェクトや、Railsのようなフレームワークの開発プロジェクトについて、開発チーム全員を雇用することは、よほどの企業体力が無ければ難しいです。 しかし、そのうち1人～数人だけを雇用するという事なら、可能となる企業の数は増えます。 そのような企業が複数で開発者を雇用し合うのは、実質的に、「会社の垣根を越えた開発プロジェクト」としてオープンソース開発プロジェクトを支える形とも言えるでしょう。

あるいは、自社のビジネスの強みとは異なる部分で副次的に生まれた成果をオープンソースで公開する、という関わり方もあります。 例えば、SNSを運営する企業の場合、ビジネス上の強みは「獲得しているユーザー数の多さと、その中で構築された対人関係の濃密さ」であって、Web UIそのものはビジネスの決定的な強みというわけではありません。 そのため、Web UIを開発するためのフレームワークやライブラリは、公開してしまっても収益に悪影響を及ぼさないと考えられます¹³。 それらのソフトウェアが業界内で広く使われると、開発者層へのプレゼンスが高まりますし、使い方に熟達した人が増えれば、彼らを優秀な人材として迎え入れやすくもなるでしょう。 もしかしたら、不具合を見つけた第三者が修正を提案してくれるかもしれず、そうなれば自社サービスの品質向上にも繋がります。

このような形での関わり方は、いわゆる「オープンソース企業」でなくても充分に可能です。 直接的な収益には繋がらなくとも、中・長期的な開発・運用コストを削減したり、事業の維持・拡大に必要な採用活動の打率が向上したり、あるいはオープンソース開発コミュニティ全般への貢献というCSR（Corporate Social Responsibility：企業の社会的責任）の面でのアピール材料になったりと、オープンソース開発に関わる事は間接的に企業活動にプラスの効果をもたらし得る、と筆者は考えています。

企業はSource Availableなソフトウェアとどう付き合えばよいか？

Source Availableとは

本記事で取り上げたいくつかのライセンス変更の事例では、変更後のライセンスは「一定の条件下でソースコードを開示し、再利用を認める」などの部分はオープンソースライセンスと共通していながらも、オープンソースの条件は満たしていません。 このような状態の呼び方は色々ありますが、近年は「Source Available」という言い方が一般化しつつあるようです。

Source Availableライセンスの内容は様々で、既知のオープンソースライセンスと組み合わせられる物も、そうでない物もあり、使用する際も外部コントリビューターとして関わる際も注意が必要です。 ここでは、本記事の事例で関係するSource Availableライセンスの代表例を簡単に紹介します。

• SSPL（Server Side Public License）
  • AGPLv3を元にいくつかの条件を変更した物です。 実際に、SSPLを策定したMongoDB自らAGPLv3とSSPLの条文の差分を公開しており、違いは前文と一部の条項のみなのが見て取れます。
  • AGPLv3は、ソフトウェアをSaaSで提供する場合であっても使用者にソフトウェアのソースコードを開示する義務がある、強いコピーレフト性¹⁴を持つライセンスですが、それでもソースの開示範囲はあくまで「そのソフトウェア」のみに留まります。 それに対しSSPLは、「SaaSとして運用するために必要な他のソフトウェアまで含めて」ソースコードを「サービス利用者だけでなく、あらゆる人に」「無償で、ネットワーク上で」開示する義務を課す点が異なっています。 この「他のソフトウェアまで含めて」という部分がオープンソースの条件に合致しないため、SSPLは非オープンソースのライセンスと言えます¹⁵。
    • この条項により、SSPLはGPLなどいくつかのオープンソースライセンスと明確に組み合わせ不可能です。
  • SSPLについては、オープンソースに当てはまるかどうか以前の問題として、条文の曖昧さからSaaS以外の用途でもリスクがあるとの指摘もあります
• BUSL（Business Source License）
  • 端的には以下の特徴を持つライセンスです。
    1. 改変、同条件での再頒布、非プロダクション環境（開発や検証など）での使用を許可する。言い換えると、プロダクション環境での使用は禁止である。
    2. ソフトウェアをBUSLで公開してから一定期間経過後に、自動的に所定のオープンソースライセンスに移行する。
  • オープンソースでは、ソフトウェアの用途の制限は認められません。 1つめの条件があることにより、BUSLもGPLなどいくつかのオープンソースライセンスと明確に組み合わせ不可能です。
• Commons Clause
  • それ単体でライセンスとして成立する物ではなく、既存のライセンスに「ただし、販売やSaaSでの商用サービスの提供を禁止する」といった条件を付け足す「但し書き」です。
    • 例えばRedisのモジュールの1つであるRediSearchは、後にSSPLに変更されましたが、「オープンソースからの離脱」当初はApache License 2.0 + Commons Clauseが設定されていました。
  • 用途を制限する条件のため、Commons ClauseもGPLなどいくつかのオープンソースライセンスと明確に組み合わせ不可能です。

企業においてこれらのライセンスが設定されたソフトウェアを使ったり、改変したりする場合は、以下のようなリスクがあります。

1.（そもそものライセンス変更の動機から言って当然ですが、）こういったライセンスが設定されたソフトウェアを自社のSaaSサービスに組み込むと、ライセンスの定めに従って他のソフトウェアまでもソースコードの開示を求められたり、ライセンス違反を問われたりすることになります。

• これは、「あなた」がこれらのライセンスの設定されたソフトウェアの開発元の競合ベンダーである場合、「あなた」はそれらのソフトウェアを競合サービス上では使えない、ということです。

2. それらのソフトウェアの開発元と競合するサービスを運営していない場合、つまりSaaSで使用しない場合であっても、それらのソフトウェア由来のコードを、条件が矛盾するライセンスのソフトウェア由来のコードと混ぜ合わせることはできません。
   • 例えば、これらのライセンスが設定されたソフトウェアはいずれも、ソフトウェアの一部をGPLのソフトウェアに持ち込むことも、その逆に、GPLのソフトウェアの一部をそれらへ持ち込むこともできません（どちらか、あるいは両方のライセンスへの違反となります）。
   • 他方、これらのSource Availableライセンスと矛盾する条項のないライセンス、例えばMITライセンスのソフトウェアであれば、Source Availableライセンスのソフトウェアに組み込むことはできます（その逆はできません）。

1つ目のリスクは自明ですが、2つ目のリスクにも注意が必要です。 例えば、「Terraformの性能を劇的に向上する画期的な変更を、BUSLとなって以後のTerraformにコントリビュートする」場面を想定してみます。 その性能向上のために必要な処理を最初にTerraformに実装してプルリクエストを送り、幸いにもマージされたとして、その後、その実装を流用して、改めて自社のソフトウェアにも同じ処理を組み込んでGPLの元で公開したり、あるいは、Terraformのライセンス変更前のバージョンをforkしたOpenTofu（MPL2）にも同じ変更を行うプルリクエストを送ってマージされたりした場合、形式上はBUSLのライセンス違反を疑われるリスクがあります¹⁶。 それを避けるためには、まず最初に、そのコードをMITライセンスや2条項BSDライセンスなどBUSLと矛盾しないライセンスで公開した上で、「それをTerraformとOpenTofuに別々に組み込んだだけだ」という体裁とするのが安全でしょう。

オープンソースライセンスの物同士を組み合わせる場面であっても、ライセンス同士の条項の競合には注意が必要です。 Source Availableだからといって、オープンソースでは必要無かった新たな概念に注意が必要になったわけではありません。 ただ、「オープンソースとほとんど同じ物だ」と思ってよく考えずに採用したりコードを提供したりすると、後々ライセンス違反が問題となる可能性はありますので、より一層の注意が必要になったとは言えるでしょう。

オープンソースだった頃のバージョンからのforkという道

また、これらのソフトウェアとの別の付き合い方として、「ライセンス変更前のバージョンをforkして当時のオープンソースライセンスのままで使い続けたり、再公開し開発を継続したりする」、というものもあります。 OpenTofuはまさにそのような例です。

OpenTofuは「開発元の競合ベンダーがプロダクション環境で使用できる」点ばかりに着目されている印象がありますが、オープンソース開発の観点では、前項で例に挙げた「GPLのソフトウェアにコードを持ち込むことも、GPLのソフトウェアから持ち出したコードを組み込むこともできない」といったライセンスの競合が発生しない¹⁷メリットがあります。

OpenTofuについて、「forkしたのがまさに、ライセンス変更によって排除された競合ベンダーの人であった」点からなされた批判的な意見も見られますが、筆者は「ユーザーが使いたい用途に使える状態にするために、ユーザー自身がプロジェクトをforkして新たに開発者の立場になること」は、オープンソースにおいて平常の営みの1つであると考えます。

筆者は、既存のOSSに修正のプルリクエストを提供したものの、そのプロジェクトの趣旨にそぐわない変更がこちらの都合でどうしても必要となったために、途中からプロジェクトをforkして、派生版として開発を継続したことがあります。 またその逆に、筆者が開発しているソフトウェアに寄せられた提案について、プロジェクトのポリシーに合致しなかったため採用を見送りつつ、「どうしてもその使い方をしたい場合は、forkして別プロジェクトとして継続して欲しい」と促し、実際にforkされ、開発が続いている様子を確認できた例もあります。

一般的に、開発リソースの分散を招く無意味なforkは避けたほうがよいですが、プロジェクトの方針に合わない変更を無理に取り込み続けると（ユーザー視点では、プロジェクトの方針に合わない要求を無闇に押しつけすぎると）、プロジェクトの破綻にも繋がりかねません。 そうして全員が共倒れになるのに比べれば、forkはベターな選択と言えるでしょう。 forkの動機となる意見の相違が、機能的な面についてであれ、プロジェクトのポリシーについてであれ、ライセンスの選択についてであれ、各ユーザーがそれぞれの事情でforkして最も使いやすいソフトウェアを自由に存続させられるのが「オープンソース」だ、というのが筆者の理解です。

まとめ

以上、オープンソース開発コミュニティに最近増えている「オープンソースからの離脱」の事例を参照して、オープンソース開発プロジェクトのマネタイズと大手クラウドベンダーのビジネスが競合した経緯と、安全に行える「企業のオープンソース開発への関わり方」の例、および、Source Availableのライセンスの注意点をご紹介しました。

オープンソース開発の成果物としてのソフトウェアは「人類の共有財産」のような性質を帯び、「特定の企業が占有できる資産」としての性質は弱くなりがちです。 企業がオープンソースに関わる時や、ソフトウェアに設定するオープンソースライセンスを選択するときは、何を目的とするのか、その選択が自社のビジネスや周辺の状況にどのような結果をもたらしうるのかを、充分に考える必要があります。 何も考えずに漫然とライセンスを選択すると、本記事で言及した中小ベンダーによるクラウドビジネスの事例のように、後々経営にマイナスの影響を及ぼす事にもなり得ます。 過去の事例に学び、自社のビジネスとオープンソースの間の適切な距離感を見極めた上で、オープンソース開発に関わって頂ければ幸いです。

また、伝統的な企業活動の仕方からオープンソースに歩み寄っていく方向性以外にも、「オープンソースあるいは自由なソフトウェアを出発点として、経済的な自立と企業活動の永続を目指す」方向性もあります。 当社は「フリー自由なソフトウェアとビジネスの両立」を理念とし、「自分達の成果を他者に共有すればするほど儲かる」道¹⁸の実現を模索しています。 このような当社の在り方に賛同し、ビジネスを生み育てる部分に加わりたいと感じた方は、採用情報をご覧頂けましたら幸いです。

1. GPLであってもソースの開示義務があるのはソフトウェアの使用者に対してのみであって、「誰でも自由にアクセスできるようにソースを公開する」義務はありません。ソースを公開している多くのケースは、「使用者に限定して、求めに応じてソースにアクセス可能とする」ためのコストが割に合わないからそうしているに過ぎません。 ↩

2. これは「開発チームに関われる」という事だけではなく、「独自にforkして新しい開発チームを作れる・開発できる」ということも含みます。 ↩

3. 元々「オープンソース」という言葉は、「自由なソフトウェア（Free Software）」の運動にまとわりつく「営利企業による経済活動とは食い合わせが悪い」イメージを払拭して、ビジネス利用を推進するために作られた物でした。 ↩

4. こういった利用の仕方も含めて、ライセンスの文面であらかじめ許諾済みであるため。 ↩

5. ソフトウェアそのものは物理的な実体を持たないため、「ソフトウェアを入手する権利」「ソフトウェアを使用する権利」「ソフトウェアを収録した物理的な媒体」といったものを売る形になります。ただ、ソフトウェアは容易にコピーできることから、現在は「使用する権利」を販売する形が主流となっています。なお、ダウンロード販売が普及したゲーム業界においても、初回特典付きの「パッケージ版」のような付加価値を付けた物理媒体を売る商品は現在もよく見られます。また、今ではあまり見られませんが、実用のソフトウェアにおいても、紙媒体に印刷された分厚いマニュアルなどを付加価値とした「パッケージ版」がありました。 ↩

6. とはいえ、ソフトウェアの開発元がサポートを提供していない場合には、第三者も有力なサポート提供元になり得ます。当社も、Mozillaが有償でのサポートを（特に、日本語での法人向けサポートを）提供していないFirefoxやThunderbirdのサポートビジネスを行っています。 ↩

7. 特に、込み入った問い合わせに対応するためには優秀な開発者と同等の知識が必要となり、教育コストや人材確保のコストが大きな問題となります。スケールさせるためには、「定型的な質問にマニュアルベースで回答する人員」と「込み入った問題に高度な知識で対応する人員」を分けて、可能な限り前者で問い合わせを捌けるように体制を作るといった方法があります。ちなみに、ChatGPTのような大規模言語モデルは、この点でのブレークスルーになるものとしても期待されています。 ↩

8. Oracle自身によるMySQLのSaaSや、本家Redis、本家MongoDBなど。 ↩

9. 例えばAmazonのAWSであれば、MySQLなどのRDBMSのSaaSであるRDS、Redis互換のSaaSであるMemoryDB、MongoDB互換のSaaSであるDocumentDBなど。 ↩

10. その結果、追従のコストを支払いきれなくなり、システムを塩漬けにしていつまでも古いバージョンのフレームワークやライブラリを使い続ける、という形になってしまうこともあります。そのような状態では、フレームワークやライブラリの新機能の恩恵を受けられませんし、既知の脆弱性の影響を受けるリスクや、ひいてはそのことが事業に損害を与えるリスクもあります。 ↩

11. 例えばGitHub社によるRailsのコントリビューション事例では、Railsの開発段階から積極的に関わる事により、新しいバージョンのRailsがリリースされてからさほど間を置かずにGitHubのサービスを新しいバージョンのRailsベースに更新できた、ということが報じられました。 ↩

12. 開発にはアサインせずとも、そのように雇用した開発者に、一歩引いた視点で社内での開発にアドバイスをもらうといったこともあり得ます。 ↩

13. この事例としては、Twitter社（現X社）のBootstrapや、Facebook社（現Meta社）のReactなどが挙げられます。 ↩

14. 著作物の取り扱いについて、作者などの権利者が独占的に使用したり扱い方を決めたりできる権利を、著作権（copyright：コピーライト。ここでの「right」は「権利」の意）と言います。それをもじって、「著作物を独占できないようにすること」を「copyleft（コピーレフト）」と呼びます。 ↩

15. オープンソースには「同時に配布される他のソフトウェアに、そのソフトウェアが元々求めていた以上の使用条件を課してはいけない」という条件があり、SSPL固有の条項はここに抵触します（参考記事）。 ↩

16. 勿論、このケースでも「あなたがそのコードの著作権を持っている」ことは事実で、BUSLのライセンス違反にはあたらないと考えられます。そのような経緯を知らない人が「Terraformのスナップショットのソースコード」を先に見て、後からあなたがそのコードを別のライセンスのソフトウェアにも組み込んでいる様子を見たときに、「これってライセンス違反では？」と誤解する恐れがあり、公開の場所での初出がTerraform（BUSLのライセンスのソフトウェア）への提供だと、その誤解を解くのが難しいと考えられる、ということをここでは問題視しています。 ↩

17. OpenTofuのライセンスはMPL2.0なので、GPLのソフトウェアにコードを持ち込んだ場合も、GPLのソフトウェアから持ち出したコードを組み込んだ場合も、その後のソフトウェアのライセンスはGPLになります。 ↩

18. 例えば辛子明太子の「ふくや」は、辛子明太子という商品を開発した後、その製法を他者が自由に使える状態にした上で、辛子明太子の大手メーカーとして成功し存続しています。 ↩