LT：MIT、GPL、BSL？何をしたら違反になる？ケースから学ぶ OSSライセンス講座
普段はメインフレームやプログラム言語の作り方の話、ITニュースで気になった話をyoutubeなどで発信しています。
脱オープンソースの流れのニュースを紹介した際に、オープンソースを辞める・辞めないという話がよくあったので、そこら辺の話をまとめた記事をZennで書いていました。今回はその記事からこの機会をいただくことができました。
どのようなニュースがあるのかというと、先日もfair sourceという謎なものが登場したので「fair sourceってなんだ？」という話や、「HashiCorpやElastic、MongoDBがどんどんオープンソースライセンスを辞める宣言をして独自の商用ライセンスを使い始めている」という話、最近よく聞く「オープンソースのAIも実はほとんどオープンソースではない」という話を今日は整理してLTでできたらと思っています。
OSSとは？
オープンソースとは、RMS達のフリーソフトウェアを源流とする、コードを無料で公開し、共同開発する開発モデルです。
フリーソフトウェアは自由という文脈を大切にしている考え方ではありますが、OSSはみんなで共同開発をするなど開発スタイルを中心に考えた、よりフォーカスしたやり方だと思っています。
単に、無料でコードを公開していたらOSSというわけではなく、OSIという団体が定義した要件を満たしている必要があります。
単なる利用者としても無料で透明性も高く、良いものが作りやすい、そのような開発モデルです。
OSSの定義
OSSの定義は、画像に記載の10個です。
最初のほうはルールが書いてあります。後ろの方はその自由を守るための制約がルールとして定義されています。
特に5、6番は覚えておいて欲しいと思います。
OSSと企業とマネタイズ
オープンソースは個人や企業・団体が自分の趣味や社会的ミッションのために公開していることも多くありますが、それだけではなくオープンソースとして企業が関わるケースも多いと思います。
企業が関わるケースにはいくつかバリエーションが存在します。
1.プロダクトで直接儲けず自社ビジネスのツールとして利用し間接的に儲ける
→ApacheWebサーバやアプリケーションサーバでは、ECや金融サービス、ゲーム会社など、マネタイズするビジネスを持っていても基盤としてプラットフォームが欲しいというケースが多くあります。そこはジェネラルでコモディティなものなので、みんなで開発したらいいという、分かりやすいオープンソースです。
2.プロダクトは無償で提供し、サポートやフリーミアムで儲ける
→プロダクトをオープンソースとして、直接設けるバリエーションもあります。
オープンソース版をコミュニティとして無料で提供し、より高機能なエンタープライズ版を出す企業も存在しています。
3.フリーミアムの発展としてSaaSで儲ける
→最近多いケースだと思っています。最近の流れで脱オープンソースが出てくるのは、ほとんどがSaaSでビジネスモデルを組み立てている会社です。ElasticやMongoDBなどです。
なぜ企業はプロダクトをOSSにするのか？
普通にお金を取ればいいのではないかとまず思いますよね。
・無料なので初手の利用間口を広げやすい
→これは大きなメリットだと思います。
・コミュニティによるFB, 生産性と品質の向上
→コミュニティと一緒にプロダクトを育てやすいことが、まさにオープンソースの開発スタイルのメリットです。
・サードパーティの利用/参加のしやすさ
→例えばTerraformというプロビジョニングのツールを使った何かしらの仕組みを作るときに普通の所要ソフトだと、まずそれを自社サービスに入れるための契約をしたり、ベンダーにコンタクトを取るところから始めたりしないといけません。
オープンソースでは、とりあえず使ってみたり自分たちと合わなければ改造してみたりが容易に可能です。ここがサードパーティとしては、参加・利用しやすいポイントです。
オープンソースにすることで、よりプロダクトが発展することを狙って企業はプロダクトをオープンソースにするモチベーションを作っています。
マネージドサービス
先ほどマネタイズの方法は3つあると言いましたが、SaaSモデル、つまりマネージドサービスについてです。
最近はマネージドサービスでの提供が増えてきています。なぜかというと、オープンソースは企業からすると実は無料ではなく、オープンソースを運用するための人件費がかかっています。
「オープンソースだから」・「無料だから」と自分のところにプロダクトを入れても、難しくてうまく運用できない利用者に、マネージドサービスを提供してもっと便利にしましょうという考え方です。
・OSSベンダーは「僕が一番この製品をうまく使えるんだ！」という観点で、競合他社より優位な立場でマネージドサービスを運用出来る
→これはオープンソースのマネージドサービスなので、誰でも同じようなサービスができるのですが、「自分たちが作った」「自分が一番この製品をうまく使える」という競合他社よりも優位な立場で提供できる強みがあります。
・自分たちのマネージドサービスやEnterprise版に恣意的な改修も出来るし、公式の知名度もある。
→公式は強いです。どこか知らないベンチャー企業よりもMongoDBが運営しているマネージドサービスだと安心感がありますよね。いいモデルなので最近は流行っていました。
・だが、強すぎる競合が現れたら？
メガクラウドベンダー（AWS、GCP、Azure）は顧客の利便性のためにオープンソースのマネージドサービスを提供する傾向があります。特にAWSはその色が強いです。
もちろん私もクラウドの利用者なので、どんどんやってほしいですが、これをされてしまうと実はマネージドサービスを提供する側の会社は困ってしまいます。
公式のGCP、Azureが提供するManaged RedisよりもRedis Enterpriseのほうが高機能だったりするんです。
そもそもRedis社と別で契約するのが面倒なのですが、GCP、Azureのボタンをポチポチして終われば追加の契約が必要ないですし、アカウント管理やセキュリティ管理、ログ管理、モニタリングなど追加の設定も既存のクラウドに統合されています。
現実として、そこまで高機能が必要ではないかもしれませんし、機能差があってもその機能差は不要な部分かもしれません。
オープンソースとしてコードが共有される部分は、基本的にマネージドサービスが提供されないのでそこが制約にはなりませんし、ソースコードの差分が競合競争力ではありません。
巨大なエコシステムを持っていることそのものが競争力なので、どうしてもOSSベンダーは真っ向勝負したら負けてしまうためビジネスモデルが崩壊しがちです。
脱OSSへの道
上記のために脱オープンソースへの道への流れが少しずつ出てきているのかなと思っています。
メガクラウドベンダーが「競合ビジネスになることを避ける」つまり「そのビジネスをしてはいけない」という自由を制限したライセンスを提供しているものが、BSLやSSPLライセンスです。
一見するとオープンソースと同じようにコードの公開・改変・再配・再配布の作成ができるので、オープンソースのようですが、実が利用方法に制限があるので、先ほどのOSSの10個の定義からは完全に反しているのです。
全然自由ではありません。なので、オープンソースと呼ぶべきではありません。
用途の制限や特定組織の制限が入っています。
OSSの定義
先ほども出したOSSの定義の5と6番についてです。
差別の禁止と言いますと、男女差別や国籍差別などのイメージがあると思いますが、ここでは競合企業が使ってはいけないなどと言う「差別」です。
利用分野が規制されるのはオープンソース的ではないということです。
OSSの亜種ではなく商用ライセンス
先ほど述べたBSAや SSPLはオープンソースの亜種ではなく、商用ライセンスと言う前提です。
商用ライセンスは、オープンソースのエッセンスが入り込んだものなので、これはOSSと呼ばないほうがいいのです。良い悪いではなく「別もの」として理解したほうが良いです。
Source-available License
別物としての呼び方として、「非商用のオープンソース」「特定用途禁止のオープンソース」など謎の単語で説明されることが多いのですが、そもそもオープンソースのオープンの部分が否定されているので冠をつけて違いに出すのも良くないと思っています。
そこでSource-available License、SALという言い方があります。コードが公開されているもの全てがSALです。
あまり流行っている言い方ではありませんが、Wikipediaにも掲載されている言葉ですし、オープンソースはブランドがある固有名詞なので、そこは敬意をもって別の呼び方をしようと思い最近はSALと呼ぶようにしています。
図にすると以下です。
Oracle DBやWindowsのようにお金を払って買う商用ライセンスもあれば、Docker Desktop ライセンスのように基本的には無料でも一定の規模のユーザーが使う場合は有料にしている商用ライセンスがあります。
分かりやすくSALの中にはオープンソースがあり、GPLやLGPL、AGPL 、BSD／MPL／Apacheがあります。さらにSALの中にオープンソースではない、ソースコードavailableがあり、それがSSPLやELv2やBSLです。
このお話をいただいた後に登場してどう扱ったらいいか困ったのがこの、Fair Sourcr(FSS)です。
Fair Sourceは、ソースコードavailableで、かつ商用ライセンスの中でさらに特定の領域を指している言葉になります。
代表的な非OSSのSALの例
・Business Source License (BSL)
→BSLは、採用しているは採用しているところが多いです。競合の利用を禁止、提供範囲を管理可能なライセンスになっています。
・Elastic License v2（ELv2）
→マネージドサービスの提供をしなければ、だいたい普通のオープンソースやBSLライセンスと同じように使えます。
・SSPL
→マネージドサービスを提供してもいいですが、もしした場合はそれに関連したソースコードではない部分……例えばダッシュボードや監視ツール、バックアップなど全て公開が必要になります。
オープンソースライセンス的には真っ向から戦っているライセンスです。相当広い範囲で、実質公開NG、公開するなと言っているようなライセンスです。
総じて利用者目線には関係ない部分です。自分たちがElasticsearchを使いたい場合に、これに引っ掛かることはほぼないと思ってもらいたいのですが、自分たちがElasticsearchを使ってビジネスをしたり、改造して何かを作ろうとしたりするときには、これらのライセンスが影響するかを気にする必要があります。
ユーザー目線では関係ないですが、デベロッパー目線では気にしなければなりません。
Fair Source Software
さらに最近登場したのがFair Source Softwareです。商用のSALの中の新しい定義で、一定の制限の下、コードの公開/改変/再配布が可能になっています。
さらに大きな特徴が一定の期間後にOSSに変わる遅延OSS公開（DOSP）の考え方を採用しています。
この2つが主な特徴でこの2つしかライセンス情報には書いていません。
一定の制限は何でもいいんです。「マネージド禁止」でも、「1000人以上の会社は有料」でも何でもいいんです。一定の期間も「5年」でも「10年でも」よくて、それぞれのFCLなど個別のライセンスに規制されています。
印象としては一定の期間、開発元の先行者利益を得てからオープンになるので、特許と発想や考え方は近いと思います。
特許期間はライセンス料を払い、特許が切れたら自由ですというイメージなのかなと思います。
OSSから変わる事の懸念
懸念事項というか注意点です。
大前提としてビジネス上の選択であり、悪ではないんです。自由よりも大切なことはたくさんあるので、選んでください。悪ではありませんが、ライセンス変更はコミュニティと軋轢を生みやすいです。
特に非オープンソースの場合、例えばBSLだと突然競合他社だと言われると使えなくなるんです。
それをCTOの立場で「自分たちのコアプロダクトにそのテクノロジーを採用しますか？」という懸念や、法務として「何が制約されているかよくわからないライセンスをあえて選びますか？」という懸念です。
開発者もどんどん便利にしようと思いcontributeしているのに、ある日突然競合企業認定されたらそのcontributeした自分のコードが使えなくなるので、「そんなところに貢献しますか？」という話です。
あえてとるかという部分では、社会として受け入れられていない部分なので少し気になるところです。
悪いことばかりではない？
ただ、悪いばかりではありません。一般の利用者はそもそもコードを改修しません。私もオープンソースのライブラリやプロダクトのコードを見るなど修正したことはありますが、Linuxのコードを見ているか、MySQLのコードを見てメンテナンスしていますか？と聞かれると、そんなことはしていません。
みんなが全部見るわけではないので、Elastic社もライセンス変更によってユーザーが減ったりはしていないという言い方をしていました。
ここからは個人的な見解ですが、別のコミュニティの形もあるのかもしれないと思っています。
自由で集まるコミュニティではなくて、企業とファンという「推し活」のような形のコミュニティもあっていいと思っています。自分が作った修正やチケットが公式にマージされたら嬉しいですよね。
そのモチベーションでコミュニティを運営するのもありだと思います。
新しい形を目指してもいいと思います。
競合を気にしなくてもいいのでエンタープライズ系のコードも公開が可能になるかもしれません。コミュニティモデルとエンタープライズモデルを分けることがあると先ほど言いましたが、それを最初から同じリポジトリで管理できるので運用がスッキリする面もあります。
オープンソースの利用でよくありがちなのは、自分のプロダクトで使いたいのに相手のオープンソースに入れてくれないということです。
当然契約を結んでいなければ、仕方ないのですがそのような話が最初からクリアされたりもするので、実はうまい関係が築けるケースや、最初からマネタイズを意識した関係が築けるケースがあります。またフリーライドになっていないケースもあるので、それもいいと思います。
何よりも儲からなければ開発は継続できません。ビジネスの場合は、サステナビリティがとても大切になると思うので、儲かるためにこのようなライセンスを選ぶのは悪いことではなく、むしろいいことかもしれません。
ただ先ほども申し上げた通り、変えることに注意は必要です。
AIとオープンソース
オープンなAIモデルとして、LLamaやGoogleのGemmaなど名前をよく聞く有名なものがあります。無料で使えてモデルも改変できて、商用利用もできるのでオープンソースなAIやオープンソースなモデルと紹介されることも多くありますが、全然オープンソースではないんです。
Googleはこれらのモデルのことを、オープンモデルやオープンウェイトモデルと言っていますし、Metaやニュース記事も最近はオープンモデルと言っていると思います。まだ、たまにオープンソースと言っている人もいますが…。
なぜオープンソースではないかと言うと、推論とチューニングは使えますが、元のデータセットやモデルを作るための詳細がないので、オープンソースで言う完全なソースコードが無い状態となんです。
かつ、こちらの方が大きな理由ですが実は禁止事項がかなりあり、「この用途で利用してはいけません」ということが山盛りに書いてあるのです。オープンソースの誰でも使って良く、どんな用途でも使っていいということには当てはまりません。
アダルトコンテンツの利用はだいたい禁止されています。ほとんどの人にとってそれは問題ありませんが、禁止すること自体がそもそもオープンではないということです。
OSAID: OPEN SOURCE AI DEFINITION
OSIでも今、OSIによる真にオープンなAIの定義を作っています。OSAIDでは利用、研究、改変、共有を常に保証することになっていて、「あなたはだめ」「この用途はだめ」ということは一切ないです。
その4つの自由は、ソースコードだけではなくモデル、データ全てに適用されています。どんな学習データを使ったのか、どんなモデルなのか最終的に最適化されたパラメーターだけではなく、重要な中間になるようなモデルも公開するべきですし、ソースコードも本体だけではなくデータの前処理からセットで公開されています。
つまり同じモデルをある程度の熟練者だったら作れる状態になって初めてオープンだとOSAIDは最近定義しました。
まとめ
Fair Sourceの考え方やAIのオープンモデルの考え方などOSSのエッセンスを含んだ商用のSource available licenseが最近増えてきています。
これはマネージドサービスの禁止などビジネス的な都合もありますが、それと同時に開発のコミュニティや開発のエコシステムにあるいろいろなメリットを両立させるための新しい形になっています。
ソフトウェアにとって自由はとても大切です。
私はフリーソフトウェアの考え方やオープンソースの考え方の自由もとても好きですが、そればかりではありません。それだと商用ソフトが全て否定されてしまうので、新しい形を目指してもいいとは思っています。
一方で、利用制限が不透明、かつ定番のライセンスがまだ決まっていないため、毎回AIやFair Sourceでどのような制限があるのかを気にしないといけません。「BSLならこれをしていい」、「GPLではこれをしてはダメ」ということは、歴史の積み重ねで分かってきていますがFair Sourceではまだそうではないので、そこが注意点だと思っています。
大谷：紅月さんありがとうございました。
最近のライセンスとその動向について改めてありがとうございました。
コメントでも来ていますが、もともとユーザー・一般のエンジニアが使うことを想定したライセンスが前提となっていて、昨今クラウドベンダーの侵害が対応するためにsource available licenseが出てきた流れでしょうか。
紅月氏：そうですね。もともとAGPL？などがそれに近いので想定されていないわけでもありません。
大谷：そうなんですね。この後のディスカッションでもまた詳しく聞いていければと思っています。
