伊藤真彦です、最近はバックエンド6割フロントエンド3割、ヘルプの更新など細かいもの1割くらいで働いています。
2022年5月17日のアップデートでOSSライセンスの表示機能をリリースしました。

OSSライセンス表示機能とは

ソフトウェア開発においてなんらかのOSSライブラリを利用することは珍しくありません。
OSSにはその利用におけるライセンス規約を明示する文化があります。それらを利用するにあたり、ライセンス条項に違反しないよう気をつける必要があります。

脆弱性とは若干方向性が異なるのですが、サーバーにインストールされたソフトウェアの情報を収集する以上、その脆弱性のついでにOSSライセンスの情報を調査できると嬉しい、という事になります。
私自身、Vulsチームに移籍する前のチームで開発しているアプリケーションがライセンス違反を起こしていないか調査するよう求められたことがあります。

Future Vulsでは、サーバにインストールされたソフトウェアの詳細を確認できます。
ここにOSSライセンスを表示する機能を追加しました。

OSSライセンスの情報収集は以下の手法でスキャンしたものを対象に行われます。

そもそもOSSライセンスとは

OSSライブラリにはその利用におけるライセンス規約を明示する文化があると書きました。
例えばGitHubで新しいリポジトリを作成する際、ライセンス条項を選択します。

GitHubでは執筆時点で下記のライセンスを選択できます、かなり沢山ありますね。

Apache License 2.0
GNU General Public License v3.0
MIT License
BSD 2-Clause “Simplified” License
BSD 3-Clause “New” or “Revised” License
Boost Software License 1.0
Creative Commons Zero v1.0 Universal
Eclipse Public License 2.0
GNU Affero General Public License v3.0
GNU General Public License v2.0
GNU Lesser General Public License v2.1
Mozilla Public License 2.0
The Unlicense

OSSライブラリを作成する際はこれらのうちどれかを選択します。
複数のうちどれかを選ぶ権利を提供もできれば、オリジナルの条件を設けることもできます。
GitHubでこれを選択してリポジトリを作成すると、選択したライセンスの条文が記載されたLICENSEというファイルが生成された状態で、リポジトリを新規作成できます。

このように多くの選択肢がありますが、多くはApache License 2.0、またはMITライセンスを選ぶ傾向があります。
詳しくはGitHUbのヘルプ及び、choosealicense.comをご確認ください。

例えばMITライセンスにはソフトウェアの使用、修正、配布を明示的に許可する条文、および損害賠償に関する免責事項が記載されています。
利用者に何かを強制するだけでなく、安心して利用してもらう、また開発者やOSSコミュニティを守るという意味でもライセンス条文を選択する意味があります。

ライセンス違反とは

様々なOSSライセンスがあることはわかりましたが、これに違反するとはどういうことでしょうか。

例えばApache License 2.0を適用したライブラリを利用する場合、ユーザーにApache License 2.0を適用したソフトウェアが利用されている事を伝える必要があります。
このようなライセンス条項への対応を忘れるケースが想定されます。

ユーザーに通知する手段は自由で、ソースコードを公開している場合はライブラリを利用している旨をソースコードのコメントや、READMEなどで記載できます。
ソースコードを公開していない場合は、ソフトウェアのインストーラとライセンス条文を同梱して配布するといった手法をとることもできます。
ゲームソフトのスタッフロールにOSSについての条文が記載された例もあります。

特に注意が必要なライセンス

数あるライセンスの中でも、気をつける必要があるものはGNU GPLライセンスです。
GNUプロジェクトの理念は、ソフトウェアの利用者に自由と権利を提供することです。
具体的には、ソフトウェアを利用する権利とともに、ソフトウェアのリバースエンジニアリング、改良版の公開といった権利も許可します。
更に、GNUライセンスを適用したライブラリを利用した場合は、利用したソフトウェアも同じライセンスを適用しなければならない、コピーレフトと呼ばれる性質があります。
この性質は商用のプロジェクトでソースコードを公開できないプロジェクトで利用する場合は、実質的に利用できないと言える大きな制約になります。

GNUライセンスには、コピーレフトの適用条件などが調整されたいくつかのバージョンがあります。

AGPL系: ネットワークを介したソフトウェアサービスの提供でも、ライセンス条項の適用を要求する
GPL系: ソフトウェアを頒布する場合は、ライセンス条項の適用を要求する。

FutureVulsではAGPL, GPLのライセンスが含まれる場合赤文字で表示する、ヘルプページへのリンクを表示するといった工夫をしています。

また、CSIRTプランでFutureVulsをご利用いただく場合、全てのサーバーを横断的に検索可能です。

是非新機能をご活用いただければ幸いです。

参考: mimemagicの事例

GPLライセンスによりコミュニティに大きなインパクトを与えたのがmimemagicのライセンス更新です。
これはmimemagicが依存しているライブラリ、shared-mime-infoがGPLライセンスであるため、mimemagicもGPLライセンスで頒布するなど対応を行うべき、というものです。
対応の一環として、今までMITライセンスで公開していたmimemagicの頒布を停止する必要がありました。

このmimemagicを利用したライブラリに、WEB開発フレームワークの定番であるRuby on Railsがあったことで影響を受ける開発者の規模は非常に大きなものとなります。
古いmimemagicが公開停止になった影響で、依存バージョンを更新したRuby on Railsでなければビルドできなくなってしまいます。
事情を把握していない人にとってはある日突然Railsアプリケーションのビルド(bundle install)が落ちるような挙動となりました。

また、コピーレフトの影響でmimemagicがGPLライセンスであるからにはRuby on RailsもGPLライセンスになり、Ruby on Railsで作ったアプリケーションもGPLライセンスになるのか、といったルール面での検討から見た課題もありました。
対応自体は正しいものであり、またビルドが通るよう改修された緊急リリースが速やかに行われましたが、ともかくRuby on Railsコミュニティにとっては大きなニュースとなりました。

ライセンスのルールは見落としやすく、場合によっては難しい対応が必要になったり、大きな影響を及ぼす事になります。
日々開発しているソフトウェアがライセンス規約に則った形で開発、公開できているか確認することの重要性がmimemagicのケースからご理解いただけると思います。

どのようにライセンス情報を収集するのか

ここからは開発苦労話です。
利用しているライブラリのライセンス情報を確認するツールは github/licensed、google/go-licensesなどが既に開発されています。
これらのツールは、ツールを実行するマシンの中に確認対象が実際に存在する前提で作られています。
FutureVulsではこの前提が大きな制約となります。
世界中の全てのソフトウェアをインストールしたサーバーを作るわけにはいかないので、インストールされていないソフトウェアのライセンス情報を収集する機能を開発する必要がありました。
そこでvulsio/licensecheckを開発、公開しました。

このツールは、実行環境のファイルツリーの代わりに、https://pkg.go.dev/など、各言語ごとのディストリビューションからライセンス情報を確認します。
このような仕組みであれば、例えば別のチームから提供されたpackage-lock.jsonを監査するようなユースケースでも簡単に利用できます。
ライセンスはMITライセンスで公開しています、Goのライブラリとしてインポートする他、CLIツールとして利用できるようにもなっています。
日々の業務で活用いただければ幸いです。
スキャン処理の所要時間に大きく影響するため、OSS Vulsにそのまま組み込むことは避けましたが、オプション機能としての提供、または各ツールを組み合わせて利用できる機能を開発することも検討しています。

まとめ

Future VulsでOSSライセンス情報の確認ができるようになりました。
GNU GPLライセンスの取り扱いを特に気をつけるよう開発しています。
ライセンスのチェック機能はOSSとして公開しました

OSSライセンス表示機能を開発しました