ソフトウェア企業の中には、自社技術のアピール、利用者のコミュニティ形成のため、自社プロダクトをOSS化するところもある。
こういった企業が収益を確保するには、例えば、プロダクトは無償で提供しつつも、導入サポートやプロダクトを利用するプラットフォームを有償とすることで儲けるという方法が考えられる。
OSSによる収益化の課題と脱OSS
しかし、近年は競合参入（大きなクラウドベンダーなど）によって上記のビジネスモデルが脅かされるリスクが大きくなっている。
OSSコミュニティによって得られる恩恵は大きいものの、「純粋にOSSを使って商用展開する事業者（クラウドベンダー）」が恩恵を受ける一方で、開発元への還元が少ないというわけである。
その結果、これまでは自由な再配布を認めていたライセンスの再策定が進んでおり、いくつかの製品では、非OSSのソース公開型ライセンス（Source-available License, SAL）に移行してきている。
具体的には、ビジネスモデルを保護できるよう「競合他社を排除する」という観点が取り入れられたSALへ変更する動きである。
OSSの定義
ここで、OSSの定義について振り返っておきたい。
OSS（オープンソースソフトウェア）とは、Open Source Initiativeによって以下のように定義されている。
- 自由に再頒布できること（無償か有償かは利用者の自由）
- ソースコードが入手可能であること
- 派生ソフトウェアの作成・派生ソフトウェアを元と同じライセンスで配布することの許可
- 作者のソースコードの完全性（integrity）
- 個人や団体に対する差別の禁止
- 利用分野に対する差別の禁止
- 再配布時の追加ライセンスの禁止
- 特定製品でのみ有効なライセンスの禁止
- 他のソフトウェアを制限するライセンスの禁止
- ライセンスは技術中立的でなければならない
このように、OSSでは「個人やグループに対する差別の禁止」「利用する分野に対する差別の禁止」という項目があるため、競合他社の参入を防ぐことはできない。
Source-available License (SAL)
これに対し、各企業が移行を進めているのが非OSSのSource-available License (SAL)である。
SALは「ソースコードが利用可能なライセンス」を意味し、OSSも含んだ概念であるので、ここでは非OSSのSALという少しまどろっこしい表現となっている。
非OSSのSALとして、例えば以下のようなものが挙げられる。
ご覧の通り、競合参入を抑制するべく、利用時には特有の制限事項が設けられていることが多い。
| ライセンス名 | 特徴 |
|---|---|
| Business Source License (BSL) |
・一定期間は商用利用/競合製品開発など特定用途への制限あり ・商用利用時に商用ライセンス契約が必要な場合あり ・一定期間経過後、通常のOSS（Apache 2.0など）に変わる ・多くの場合、非商用目的では無償で自由に利用可能 |
| Server Side Public License (SSPL) |
・SaaS提供の場合、SaaS運用に必要な管理ツール/関連ソースコードの公開も必要 ・非公開でSaaS提供する場合、商用ライセンス契約が必要 |
| Elastic License 2.0 (ELv2) |
・製品をマネージドサービスとして提供する行為の禁止 ・ライセンスキー保護機構の回避や、ライセンスキーで保護される機能の削除/隠蔽の禁止 ・使用許諾/著作権/その他の通知を削除したり、分かりにくくする行為の禁止 |
SAL移行のメリットとデメリット
自社のコードを非OSSのSALとするメリットは、競合他社による商用利用を規制し、自社製品の収益化を強化できる点である。
一方、OSSの精神（自由な利用）からの逸脱によりコミュニティからの信頼が低下し、その利用リスクから利用者や貢献者が逃げる可能性がある。
また、制約に関係する用語の定義が曖昧なライセンスもあるのが懸念となる。
例えば、BSLの場合だと、「競合製品とはどこまでを指すのか」が良く分からず、提供元から突然「おたく、うちから見たら競合他社ですわ」だと言われると、コードを使えなくなる状況が生じることもあり得るわけである。
まとめと所感
以上のように、OSSは成長段階で収益化とのバランスを取るために、非OSSのSALへの移行が増加している。
こういった取り組みは、「OSSとしての自由」と「持続可能な商用ビジネス」のせめぎ合いを象徴している。
しかしコードを利用する立場としては色々と制限事項もあるわけで、あくまで個人の意見ではあるが、開発部から「これ使いたい」と言われると、判断が中々難しい。
OSSライセンスのように知見が蓄積されていないケースも多く、場合によっては想定外の利用制限が発生し、コードの入れ替えであったり、最悪ソフトウェアの販売を中止するというリスクもゼロではない。
知財業務として一番避けるべきは特許侵害による差止請求であるところ、特定のSALについても同様に製品販売に支障をきたす可能性が捨てきれないのであれば、そのコードの利用は避けるよう開発部に提言することになるのだと思う。
「知財がブロッカーになって開発がスピーディに進まない」と思うエンジニアもいるかもしれないが、そこは丁寧に背景を説明するしかない。