- Liquibase は従来のオープンソースライセンスから Functional Source License(FSL) へ移行した
- FSLはOpen Source Initiative(OSI)の基準では 公式なオープンソースライセンスではない にもかかわらず、READMEなどでは依然としてオープンソースプロジェクトとして紹介されていることが問題視されている
- コミュニティでは、FSLは 公式なオープンソース基準に違反する という意見と、FSLはオープンソース要件を満たしているという相反する意見が示されている
- プロジェクト内ではREADMEでのオープンソース表記について 修正作業が進行中 である
- FSLには競合的利用を制限する条項などがあるため、OSI Open Source Definition(オープンソース定義) の一部条項に抵触するとの指摘がある
問題の概要
- Liquibaseプロジェクトのライセンスは最近 Functional Source License(FSL) に変更された
- しかしREADME.mdなどの公式文書では依然として Liquibaseをオープンソースプロジェクトとして紹介 しており、コミュニティ内で混乱と意見の対立が生じている
報告内容と論争
- Issueの作成者は、LiquibaseがFSLへ移行したにもかかわらず依然としてオープンソースであると明記している点が問題だと指摘している
- FSLについてはLiquibase自身も オープンソースライセンスではないと述べた ことがある
- プロジェクト文書でオープンソースという用語がこれ以上使われないよう、READMEおよびその他の文書の修正が求められている
コミュニティおよび関係者の意見
- 一部の参加者は、FSLは OSI承認のオープンソースライセンスの基準を満たしていると主張 しており、FSLが正式なレビューを経てOSI承認ライセンスになれば問題はないという立場である
- これに対し別の参加者は、FSL内の「許可された目的」条項などにより OSIのオープンソース定義の複数の条項(第1、3、5、6項)に違反すると強調 している
- 「Fair Source」と「真のオープンソース」を区別すべきだと強調し、FSLは Fair Source として分類されるべきだという意見もある
問題解決の過程と文書修正
- プロジェクトのコントリビューターは問題提起に対応して README.mdを修正し、オープンソース表記を段階的に削除 している
- ただし、リポジトリの各所には依然としていくつかの
open source、oss という表現が残っており、追加の確認と整理が行われる予定 である
オープンソース定義とFSL(Functional Source License)の問題
- Richard Fontana などオープンソース陣営の代表的な人物は、FSLが競合的利用の禁止などの条項によりOSIのオープンソース定義に違反する ことを明確にしている
- オープンソース定義には 「分野および個人・団体に対する差別の禁止」 などの条項があり、競合用途の禁止などはこれに反するとされる
- FSLは2年後にMITまたはApache Licenseへ移行し、完全なオープンソースになる予定だが、それまでは 制限付きの条件が残る
結論と現状
- このIssueは、Liquibaseのオープンソース表記の修正過程 において、コミュニティの透明性要求とオープンソースの本質に関する議論を促している
- READMEなどの公式文書の修正作業は開始されており、Fair Sourceとオープンソースの区別基準 が実例として議論されている
- OSI承認の有無にかかわらず、ライセンスの実際の条件が 国際的なオープンソースコミュニティで大きな意味を持つ状況 である
1件のコメント
Hacker News の意見
4.x バージョンを今後使えなくなる場合に備えて、代替手段を探し始めている。
OSS ライセンスから有料化への転換については、誰かが有用なソフトウェアで収益を上げたいと考えること自体は理解できる。
しかし、オープンソースからライセンスを変更するのは一種のベイト・アンド・スイッチ戦術だと思う。
こうした決定はすぐに信頼を壊し、短期的には収益化が難しくても長期的に可能性のあるユーザー層まで失うことになる。
Elastic や TerraForm の事例から、すでに重要な教訓を得ているはずだと思っていた。
Flyway もいつ同じ道をたどるかわからず、信頼が揺らいだ感じがする。
フォークが出てこないなら、自分たちの実運用に合う migration ライブラリをいっそ自作することも検討している。
Liquibase は単に便利だから使っていただけで、決して代替不可能ではない。
EventStoreDB（今は KurrentDB）や NATS についても、サービスの信頼性という面では疑わしく見ている。
EventStoreDB はすでにライセンスを変更しており、NATS もユーザーの反発で計画を取り下げただけだ。
今ではこうした動き自体が一種のビジネス戦略になってしまったように感じる。
オープンソース最大の利点は、以前のバージョンをいつでもフォークして使えることだ。
本質的には製品価格を引き上げるのと大差ない転換だと思う。
Postgres 専用ではあるが、自動化をさらに一段進めた pgroll というプロジェクトもある。
Flyway（Apache ライセンス）のほかにも、Atlas（Apache）、Sqitch（MIT）のように、まだオープンソースのライセンスは十分ある。
Elastic のライセンス変更は、彼らの視点から見て本当に失敗だったのか気になる。
株価はしばらく下がったが、実際の会社はいまも健在だ。
私の知る検索や RAG 分野の開発者は、今でも Elastic NV が提供する Elasticsearch しか使っていない（オープンソースのフォークや代替ではない）。
特に Elastic が最重要視する主要顧客層（有料顧客）だけを見れば、信頼破壊どころか逆効果ですらなかったように見える。
実際、売上も 2020 年比で 2 倍に成長している。
まだオープンソースだと主張する意見もあるが、Liquibase 自身が FSL はオープンソースライセンスではないと明言している。
Liquibase 公式ブログの告知を参照
最近はソースを公開しているだけなのに、あたかもオープンソースであるかのようにブランディングするプロジェクトが多くて残念だ。
Liquibase が強い copyleft（たとえば GNU AGPL）ではなく Apache を選んだのなら、当然ながら他社がクローズドソースの派生物を作ることは想定しておくべきだった。
結局は Liquibase 自身が選んだことであり、その責任も Liquibase にあると思う。
一定期間後に Apache へ自動的に切り替わる仕組みのようだ。
これがより良いのかどうかは、正直よくわからない。
企業は実際、AGPL のようなライセンスでも自社の目的を十分に達成できる。
Redis も移行したし、コミュニティの反応も好意的だった。
Liquibase が AGPL のデュアルライセンスを選んだからといって、ユーザーが不満を持つとは思えない。
「2 年遅れのオープンソース」あるいは「2 年後にオープンソース」と呼ぶべきだと思う。
実際には「役に立たなくなる頃にオープンソース」だと感じる。
こういうやり方は、本当は自由を尊重していないのに、そう見せかけるイメージだけを与えているのが本質だと思う。
そこまで早く旧バージョンが無価値になることはまれだ。
これを自由への敬意の欠如だとは思わない。
狙いは企業（人ではない）に一定の制限をかけることにある。
エンタープライズ分野でオープンソースの中核にあるのは、「自由」よりも信頼と透明性だと思う。
ソース公開だけでも、法的・収益化の問題なしに FOSS の利点は享受できる。
オンラインでは、オープンソースモデルに対する盲目的な信頼が過剰に現れがちだ。
2 年の混合ポリシーも十分合理的だと思うし、新しいライセンスが嫌なら旧バージョンを使えばいい。
遅延したオープンソース。英語の
lateのように二重の意味を含んでいる。#source-washing
新しいライセンスになじみがなければ、FSL の詳細説明リンク を参照。
FSL に関する追加の文脈として、これは Sentry が作ったもので、なぜこのライセンスが必要で、どんな問題を解決しようとしたのかは Sentry ブログで確認できる。
個人的に唯一許容できるクローズドソースライセンスは BuSL "Business Source License" だ。
有効期間 4 年後に必ずオープンソースになり、それまではソースも公開される。
不要なライセンス乱立も防げる。
Business Source License の Wikipedia も参考になる。
2 年という期間は短すぎるのではないかという疑問がある。
大企業の立場では、5 年前のソフトウェアでも普通に使われているし、私自身も Redis 2012 年版や Postgres 2020 年版で十分だと思う。
こうしたケースの履歴や企業リストをまとめたことがある。
関連ブログ記事 に整理してあるので、ほかにも知っていれば共有してほしい。
Pro 機能がコミュニティ版の文法をたびたび壊すので、透明性はまったく感じられなかった。
もちろん作業に対する正当な対価は必要だが、「自分たちはオープンソースだったが、こっそりそうではなくなった」はあまりに一般的になりつつある。
こうした転換は、誰にも気づかれないことを願うように、いつもひっそり進められているように見える。
実質的な損害や主な問題が何なのか気になる。
むしろ競合分野と非競合分野を区別している点は気に入っている。
コメント欄の雰囲気が少しおかしく感じる。
多くは「base」だけを見て無関係なサービスを勧めたり、ソースを公開していればオープンソースだと主張したりしている。
Liquibase がライセンス変更したことを知らなかった。
実際、ほぼすべての Web フレームワークには代替があり、Alembic や Flyway のようなフレームワーク非依存の代替も多い。
このタイミングでは少し奇妙に見える。
今回の件は Keycloak のような OSS プロジェクトにも問題を引き起こしかねない。
CNCF のポリシーでは非オープンソースライセンスは使えないため、Keycloak は Liquibase を使えない。
Debian や Fedora などでも OSS ライセンス要件があるため、こうしたディストリビューションに Liquibase 依存プロジェクトを含められるのか気になる。
Keycloak の issue 詳細リンク
ただし、個別のリポジトリや rpm fusion non-free のようなカスタムリポジトリであれば含めることは可能だ。