アプリケーションサービス提供事業者の皆さん、サービスを実現するためにサーバサイドでOSSを数多く使っていることと思います。そのOSSのライセンスを意識していますか。あまり意識してこなかったのではないでしょうか。「全く意識していないというのは危険かも」というちょっとコワい話をこれからします。
でも安心してください。実績のある対応方法がありますので、そちらについても紹介します。
1. はじめに
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
「OSSのライセンスって何？」という人は、流石にこの文章を読まれる方の中にはいないと思います。（実は、、、、という方は、このシリーズの他の文章にきっと書いてあると思いますので、そちらを読んでからまた戻ってきてください。）
「いや、『まったく意識していない』という訳ではない。以前世間で騒ぎになった頃、気になって関連のセミナーを受講したら『サーバでOSSを動かす分には、そのライセンスは気にしなくて良いです』と講師から言われた」とかでしょうか。この文章を読まれる方の中ではここに当てはまる方が一番多いのではないかと思っています。その講師の言ったことは嘘ではないのですが、残念ながら厳密に言うと正しくありません。きっと、限られた時間の中で「まずは基本を押さえてもらおう」と意図的にややこしい話は外したのでしょう 。
「いや、私の聴いたセミナーでは講師はAGPLについて触れていたぞ」という方、それは厳密さを優先する講師に当たったのですね。ただし、他のライセンスの話と比べて、AGPLの話はかなり短かったのではないでしょうか （もしかしたら、本当にAGPLの名前だけ、なんてことも、、、）。「それなりにAGPLついても話してくれたよ」という方も、最近の動向も含めて書いていこうと思いますので、最後までお付き合いいただければと思います。
2. GPLとAGPL
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
こんな話を聞いたことはないでしょうか。「例えば、グーグルは検索などのサービスを実現するために、数多くのサーバでLinuxを動作させているはずだ。LinuxのライセンスはGPLだが、グーグルがそのコードを開示しているという話は聞かない。だが、これはライセンス違反ではない。なぜなら提供しているのはあくまでサービスであって、Linuxの動作しているサーバを配っているわけではないからだ。」この考え方は間違いではありません。皆さんも、例えばWebサーバを構築するときに、そのOSにLinuxを使うことは多いと思います。その場合も上と同じ考え方が適用できて、皆さんがLinuxのライセンス順守に頭を悩ます必要はないです。
ただ、ライセンス上は問題ないとしても、このような使い方を「OSSへのタダ乗りではないか」と快く思わない考え方もあります。（特にサーバの数がものすごく多いとなればなおさらです。）そこで、GPLのこの「欠陥を修正」した新しいライセンスが作られました。それがAGPLです（※１）。（ここで「何！？LinuxでWebサーバを構築するとLinuxのコード開示が必要になるのか！？」とは早とちりしないでください。LinuxのライセンスがGPLからAGPLに変わったわけではありません。）興味のある方は、是非ご自分の手でGPLとAGPLのライセンス文を比較してみてください。名前のところで差分が出てくるのは当然ですが、それを除くと差はほとんどありません。一ヶ所だけ差があるのですが、それがまさに「GPLの欠陥を修正」した部分です。
※１：本文中ではできるだけ簡単な言葉を使って説明しようとしていますが、検索などのために専門用語を知っておきたいという方もいるかもしれませんから、そんな方のために。「GPLにはASPループホール（アプリケーションサービスプロバイダの抜け穴）があって、それを塞いだのがAGPLだ」というのがより専門的な言い方かと思います。
3. AGPLのOSS
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
いきなりですが、ここで質問です。ライセンスがAGPLのOSSって見たことありますか。
「この文章を読みながら、ブラウザーで検索したら、それなりの数が見つかったよ」が答でしょうか。今はそういう時代のような気もしますが、ここで私が聞きたかったのは「何らかの形でAGPLのOSSと関わったことがあるか」です。「でも、もう検索してしまったし、、、」というのであれば、お付き合いしましょう。検索結果のかなり上の方にGhostScriptというOSSが出てきているのではないでしょうか。印刷に関係するOSSですが、その機能を自社のソフトウェア製品に組み込みたいと言うのであれば、GPLだと思ってライセンスを順守すればいいです（先程GPLとAGPLにはほとんど差がないと言いましたよね）。ソフトウェア製品ではなく印刷に関連するサービスを提供する場合には、AGPL固有の部分を気にしないといけません。が、印刷といえばPDF全盛で、PDF化なら手元のパソコンでもできるこのご時世に、そういうサービスをあえて用意しようという方もいないのではないかと思います。（「そもそも印刷なんてしない」というのがもしかして今風でしょうか。）
で、話を戻して私の質問に戻りますと、「いいえ」の答の方が圧倒的に多いのではないかと思います。実を言うと、私もAGPLのOSSを扱ったことは数えるほどしかありません。（私も業務でOSSを扱って長いのですが、、、）セミナーでAGPLに一切触れなかった講師は、こういう現状を踏まえていたのかもしれませんね。
4. 最近の動向
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
「そもそもAGPLは比較的最近になってできたラインセンスだし、AGPLのOSSはほとんどない」という考えで以前は問題ありませんでした。私もAGPLと言われて思い出すのは、ガラケーに特殊なサービスを提供するサーバ側のプログラムくらいです。今なら「スマホにウェブ経由でサービスを提供」ということになるのでしょうが、当時は通信会社各社がそのあたりの仕様を完全に握っていましたので、サービスを提供すること自体にものすごい壁がありました。（少なくとも私個人が道楽で何かできるようなものではありませんでした。）なので、「へえ、こんなプログラムがあって、こんなライセンスなんだ、、、」以上の感想は当時はありませんでした。あ、こんなことを書くと年齢がバレますね。
ですが、最近少し状況が変わってきました。皆さん、NoSQLという言葉を聞いたことがあるのではないでしょうか。ここでSQLは「結果を問い合わせるのにSQLを使うデータベース」という意味で使われているようですが、そういったデータベースはデータをきっちり扱います。（※2）一方、NoSQLはNoとあることから分かるように、SQLのデータベースとは異なりデータをきっちりとは扱いません。多少いい加減に扱います。その代わりSQLのデータベースと比べると処理速度は圧倒的に速いです。 （※3）
現在はデータが大量に生み出される時代ですから（「ビッグデータ」なんて言葉もありますよね）、大量のデータを多少いい加減でも良いから迅速に扱いたいという要求も多いわけです。なので、NoSQLのOSSがよく使われるようになりました。そうなるとクラウド側でもいちいちユーザがインストールしなくても良いように最初からNoSQLが用意されているようなサービスを用意するようになります。で、そのNoSQLの中にライセンスがAGPLのものがありました。
「AGPLなのだからクラウド側でソースコードを開示したのだろう」と思われるかもしれませんが、実際はそうなりませんでした。AGPLの条件は厳密には「サーバで改変したプログラムを動かした場合」となっていまして、クラウド側ではNoSQLそのものを改変することはせず、NoSQLを便利に使う補助プログラム群を追加したという形で使っていたのです。
これは確かにライセンス違反ではないかもしれません。が、見方によっては「新しい形のOSSへのタダ乗り」とも言えるわけで、GPLからAGPLを作ったように、「AGPLの『欠陥』を『修正』しよう」ということになりました。その結果できたライセンスがSSPLです。この流れを作ったのはMongoDBというNoSQLですが、もちろんMongoDBが唯一のNoSQLというわけではありません。当然他にもNoSQLはあって、その他のNoSQLもその流れに乗りました。ただ、すべてのNoSQLがライセンスをAGPLからSSPLに切り替えた、という単純な話ではなく、独自に「AGPLの『欠陥』を『修正』した」ライセンスが一時は雨後の筍状態になりました 。
最近は流石に落ち着いて来て「雨後の筍」ではなくなりましたが、そうは言っても中にはしっかり竹として育ったものもあります。ですので、「サーバで気にしなければいけないライセンスはAGPLだけ」「AGPL（とその類似のライセンス）のOSSはほとんどない」と言っていられた牧歌的な時代はとうに過ぎ去ったことがご理解頂けるかと思います。
※2：例えば、銀行口座間での振込とかをイメージしてもらうと分かりやすいでしょう。振り込んだはずのものが途中で消えてしまったら大問題ですよね。
※3：MMORPGでラスボスに一斉攻撃をして倒す場合とかを考えると良いでしょう。みんなの攻撃でラスボスが倒せたかどうかだけが大事な場合、NoSQLだとそういった処理が素直に書けるのですが、SQLのデータベースだと「誰がどんな順番で攻撃したか」まで律儀に処理しようとしますので、その処理のせいで、もしゲームがもっさりしてしまったら興ざめですよね。
5. 対策
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
さて、ここまで長々とちょっとコワい話を書いてきましたが、それに対して対策がないわけではありません。実は、組み込みの業界では20年近く前からこの問題に取り組んできています。
組み込みというのは文字通り製品にOSSを「組み込んで」販売するのですから、「サーバでOSSを動かす分には、そのライセンスは気にしなくて良いです」作戦は使えません。ですので、AGPLに限らずOSSすべてのライセンスを気にしなければなりませんでした。ソフトウェアの規模がそれほど大きくないうちは、（社内の）有識者によるレビューなど、人手で何とかできたかもしれません。が、「組み込み」とは言っても、その当時からすでにソフトウェアの規模が大きくなりつつあること（※4）が課題になっていましたので、かなり早い段階で「人手で何とかする」というのは諦めざるをえませんでした。そこで、ツールの出番です。ツールで自分の製品のソフトウェアの中にどのようなOSSが入っているか、そしてそのライセンスはどういうものかを確認するようになりました。
これをそのままアプリケーションサービス提供事業者の皆さんの側でも取り入れてもらえば、問題解決です。「ライセンス順守が大事なのは分かるけど、うちはその前にセキュリティだな」「え？セキュリティとは別にツールを買わないといけないの？」と思った皆さん、安心してください。組み込み業界で取り組み始めた当時は、「ライセンス順守の機能が主。セキュリティのチェックについてはオプションで付けられるかも」な感じでしたが、今では例えばFossIDのようにライセンス順守の機能とセキュリティのチェックの機能の両方が（オプションでなく最初から）あるものが多いです。
※4：携帯電話の高機能化を思い浮かべて頂けると、納得できるかと。
※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。
Tips集のご案内
テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。
「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。
1.「OSS最新動向-コロナに負けないオープンソース」
2.「オープンソースSBOMが必要な理由とは！」
3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
4.「OSSと上手に付き合う方法～攻めは最大の防御なり～」
5.「OSSと上手に付き合う方法～サプライチェーンを安全に～」
6.「ISO/IEC 5230で変わる？OSSコンプライアンス対策」
7.「著作権トロールとは？」
