Business Source License 1.1
HashiCorp が OSI オープンソース・ライセンス のソフトウェア (以降 OSS) 製品を Mozilla Public License 2.0 (以降 MPL) から Business Source License 1.1 (以降 BUSL) にライセンス変更して話題になっています。
自社は主力製品はクローズドソース、それ以外は Apache License 2.0 で OSS として公開という戦略をとっていることもあり、 BUSL について自分の考えを雑に書いておこうと思います。
法律の専門家ではないので、間違いもあると思います。きっちり理解したい人は弁護士に相談しましょう。
Business Source License 1.1
MariaDB が公開したライセンスで、OSS ではなく、ソースコードを公開するためのライセンスの１つです。
- 実稼働環境での利用は許可されていない
- 追加使用許可が指定可能
- 公開してから一定期間が経過するとライセンスが切り替わる
HashCorp の場合は 4 年で MPL に切り替わり、その 4 年間は追加使用許可として以下が指定されています。
お客様は、HashiCorp の製品と競合するホストまたは組み込みベースでライセンス作品を第三者に提供することを含まない限り、ライセンス作品を実稼働環境で使用することができます。
簡単に言うと競合はマネージドサービスやったり、ソリューションサービスやったりするんじゃねーぞ。それ以外は実稼働環境で利用していいからな。という内容です。
零細企業から見た BUSL
かなり良いライセンスに見えます。特にミドルウェアやツールをソースコードを公開しつつ競合対策するには良さそうです。競合でなければ多くの場合は追加使用許可により特に困ることはなさそうです。
BUSL で製品を公開している企業は「BUSL 以外の商用ライセンスも提供する」という選択肢も用意していますが、HashiCorp も同様です。お金で解決できるのはとても健全だと思いますので、お金を払って使い続けることができます。一切のシャットアウトってわけじゃないのも良いところだと思います。
OSS で稼ぐのは難しいのか
難しいと思います。多くの場合はサポート契約だったりクラウドサービスで稼ぐことが多いですが、大手がクラウドサービスやり始めたりもしますし、サポート契約は入ってくれない企業がほとんどです。そうすると詰みます。
そのため、クラウドサービスは独占事業にするのが一番手っ取り早いです。
自社から見た BUSL
自分は時雨堂という零細企業を経営しています、主力製品はクローズドソースのパッケージ製品でサブスクリプションライセンスモデルです。それ以外の SDK やツール類は全て Apache License 2.0 で OSS として公開しています。
実は BUSL を色々調べたりしていました。理由は主力製品のソースコード公開版を提供しようと考えているためです。
主力製品はクローズドソースでサブスクリプションライセンスは気軽に使って貰いづらいです。そのため自社の顧客は多くが大企業です。もっと中小企業に使って欲しいのですが、特別価格とかは既存顧客への裏切りになるため一切やりたくないため、新規に主力製品の一部互換（つまり色々機能が実装されていない）版の開発 (Erlang ではなく Go で 1 から実装する)を検討しています。
ただ、このソースコード公開版を競合に実稼働環境で気軽に利用されるの普通に怠いです。そのため BUSL は選択肢の１つとしてとても良いなと感じています。
OSS の精神とかそっちの考え
BUSL は OSS ではないので、BUSL への移行をする際は OSS の精神とか何かを言うのは不要だと思っています。ソースコードが公開されており、利用に制限があるライセンスを採用したビジネスに切り替えたというだけでいいのではないでしょうか。変に OSS に乗っかるのはやめるべきだと思っています。
特に実稼働環境での利用が禁止のライセンスなので OSS とは大きく乖離していますので、そのライセンスをもって OSS の精神がとか言うのは見当違いだと思います。
コミュニティ版という表現
BUSL を採用した企業がよく BUSL 版の製品をコミュニティ版 (Community Edition) という言い方をしていますが、これはうまい言い方だなと思っています。
ソースコードが公開されており、実稼働環境以外では自由に利用できることもあり、調査や貢献はしやすいという意味でのコミュニティ版なんだと勝手に思っています。
TimescaleDB は独自ライセンスですが、マネージドサービスだけを禁止したコミュニティ版を提供しています。
まとめ
今後は BUSL を最初から採用したソースコードを公開した製品のビジネスはありだと思います。途中から変更するのではなく、最初から競合への牽制がされてるの悪くないのではないでしょうか。
OSS じゃないといってもソースコードは公開されているわけですし、悪くない選択肢だと思います。
追記1: AGPL-3.0-or-later (以降 AGPL) について
BUSL ではなく AGPL を採用すればいいのでは？と考える人もいるかもしれませんが、多くの企業では AGPL ライセンスを採用しているだけで製品が選択肢に上がらない場合が多いと思います。これは AGPL がどのようなライセンスなのかを理解している人が少ないからだと思います。実際、AGPLv3 の製品を自社サービスにライセンスを買わずに採用する企業は多くないと思います。
また、ビジネスをする際、企業側としては「改変した際にコードを公開して欲しい」というよりも「競合に利用されたくない」という思いの方が強いのだと思います。
BUSL は前提として実稼働環境を禁止しており、追加使用許可が明確です。利用する側には OSS でなくてもソースコードが見れて、ライセンスが明確であれば充分な場合が多いというのもあると思います。
