Bearがソース公開ライセンスへ移行
(herman.bearblog.dev)- BearプロジェクトがMITライセンスからElastic Licenseへ移行
- 以前のMITライセンスはコードの自由な利用とフォークを許可していたが、新しいライセンスではこれをホスティングサービス提供に制限
- 複数のオープンソースプロジェクトでも、ただ乗り競争の防止のために同様のライセンス変更を導入する流れがある
- 人工知能時代にはコードの複製とサービス化が非常に容易になった状況
- コードの公開性も重要だが、ユーザーコミュニティと継続的な運営意思がBearの中核
Bearソース公開ライセンス移行の背景
- Bearプロジェクトは当初、MITライセンスでソースを公開し、学習や監査可能性、ユーザーにプライバシーとセキュリティへの信頼を提供することを目指していた
- しかし時間がたつにつれ、Bearプロジェクトのコードを基にした競合サービスが登場する事例があった
- 自分のソフトウェアを愛情を込めて開発してきた一方で、ソースが簡単に複製されて競争相手として戻ってくる現象に喪失感と経済的な危機感が生じた
- オープンソースの価値を信じていたが、現実には困難を抱える状況だった
ライセンス変更の決定
- 最近の出来事をきっかけに、MITライセンスからElastic License（Elasticsearchで導入されたコピーレフト方式）へライセンスを変更することを決定
- Elastic LicenseはMITに似ているが、ソフトウェアをホスティングまたはマネージドサービスとして提供する行為を禁止する
- 具体的なライセンス条項はGitHubリンクで確認可能
オープンソース生態系の動向
- 調査の結果、多数のオープンソースプロジェクトがここ数年、**「ただ乗り競争」**を防ぐためにライセンスを制限する流れにある
- 例: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry など複数のプロジェクトが同様の決定を実施
人工知能時代と競争激化
- AIコーディングツールの登場により、「このリポジトリをフォークして名前を変えた後、EC2にデプロイしてみて」といった迅速な複製とサービス化が可能になった
- このような環境変化は、原著作者により大きな負担とリスクをもたらすようになった
Bearの特別な価値
- Bearプラットフォームの真の価値は単なるソースそのものではなく、それを利用するコミュニティと運営者の長期的な責任感に由来する
- 今後、コードレベルの制限が一部生じても、プラットフォーム自体は誠実に維持管理していく意思を表明している
3件のコメント
GLPv3 と AGPL は、このライセンスの作者の意図どおりには使われていないように思います。
多くがデュアルライセンスを認めているせいで、結局は商用利用を強制するための仕組みとして使われるケースをあまりにも多く見てきました。
その意味では、Apache や MIT は当初の意図どおりに機能している数少ないオープンソースライセンスだと思います。
（ただし、完全無欠なオープンソースライセンスがあるとは思っていません。）
Hacker Newsの意見
私の理解では、「Open Source」陣営は、AmazonがAWSのサービスとして提供できないならそれは真のオープンソースではない、という立場で、誰かがそう主張すると非常に不快に感じるようだ。
みんながこの筆者の言う「フリーライド競争」という現象をもう少し認めてくれればと思う。Hermanがやっていることはみんなのためになることであり、だからこそ "source-available" よりも温かみがあって、コミュニティプロジェクトをきちんと表せる新しい用語があればいいのにと思う。
下のコメントで自分の考えがうまく要約されていたので追記する。
市場の自然な独占化構造は、自由・オープンソースソフトウェア（FOSS）のミッションに役立たない。大企業がこのやり方で利益を得るのを止めなければ、むしろオープンソースの使命を深刻に損なう問題だ。そしてその過程で、利用者は大企業の独占的ソフトウェアとFOSSを組み合わせた罠にはまる
もともとオープンソース陣営の態度は、GPL → GPLv3 → AGPLのようなライセンスで、こうした問題を明確に防ぐやり方を支持していた
MIT/BSD/Apacheのような全面的に権限を与えるライセンスが広く使われるようになったのは、企業の利害に合わせて自由ソフトウェアの理念を弱めようとした意図的な流れに見える
ほとんどの人は、オープンソースではないソフトウェアにもそれほど不満を持っていない
問題は、Terraformのようなプロジェクトがオープンソースだったから人気を得て成長したのに、その管理者がクローズドなライセンスに変えてしまい、元の成功の土台が失われた状況にあることだ
そのうえ貢献者たちがCLA（貢献者ライセンス契約）に署名していて、その人たちのコードまで勝手にクローズドライセンスへ変えられてしまう場合は、二重に失望させられる
オープンソースに関心がないなら使わなければいいだけで、これまでオープンソースには明確で一貫した意味があった
それぞれ自由にソフトウェアを作ればよく、信じる価値観に応じて選んで使えばいいのであって、わざわざ問題にすることではない
誰でも好きなライセンスを使えるが、なぜ大半のオープンソース開発者がMITのような寛容なライセンスを選ぶのか考える必要がある
現実には市場に良いオープンソースが多く、選択肢は広い。ライセンスに制約を付ければ、人々は単に別の代替案を選ぶ
だからGPL系でライセンスすると、プロジェクトが大衆的に使われにくくなる。もちろん例外としてLinuxやWordPressは大成功したが、特に一般的な現象ではない
MITのような寛容なライセンスでも収益化は難しいが、利用者自体がいなくなればなおさらだ
これが良いか悪いかは議論があるが、実際にはみな合理的に行動しているように見える。本質的にソフトウェアはそれほど希少ではない
AGPLはまさにこういうケースのために作られたのでは？
AGPLは、ネットワークサービスとしてソフトウェアを提供する場合に制限を設ける、OSIが認めたオープンソースライセンスだ
メンテナーがFair Sourceを見たことがあるのか気になる fair.io
Fair Sourceは "source-available" より優れていると思う。DOSP（opensource.org/dosp）の下で完全なオープンソースになる道筋でもあるので、無料ユーザーにも有料ユーザーにも有益で、特にBearのようなブログプラットフォームに理想的なモデルだ
FCL（fcl.dev）Fair Source LicenseもBear Blog Licenseの方向性と似ていて、Bear manifesto（herman.bearblog.dev/manifesto/）にもよく合っている
たとえBear PTY LTDがなくなっても、Bear自体は残り続ける構造を作れる（DOSPとして規定可能）
私はFair Sourceの作成にも関わった立場だ
それでも "fair source" という用語は悪くない響きだ
ApacheやMITのように、時間が経てばオープンソースになるソフトウェアならfair sourceに当たると考えてよいのか、それとももう少し複雑な基準があるのか気になる
ある人は、少し甘かったのだと思う。MITライセンスを選べば、誰が自分のコードをどう使うかは自由だ。後になって稼ぎたくなったら、解決のために変わったライセンスへ変える
結局のところ選択肢はMIT/BSD、GPL、LGPL、AGPLで、それ以外のライセンスは無駄な互換性問題を生むだけだ
私もこの見方に同意する。本当に「無条件で」ソース公開がしたいならMITを選べばいい
今回は明らかにそう考えて選んだのではなく、やや曖昧に「善人ぶること」と「事業家ぶること」の両方をやろうとしたのではないかと思う
MPL（Mozilla Public License）もかなり有用で過小評価されているライセンスだと思う
GPL系よりは明らかに感染性が弱く、MIT/BSDよりは制約がある（変更点は配布時にソース公開が必要）
MITとBSDには特許権の保証がないので、Apache Licenseを選ぶのがよい理由になる
Guy（作者）は、単に自分のプロジェクトを作り、ソースを公開することに意味を置いていたように見える
特に別の戦略的な目的はなかったと思う
オープンソースプロジェクトが永遠にオープンソースであり続けると信じるユーザーも甘い
ライセンスを変える権利は著者たちにあり、それに驚くのも、オープンソースで事業化が簡単だと信じるのも、結局はどちらも甘い態度だ
競合利用を根本的に封じたいなら、こうするのが普通だ。もはやオープンソースという言葉を使わないのも正しい選択だ
ただ、たいていの状況ではAGPLのほうがより良い代替案だと思う。AGPLなら、大企業が社内規定のためにコードを使えず、大手事業者の参入を防ぐ効果がある
オープンソースの本来の意味を裏切る行為だ
「MITで公開しておいて、自分のコードを誰かが商売に使って金を稼いでいる。そんな結果を予想していなかったというのが不思議だ」
なぜこういうことが繰り返されるのか？ なぜこんなにも多くの開発者がこの当然の結果を見通せないのか不思議だ
MITは、GitHubで新規プロジェクトを作るときにドロップダウンで選ぶだけで自動的に設定される、参入障壁の低いデフォルトだった
プロジェクトが新しく、どう発展するか分からない段階では、後でライセンスの心配をするほど大きなプロジェクトになるとは想像しにくい
MITライセンスは、もともとプロジェクトがいつでも新たに再ライセンスすることを許している
Bearの管理者は、最初は寛容なライセンスを選び、状況が変わるとより厳しいライセンスへ変えた
私には非常に合理的な意思決定に見える
15〜20年前にBSD陣営がオープンソース文化戦争で勝ったからだと思う
もしGNUライセンス陣営がその戦争に勝っていたら、今日のエコシステムはどう違っていたのか気になる
Bearがオープンソースだから支援していたのに、そうでないならもう支援する理由がないので購読を解約した
これがAGPLに戻るなら本当に望ましい
Bearには望むライセンスを使う自由があり、私はそれを使うかどうか決められる
オープンソースライセンスの目的は、基本的に金銭的利益ではなく共有そのものだ
オープンソースプロジェクトだけを支援するのも完全に理解できる
収益を生み出さなければならない段階になると、オープンソースライセンスはもはや適切ではないかもしれない
一部の開発者はオープンソースが収入を守ってくれると誤解し、一部の利用者はプロジェクトが永遠にオープンソースのままだと勘違いする
source-availableやshipped-with-sourceのようなモデルも一種の独占的（プロプライエタリ）ライセンスであり、必ずしもオープンソースである必要はない
「ユーザーは、ソフトウェアの主要機能を提供するサービスとしてホスティングしたり、マネージドサービスとして提供してはならない」
私は弁護士ではないが、この制限が自分でインストールして社内用または個人用にBearを運用することまで制限するのか気になる
実際それもできないのなら、MITライセンスを使っていた理由が分からない
Bear Blog License 原文
しかし、他人や他社にサービスとして提供するのは不可だ
参考: Elastic License FAQ
脱力感には共感するが、新しいライセンスは少し曖昧だ
「ホスティング／マネージドサービス経由で機能提供不可」と言うとき、一般的なVPS事業者（パッケージマネージャーでインストールするようなもの）も制限されるのか？
1-clickインストールのようなセットアップスクリプトがある場合はどうなのか、サービスの過程で案内さえしなければ問題ないのか、曖昧だ
第三者がインストールスクリプトを提供するのはよくて、サービス段階で言及さえしなければ何でも通る、というような「芝居」に感じる
つまり、このソフトウェアをサービス（無料／有料）として他人に提供してはいけないのであって、自分だけで使うのは問題ない
要するに、アカウント提供そのものが禁止されていると考えるべきだ
ターンキーホスティングの提供も禁止ではあるが、この場合に問題なのはホスティングを提供する側ではなく、そのホスティングインスタンス上でユーザーアカウントを作って売る側だ
この文言は、Amazonのような大企業がデータベースインスタンスを外部に提供し、その上でアカウントだけ発行するのを防ぐためのものだ
一方で、単にVM上でパッケージマネージャーからインストールするだけなら問題ない
それでも、この種のライセンスは非常に混乱しやすく不明確だ
もしオープンソースのままにしておくつもりで、多くの人に使ってほしいのに、他人にホスティングされるのは望まないのなら、わざわざコードを共有する必要はなく、"All rights reserved" のままにしておけばよい
動機やソース公開の意図は理解できるが、競争を懸念していたのならMITではなくAGPLを検討していてもおかしくないので気になる
AGPLでも結局、他人がコードを改変せずそのまま商用で再販できるのでは？
AGPLは変更点のソース公開を強制するだけだ
ここでは、Bearblogをほぼそのまま、あるいは名前を少し変えただけで商用提供するようなケースが問題なのだろう
たぶん最初は競争が問題だとは思っておらず、だんだん問題になってきたのでライセンスを変えたのだろう
このやり方（ソース公開 + ホスティング制限など）は、個人的には最高のライセンスモデルだと思う
自分の好みに合わせてコードを確認したり変更したりできる一方で、プロジェクトとメンテナーは過度な競争圧力なしに自分たちの基盤を守れる
最初からこう始めていれば、後から急に変わって揉めたり、フォークが本家を上回ったりすることも防げる
Bearがそこまで大きな反響を呼ぶようなプロジェクトだったとは思わないが
私はmataroa.blogも時々便利に使っているし、Bearのメンテナーにも自分のプロジェクトにやりがいを感じてほしい
実際、オープンソースプロジェクトにとって利用者の関心と貢献はほぼ唯一の資源ですが、
完全に定着した段階でない限り、誰でも、特に大企業がフォークして関心を独占してしまえば、結局は他人のためだけに尽くしたことになってしまいます。
そもそもこの種のライセンスは、最初から利用者の自由のためのものであって、開発者のためのものではありませんでした。
Windows の CLI パッケージマネージャーである winget も、他人のプロジェクトを Microsoft がそのままフォークし、名前だけ変えて公開したものだという事実をご存じですか。
元のプロジェクトである appget の作者が書いた文章もあります。
The Day AppGet Died.
（特に大企業やバイラル拡散が得意な人たちのための）他人のためだけに尽くすことを望まず、自分の時間に価値を置くのであれば、オープンソースライセンスを採用することを改めて考え直す必要があります。
同じボランティアでも、貢献に対して敬意を払われることと、徹底的に無視されることの間には大きな違いがあります。
Hacker News のコメントに付いていたような代替案を見てみてください。