なぜ脱OSSが増えているのか？

はじめに

TerraformやVaultを開発するHashiCorpは自社製品をOSSのMPL(Mozilla Public License v2.0) から、ソースコードは公開するも一部の利用に制限があるBSL(Business Source License) への変更をアナウンスしました。
https://cloud.watch.impress.co.jp/docs/column/infostand/1524938.html
https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

これは2018年のRedisを皮切りにMongoDBやCockroachDB、ElasticSearchなど多くのプロダクトで進められている脱OSSの流れです。商用のオープンソース^[1]と言われてしまうこともある最近のこの動きの理由は何故なのか？　という点を以下の動画で解説しました。
https://youtu.be/QpIGExxsH0k

動画中では尺の都合で端折った個所も多いので、こちらの記事の方にもまとめておきたいと思います。

OSSとは？

OSSの定義

まず、OSS（オープンソース）とはなんでしょうか？ これはRMSのフリーソフトウェアを源流とする考え方で、ソースコードを公開し自由に改変/再配布する開発モデルです。良く誤解されますが、単にソースコードを公開しただけではOSSではありません. OSSは特定のブランド/商標であり固有名詞です。OSI (Open Source Initiative)では以下のように定義しています。

1. 再頒布の自由
2. ソースコード（「ソースコード公開」も含む自由な利用）
3. 派生ソフトウェア（派生物の自由な利用）
4. 作者のソースコードの完全性(integrity)
5. 個人やグループに対する差別の禁止
6. 利用する分野(fields of endeavor)に対する差別の禁止
7. ライセンスの分配(distribution)
8. 特定製品でのみ有効なライセンスの禁止
9. 他のソフトウェアを制限するライセンスの禁止
10. ライセンスは技術中立的でなければならない

詳しくはOSG-Japanの解説を読んでもらうのが良いと思いますが、ざっくりといえば 「ソースコードを自由に利用できる権利の保障」 と 「自由を妨げる行いの禁止の仕組み」 が規定されています。OSSであるためには単にコードを公開するだけではなく、これらの定義に当てはまる必要があり、特に今回の脱OSSの流れで問題になるのが第5条:個人やグループに対する差別の禁止と第6条:利用する分野に対する差別の禁止です。「差別」という強い言葉が使われていますが、要は商用利用禁止とか研究機関のみで利用可能とかの制限を入れてはならない、ということですね。

OSSとフリーソフトウェアの違い

余談ですが、OSSはフリーソフトウェアの考え方から生まれており、OSSの定義もフリーソフトウェアの定義とおおむね合致します。というかGPLとかフリーソフトウェアらしいライセンスももちろんOSS準拠のライセンスですし。しかし２つは思想/信条が異なる部分があり、ある意味では似て非なるものです。

フリーソフトウェアは主に 「自由と権利」 を強調しますが、OSSは 「品質と共同作業」 を協調します。すなわちフリーソフトウェアとしてはソースコードの公開/共有/改変は自由のための権利ですが、OSSにとってのそれは品質と生産性のための手段です。これはOSSが企業にとって魅力的であり利用しやすいように意図的にリブランドしたもの^[2]です。
もちろんこれは白黒はっきり分かれるようなものではなく、そもそもフリーソフトウェアから始まったものなので、コミュニティは大部分が重なっていますし、当然OSSの人たちにとっても自由は重要です。ですがOSSは 思想ではなく開発手法 に着目する事でよりビジネス向けの活動になったことは間違いないと思います。良い悪いは別として。

OSS周りの歴史はWikipediaが結構まとまってて良かったので是非一読してみてください。
https://ja.wikipedia.org/wiki/オープンソースソフトウェアの歴史

OSSは固有名詞？ OSS、ブランド、Source-available license

今回の脱OSSの流れや最近流行りのLLMのモデル公開の流れで 「商用のオープンソース」 とか 「非商用向けのオープンソース」 という言葉でOSSが誤用されることがあります。OSSは単にソースコードが公開されたプロダクトの一般名詞ではなく、前述のとおりOSIの定義を満たしたプロダクトを指す固有名詞です。商標も取られています。
https://opensource.jp/osg/trademark/
しかしながら、リンク先にも記載がある通り 「『コンピュータのソフトウェアの ソースコードを公開して、誰にでも自由に改良できるようにすること』の 意味合いを認識する」 と2001年での商標申請の時点で却下される程度には広義の意味も広まっているので誤用とは言い切れない部分もなくはないです。元々造語として生み出したものが広まる過程で変質したとはいえ皮肉なものですね。

じゃあ一般名詞としてのオープンソース、広義のオープンソース/狭義のオープンソースで使い分ければ良いじゃないか、という話もあるのですが、個人的にはOSIの定義を満たしたものだけをOSSと呼ぶべきかな、と思います。
というのも、OSSという言葉はブランドとして彼らコミュニティが育ててきたものです。日本にいるから和牛、松阪で育ったから松阪牛で良いだろう、という話ではブランドへのフリーライドですよね。多大な恩恵を自分たちひいては社会に与えてきたOSSですから、そこは敬意を払うべきかと。

じゃあ、OSIの定義を満たさないコードを公開してるプロダクトをどう呼ぶのか？　という話になるわけですがSAL (source-available license/software)という呼び方があります。そのまま 「ソースコードが利用可能なライセンス」 という意味でOSSを含むコードを公開するライセンスの包括的な呼び方です。

正直、現時点ではあまり普及した言い方ではないですが、脱OSSの流れの中で見かけることも増えましたし、今後はより広まっていくことを期待します。

なぜ、企業はプロダクトをOSSにするのか？

OSSの運営形態

ひとくちにOSSといっても様々な運営形態があります。大きく分けると以下の3つに分類できます。

1. 個人/小規模の完全ボランティアベースのプロダクト
2. NPOやコミュニティ/委員会により運営されるプロダクト
3. 企業が自社製品をOSSとして展開するプロダクト

1に関しては基本的には趣味の世界の運営ですね。特別な理由はなく 「せっかくだしOSSで公開するか」 くらいのモチベーションの人も多いはず。小さいからと言って必ずしも「重要ではない」とはならないのですが、いずれにしてもここは趣味だったりボランティアベースの運営となります。

2は基盤よりのプロダクトで採用されることが多いです。企業が絡むことも多いですが大なり小なり力関係はあっても独占的なものではなく、共同資産をみんなで開発するという色が強い運営形態。OSSっぽいですね。

3は自社製品をOSSとして公開してるパターン。OSSが先にあって会社を作るパターンと会社がプロダクトを作ってOSSにする両方のパターンがありますが、いずれにしても外部メンバーのコミットを受け付ける場合であっても主導権は特定企業が握るパターンです。ちょうど脱OSSしてる企業群はこれにあたります。

OSSと企業とマネタイズ

では企業は何故OSSにかかわるのでしょうか？ 普通に考えたら無料で使われるものに営利企業が絡むのはおかしいですよね？
CSRや社会貢献、あるいは技術アピールという側面もありますが、経済活動に限ってももちろん理由があります。思いつくのは以下の３つでしょうか。

• Case01: プロダクトは無償で提供し、サポートやフリーミアムで儲ける
• Case02: プロダクトで直接儲けず自社ビジネスのツールとして利用する
• Case03: プロダクトを利用しやすくするプラットフォームで儲ける

Case01はLinuxディストリビューション(以下Linux)がイメージしやすいと思いますが、OSSであるLinuxをサポート/保守をすることでサブスクリプションとして利益を得ます。ソフトが無料でも自分で導入したりサポートするのは大変ですからね。また商用のパッケージなどを追加して痒い所に手が届くエンタープライズ版としてプロダクト自体でもお金を取るケースもありますね。従来からよく行われており、イメージしやすいOSSビジネスの一つです。

Case02は自分たちのビジネスに利用するジェネラルな道具をOSSで効率的に開発する、というケースです。多くのプログラミング言語やWebサーバのOSSがECを始めとした様々なインターネット企業で利用されており、彼らがそうしたOSSを寄付金やコミッターの面で支援する事も多いです。CookpadやNetflixといった企業は動画配信だったり自分たちの本業で儲けますが、そのためには利用しやすい道具が必要なのです。そこはみんなで開発した方が効率が良いですよね。

Case03はプロダクト自体は無料なのだけど、それを動かす最適な場を有償で提供してそれで儲ける方式です。ジーパンやツルハシを売る作戦に近いかもしれません。クラウドベンダー等がよくやる手法でDBやデータ処理基盤, BIツールなどをPaaS/マネージドサービスとして提供します。前述のパターン3にあたる 「自社プロダクトをOSSで公開する企業」 もマネージドサービスでマネタイズを狙うことが多く問題の火種となっています。

ちなみに余談ですが最近流行りの生成AIで、MSやGoogleはAIをCase03的な運用もしていてMeta社はCase02のみの利用方法になるので、プロダクトの公開の仕方も異なっているのは注目しておきたいところです。マネージドサービスにしてAPIで提供するのはもちろん、大きなモデルを作ると自社のIaaSがたくさん利用される機会が増えますしね！ ま、邪推ですが。

このようにOSSでも企業がマネタイズ出来る方法はあり、自社プロダクトをOSS化したうえでCase1やCase3を使ってマネタイズを狙う会社も多いです。

企業としてのOSS採用の魅力. なぜ自社プロダクトをOSSに？

マネタイズ出来る事は分かりましたが、それでも 「なぜOSSにするのか？」 は不明のままですね。シンプルにプロダクトに値札を付けた方が分かりやすいですよね？ もちろんこれにも貢献的な側面を除いても、多くの理由があります。パッと思いつくのは以下の３つです。

1. 無料なので初手の利用間口を広げやすい
2. コミュニティによるFB, 生産性と品質の向上
3. サードパーティの利用/参加のしやすさ

まず1ですが、どんな良い製品も使ってもらわなければ始まりません。Case01の場合でも初手は自前で手軽に検証/導入が出来て、後からサポートや有料プランに持ち込んだ方が絶対に良いです。いわゆるフリーミアム的な考え方です。自社の用途にマッチをするかを確認するPoCの時点からライセンス費用が発生するのは、ねぇ？
これはCase03のマネージドサービスの場合も同様ですし、 「使い慣れたあのツールをもっと手軽に運用」 という謳い文句も魅力的ですよね。使ったことの無い謎のマネージドツールより。

2もOSSのイメージとして分かりやすいですよね！ デベロッパーによる直接的なコミットの支援はもちろんですが、利用者からのIssueとしてのFBや、ドキュメンテーションの支援もあるでしょう。実際のところ自社プロダクトをOSS化してるケースだと、どこまで要望やPRが通るのか？　という話はありますが、コードも見れるし、いざとなればフォークも出来るという点でクローズドなコードよりは圧倒的にコミュニティが育ちやすく、その恩恵も受けいやすいと思います。

3のサードパーティも1や2の派生と捉える事も出来ますが、例えばとあるツールのダッシュボード --- 最近だとStable Diffusion Web UIとかがイメージしやすいですね --- こうしたものがOSSだと簡単かつ安心して作れます。問題があったときの調査もコードが読めますし、改変も出来るので製造元ベンダーとの契約とかなくても対応が自前で出来ます。なので、他社が自社の製品に組み込んだり連携したりということが非常にやりやすいのがOSSです。通常の商用ソフトだとまずは相手先企業にコンタクトを取るところから始めないとですし、契約に成功しても費用面の話とかどこまで情報開示されるのかとか問題発生時の切り分けとか考えることがたくさんありますが、OSSではそれをほぼ考慮する必要はありません。これはOSSとして公開した企業としては自社プロダクトをより魅力的にし利用を拡大する重要な手助けとなります。

脱OSSへの道

マネージドサービスとメガクラウドベンダー

先ほど、自社プロダクトをOSS化する企業はマネージドサービスでマネタイズする会社も多いことを説明しました。一種のフリーミアムモデルですね。もちろんこれは他の企業でも出来る事なのですが自社プロダクトのプライドを込めて 「僕が一番このプロダクトをうまく扱えるんだ！」 という奴です。実際、多くの場合で競合他社よりも製品理解を含めて優位な立場に立てるでしょう。それでも、強すぎる競合が出てくることはあります。そして、その典型がAWSを筆頭とするメガクラウドベンダーです。

AWS, Azure, そしてGCPといったクラウドベンダーはOSSをマネージドサービスとして自身のサービスの一部として展開する事が多いですね。特に顧客ファーストのAWSはその傾向が強い。これは非常に強力で、他の独立系PaaSベンダーとは異なり、利用者からするとわざわざ別のベンダーを契約するよりも手慣れた環境でボタンポチポチで構築する方が良いわけです。監視やログ周りの機能、設定のダッシュボードなどがクラウドベンダー側と最初からうまく連携してることも多く、そういった運用面でも導入のしやすさは圧倒的です。公式のマネージドサービスの方が機能的に優れてる事も多いですが、そこまでユーザが求めてない事も多く、クラウドベンダーに美味しいところを取られてしまいビジネスモデルが壊れてしまうわけですね。

OSSなら基本的にコードは全体に還元されるので、同じ道具を使うなら公式の優位性がありそうですが、このケースは当てはまりません。そもそもAGPLなどの一部の例外を除けば、サーバサイドで利用するのみでバイナリを提供してないなら通常のGPLやBSDの場合はコードの開示義務が発生しません。そして、それ以前にクラウドベンダーが強い原因はプロダクト品質以前に自社サービスに統合し既存利用者に提供していることです。これはOSSベンダーでは真似できませんから、自由にマネージドサービスをされては困るわけです。

脱OSSという選択肢

このような状況でマネージドサービスをマネタイズ手段として想定している自社プロダクトをOSSにしたベンダーはあることを考えます。それはビジネスモデルに影響を与える 「競合他社の排除」 です。
OSSによりもたらされるフリーミアムの効果や、コミュニティは維持したいのでコードの公開や改変、再配布や派生物の作成は原則OKにしたいと思いますが、ビジネスモデルを壊されては困るので、ほんの少しだけルールを変えます。基本的に自由にしていいけど 「マネージドサービスを作るのはやめて」 とか 「競合したビジネスのＡ社はダメ」 とか、ほとんどの人には従来通り使えるけど一部の組織や用途に制限を加える事で、自分たちのビジネスモデルも守られてwin-winに見えます。なかなか冴えたアイデアです。

しかし、これはOSIの定義の第５条や６条に真っ向から反しています。OSSはフリーソフトウェアに比べればフラットとはいえ、やはりその根底には 「自由の思想」 があります。そのため如何に似ていてもビジネスのために用途に制限を掛けてくるライセンスは、良い悪いではなくOSSではなくプロプライエタリなライセンスとなります。

流れ的にOSSに一部制限を加えたOSSの亜種、と考えがちですが、ビジネスモデルとそれを維持する開発モデルのためにOSSのエッセンスの一部が必要なだけなので、OSSの特徴であるコードの公開や改変/再配布を限定的に許可しているプロプライエタリライセンスとして考えた方がしっくりきますよね。

また、一応、表向きは 「OSSの成果物にフリーライドするだけで彼らは貢献をしない」 という形でライセンスの変更理由を言っていますが、それであればマネージドサービスや競合他社を直接的に制限対象にする必要も無いですよね。実際、AWS向けの機能とか場合によってはPR送られてきても困るでしょうし... 本音は別、ということです。

こういう流れで各ベンダーはプロプライエタリなSALを作成/採用し、脱OSSを行う企業が増えています。

代表的な非OSSのSource-avairable license

それでは、いくつか非OSSのSource-avairable licenseを紹介します。

Business Source License (BSL)

HashiCorpも採用したBSLです。元々MySQLのフォークであるMariaDBのために作られたライセンスです。
https://www.hashicorp.com/bsl
ソースコードの閲覧/配布/変更/再配布/派生物作成は非商用では自由に可能です。商用の場合も競合サービスを展開しない限りは自由に可能です。

BUSL-1.1 は非商用（non-production) では利用可能、商用 (use-production) 利用は認められていません。
追加使用許可 (Additional Use Grant) を定義することで、HashiCorp は競合以外は商用利用しても良いとしています

※ コメントで指摘いただきましたが競合以外は商用利用可となるのはHashiCorpの場合だけのようです。ご指摘ありがとうございます。

ただし、この「競合サービス」というのが曖昧で、HashiCorpでは「とりあえず迷ったら問い合わせて！」と言ってるので恣意的に決める形となり、ある日HashiCorpが競合になると、商用ライセンスに切り替えたり別のツールに変更が必要なリスクがあります。

Elastic License v2（ELv2）

Elasticでは ELv2という非常にシンプルなライセンスを採用しています。
https://www.elastic.co/jp/blog/elastic-license-v2

わずか3つの概念的制約の下にソフトウェアを使用、複製、配布、提供する権利、ならびに派生成果物を作成する権利を認めます

1. 製品をマネージドサービスとして他者に提供する行為
2. ライセンスキーによる保護機構を何らかの方法で回避する行為、および、ライセンスキーで保護される機能を削除または隠蔽する行為
3. 使用許諾、著作権、その他の通知を削除、またはわかりにくくする行為

こちらも 「マネージドサービスに出来るのはうちだけだからね！」 というスタンスですね。

PolyForm

現時点ではOSSではないSALに関しては、各社ともニーズに合わせて自分で定義する傾向にあります。しかしこれでは体力のあるところしか出来ないし、各社のライセンスを都度都度読まないといけないので正直面倒。そこでCreative Commonsのように、単一のライセンスで「非営利」とか「競合不可」とか様々な条件を簡単に表現出来るように作られているのがPolyFormです。
https://polyformproject.org/licenses/

CCと同じようにアイコンで用途を示す事ができます。例えば単なる非商用なら「Non Comercial」、BSLのような競合ビジネス禁止なら「Shield」、Llama 2のように大企業での利用を制限するなら「Small Business」です。

「Trial」とかもあるので、大抵の用途はこれで済みそうですね。こちらがクイックリファレンス。

License	Use	Change	Distribute	Limitation
PolyForm-Strict	Yes			Non-Commercial
PolyForm-Noncommercial	Yes	Yes	Yes	Non-Commercial
PolyForm-Free-Trial	Yes	Yes		Trial
PolyForm-Internal-Use	Yes	Yes		Internal
PolyForm-Small-Business	Yes	Yes	Yes	SMB
PolyForm-Perimeter	Yes	Yes	Yes	No Competition with Software
PolyForm-Shield	Yes	Yes	Yes	No Competition with Provider

OSSから変更することの懸念と展望

まず、前提としてBSLやその他の非OSSのSALがOSSに準拠してないからと言って、邪悪であるとか違法であるとかそいうことはありません。コミュニティに同意を得ずにライセンス変更をした場合は軋轢や反発はあるでしょうし、フリーソフトウェアやOSS界隈からは自由の観点で避難があるでしょうが、それはそれとして営利企業としては自分たちのビジネスが回る最適と思われる選択をするべきでしょう。

それでも、こちらの記事にあるような指摘はコードを公開する事で、コミュニティやサードパーティの協力を得るのが難しくるリスクはあります。
https://blog.gruntwork.io/the-future-of-terraform-must-be-open-ab0b9ba65bca

もしCTOであり、会社でIaCツールを選ぶ場面になったとき、TerraformがBSLライセンスであることを知ったら、なぜリスクを取るのでしょうか？ あなたは、真のオープンソースでライセンスの頭痛がない代替ツールを選ぶ可能性がはるかに高くなります。

もし会社の法務チームに所属しており、開発チームが使用したいライセンスをレビューしていて、BSLを見たら、なぜリスクを取るのでしょうか？ あなたは、BSLを禁止ライセンスリストに追加するよう提案する可能性がはるかに高くなります。

もし開発者であり、オープンソースへの貢献を検討している場合、将来自分の作業を使用できる保証がないBSLプロジェクトに貢献する理由は何でしょうか？ あなたは、他のものに貢献する可能性がはるかに高くなります。

もしベンダーであり、DevOps領域での製品やツールの開発を検討している場合、なぜTerraformを中心に構築し、HashiCorpが現在または将来、あなたを競合とみなすリスクを取るのでしょうか？ それは建設の基盤としてあまりにも不安定すぎるので、あなたは他のものを中心に構築する可能性がはるかに高くなります。

これらは杞憂でしょうか？ 個人的にはその製品が唯一無二とかならともかく、代替の選択肢があるなら、リスクとして「あえては選ばない」くらいの影響は出てしまうと思います。

一方で、悪いことばかりではないかもしれません。元々、一社の影響が極端に強いプロダクトですから、企業とそのファンという形で 「自由」 とはまた別の形でコミュニティはまとまるかもしれません。例えば、推しに貢献したいとか、公式に認められたって立派なモチベーションですよね？

また企業としては競合を気にせず安心してコードが公開出来るので、例えばCommunity版だけではなくEnterpise版のコードも公開するなどして、より透明性と生産性が高まるかもしれません。サードパーティからも大手からは利用費用を徴収する事で収益性が改善されプロダクト品質が上がるかもしれませんし、利用拡大時に契約を結ぶならサードパーティ側も適切なサポートを受けれる可能性がある。
上記に述べたリスクは確かにあると思いますが、実際には気にするほどでもないかもしれないですし、それを上回るメリットがあるかもしれないです。このあたりはプロダクト毎に事情が異なると思います。

まとめ

HashiCorpやRedisなどプロダクトをOSS化する企業が何故存在するのか？　そして、どうして最近は脱OSSの流れがあるのか、という点を解説しました。

歴史的に見れば「自由」から始まったフリーソフトウェアが、OSSになる事で開発手法に注目があつまり、それがさらに先鋭かされついには本命だった「自由」が忘れ去られた形になります。
これは、自由にフォーカスすると明らかな劣化ですが、ビジネスの点に限ればマネタイズの手段が確保されつつも、一般的な商用ライセンスよりも利用者としても活用しやすいということで、必ずしも悪いばかりの流れではありません。中の人たちも自由とマネタイズのバランスを考えての結果のはず。

こういった非OSSのSALがどこまで普及するのかは分からないですが、様々な選択肢があること自体が多様性でもあるので、こうしたプロダクトがどうなっていくのかも注目しておきたいですね。その際はライセンスはある程度統一されて欲しいですが...

それではHappy Hacking！

脚注

1. もちろんOSSの定義的にこの表現は変ですが

2. 「オープンソース」の始まり - Wikipedia