最近バズっていた記事を読んでソフトウェアライセンスについて考える

こんにちは、下條です。昨日のAWS東京リージョンの障害では、Multi-AZのRDSが影響を受け、ちょっとヒヤヒヤものでした ^^;

さて、先日このようなブログ記事がバズっていたようです。
趣味で作ったソフトウェアが海外企業に買われるまでの話

個人で開発したOSSが企業に買われ、開発者自身もその企業に雇われる。夢のある話だなーと思って読んでいたのですが、買収されたソフトウェアがTrivyというコンテナ脆弱性スキャンツールだと知って驚きました。

というのも，弊社では脆弱性スキャンツールのVulsというソフトウェアを利用しており、Vulsではここで紹介されているTrivyというツールが使われているので、弊社で利用しているツールだったからです。

といいながらも、私はこれまでTrivyのコードはほとんど読んだことがなかったので、これを機会にちょっと読んでみることにしました。まずはREADMEからと思って読んでいたのですが、ひとつ気づいたのがライセンスがAGPL (Affero General Public License) であることです。このライセンスを紹介つつつ、買収したAqua Security社にとってのこの買収の意味をちょっと考えてみることにしました。

まずは、AGPLというライセンスについて簡単に説明しておきます。基本としてAGPLはGPLの考え方をベースとしています。GPLの説明はいろいろなところに書かれているので省きますが、GPLにはコピーレフトという重要な考え方があります。

コピーレフトの考えでは、著作権者はそのコピー（複製物）の受取人に対して撤回の出来ないライセンスを認め、販売を含む再配布を許可し、翻案（改変）されることも可能とする必要がある。逆に、コピーレフトを利用する側では、このライセンスのものをコピーや変更、再配布する時にはこのライセンスをそのまま適用し、それを明確に示さなければならない。

https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%94%E3%83%BC%E3%83%AC%E3%83%95%E3%83%88　より。

例えば、GPLのソフトウェアを組み込んだり、ライブラリをリンクしたりしたソフトウェアを配布する場合は、そのソフトウェアのライセンスもGPLにする必要があるということです。

私は前職で商用のインストール型ソフトウェアを開発していましたので、GPLについては気をつける必要がありました。というのもその商用ソフトウェアにGPLのソフトウェアを入れ込んだり、ライブラリをリンクした場合、ソースコード全体を開示する必要が出てくるためです。商用ソフトウェアの開発ベンダーの立場としては基本的にはそれは受け入れられないことであり、GPLのソフトウェアは取り込んではいけないものとして扱われていました。 (GPLの良し悪しの話ではありません。あくまで商用ベンダーとしての立場・方針の話です。)

しかしGPLが考えられた頃から時代は変わりました。現在はソフトウェアはネットワークを介して利用されることが増えました。あえて単純な表現をすれば、インターネットを介してサーバ側のサービス (ソフトウェア) を利用する形態が急激に増えてきました。その際、サービス提供者であるASP側がGPLのソフトウェアを組み込んでいたとしても、ASP側はソフトウェアを配布しているわけではないので、GPLとする必要はなく、ソースコードを公開する必要はないのです。ただし、これはフリーソフトウェアの考えには反します。ある意味抜け穴となっていたとも言えます。

そういった背景を踏まえ考えられたライセンスがAGPLです。AGPLはGPLをベースとしていますが、ネットワーク経由での利用についての条項が加えられていることが特徴です。

The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.`

https://www.gnu.org/licenses/agpl-3.0.en.html より引用。

これは、ASPがAGPLのソフトウェアを組み込んだ場合、サービスの利用者にソースコードを公開しなければいけないということを意味します。

それでは最初の、TrivyがAGPLであるという話に戻ります。これを踏まえると少し買収の意味が見えてくるのではないでしょうか。

もしTrivyを利用しているASP型サービス (コンテナ脆弱性チェックサービスのようなものでしょうか。) がある場合、そのサービスのソースコードを利用者に公開する必要が発生するということになります。

Trivyが個人の持ち物であった場合は、仮にライセンス違反をしていても訴訟のリスクはほぼないですので、ライセンス違反の状態でも実質問題はなかったかもしれません。訴訟リスクがないからといってライセンス違反していいという話ではありませんが。しかし、Trivyが買収された現在では現実問題として訴訟リスクが発生してきます。

要するにこの買収は、Trivyを利用しているASP型サービス (おそらくAqua Security社の競合) への大きな牽制となる他、今後コンテナ脆弱性チェックのようなASP型サービスを作ろうとする場合、Trivyを非常に使いずらくなるということを意味します。そういう意味では、汚い言葉で言えば競合つぶしの側面を強く感じる買収ではあります。

もちろん、買収時にライセンスがAGPLでなかったとしても、買収後にAGPLに変更することは自由です。したがって、ライセンスはあくまで付随的な話であり、素晴らしいソフトウェア・開発者の方だったから買収されたということには変わりないことを補足しておきます。

と書いてきましたが、今回本当に言いたい話は別にあります。

自戒も込めて、

「Webサービスを開発している皆さん、ライセンスについて意識していますか？」

ということです。今どきのWebサービス開発ではOSSのライブラリを多数バンドルすることが多いと思います。それぞれのライセンスについて把握していますか？

Webサービスのソフトウェア開発においては、非コピーレフト型ライセンスはもちろん、GPLなどのコピーレフト型ライセンスの多くは自由に利用できてしまいます。あくまで個人的な印象ですが、そういった背景や、MITライセンスのような比較的ゆるいライセンスが増えているせいか、Webサービスの開発者の方には比較的ライセンスについて比較的無頓着な方が多い印象を受けています。ただ、今回強調したAGPLライセンスはWebサービスを開発している人にダイレクトに影響するものです。

ライセンスについて意識・尊重するということは、そのソフトウェアや開発者を尊重するということです。もしこれまでライセンスについて意識してこなかったという方がいらっしゃったら、本記事によりこれから意識していただくきっかけとなれば幸いです。

内容には誤りないよう注意を払ったつもりですが、もし間違いがあったらTwitterなどでご指摘いただければ幸いです。

shimo