はじめに
みなさんが開発する製品やサービスでは、どの程度の数の OSS が同梱されたり、動いているでしょうか？200でしょうか？500でしょうか？1,000以上でしょうか？
一般的に、Linuxディストリビューションを使用していれば、最低でも100以上、アプリケーション側でも Web フロントエンドで 100以上、バックエンドで100以上…ということもあるでしょう。
このような大量のOSSを効率よく扱う上で重要な概念がパッケージです。パッケージは、ソフトウェアを流通の単位でまとめたものです。多くの場合、ライセンス情報を含むメタデータを持ちます。さらに、パッケージをダウンロード、インストール、構成管理、依存関係を管理するためのツール（パッケージマネージャー）が提供されていることが多いです。
OSSを使用する上で特に大切なことはライセンスの確認でしょう。理想的には、パッケージマネージャーでインストールしたパッケージを列挙して、パッケージのメタデータのライセンス情報を使用し、これらの OSS が利用可能かを判断できると、個々のOSSのドキュメントやソースコードを確認するよりも効率よく確認できます。
さらに、ライセンス情報は、SPDX License Expression という標準的な記法で記載されることが一般的です。例えば、Apache License, Version 2.0 であれば Apache-2.0、GNU General Public License v2.0 の場合は GPL-2.0-only などです。また、Apache-2.0 と GPL-2.0-only のデュアルライセンスの場合は、Apache-2.0 OR GPL-2.0-only のように記載します。OSS では多くの場合、限られた中からライセンスを選択するため、SPDX License Expression を使用することで、ライセンスファイルの内容を毎回確認することなく、容易にどのライセンスが適用されているかを知ることができます。
世の中にはたくさんのパッケージの種類がありますが、今日はアドベントカレンダーの投稿ですので、内容を絞って Linux ディストリビューションのパッケージを例に書きたいと思います。
パッケージとアップストリームのライセンスが違う？
パッケージの単位でライセンスを確認できるとよいと書きましたが、うまくいく場合もあれば、うまくいかない場合もあります。
実際にパッケージのライセンス情報を確認していると、パッケージされる前のオリジナルのソースコード（アップストリーム）のライセンス情報と、パッケージのライセンス情報が異なることに気づくことがあります。そのような場合に、どちらが正しいか悩んでしまったことはないでしょうか？
すべてではありませんが、次のようなケースがあります。
ケース1: パッケージ作成者がライセンス情報を補完した
これは、良い事例です。パッケージ作成者が、アップストリームのソースコードにライセンス情報が不足していると判断し、パッケージのメタデータにライセンス情報を追加した場合です。例えば、とある OSS プロジェクトで、ライセンスが Apache-2.0 であると LICENSE ファイルに記載されていたものの、ソースコードの一部に LGPL-2.1-or-later のファイルが1つ含まれていました。このような場合に、パッケージの作成者が、パッケージのライセンス情報を Apache-2.0 AND LGPL-2.1-or-later (AND は両方の条件を満たす必要がある) のように補完し、パッケージの利用者に正しいライセンス情報を提供することがあります。
このようなライセンスが異なるファイルの混入は、OSS の利用者がソフトウェア構成解析ツールなどで調査することもあるかと思いますが、この作業をパッケージ作成者が代行し、結果を共有してくれたと考えることもできます。
ケース2: パッケージ化する際に、パッケージ作成者がライセンスの異なるコードを追加した
パッケージはアップストリームのコードをそのまま流通させるだけではなく、不具合の修正や、特定の環境向けの調整などを行うことがあります。このとき、パッケージ作成者がコードを追加・変更することがあります。
稀ではありますが、この追加・変更されたコードにアップストリームコードとは異なるライセンスが適用されている場合があります。この場合、アップストリームのソースコードのライセンスとパッケージのライセンスが異なることになります。
具体例を見てみましょう。AlmaLinux 8 (Red Hat Enterprise Linux、以下 RHEL も同様) の少し古い openssl パッケージです。ライセンスは OpenSSL ライセンスです。このパッケージのライセンス情報には OpenSSL and ASL 2.0 と記載されています。（ASL 2.0 と記載されていますが、Apache-2.0 と同じ意味です。これは AlmaLinux 8 と RHEL 8 は SPDX License Expression を正式に採用していないためです。）
なぜ OpenSSL AND Apache-2.0 なのでしょうか？実は、このパッケージには新しい OpenSSL のコードがパッチとして取り込まれています。そして、現在の OpenSSL のライセンスは Apache-2.0 となっており、取り込んだコードには OpenSSL ではなく、Apache-2.0ライセンスが適用されているため、このようなライセンス情報になっています。
余談ではありますが、このようなケースがあるため、OSS をパッケージとして使用する場合は、アップストリームのソースコードのライセンス情報だけではなく、パッケージのライセンス情報を確認することを忘れないようにしてください。
ケース3: パッケージ作成者が意図せず異なるライセンスを設定してしまった
これは、例から見てみましょう。最近、よく使われる圧縮アルゴリズムに zstd があります。zstd のライセンスは BSD-3-Clause OR GPL-2.0-only のデュアルライセンスです。どちらかのライセンスを選んで使用することができます。では、AlmaLinux 8 (繰り返しますが、RHEL 8 も同じです) の zstd パッケージのライセンス情報を見てみると BSD and GPLv2 と記載されています。
より新しいバージョンの Fedora 43 の zstd にも BSD-3-Clause AND GPL-2.0-only と記載されています。
この AND と OR の違いは非常に大きいです。BSD-3-Clause AND GPL-2.0-only をどう捉えるかについては、後述の議論の余地がありますが、このパッケージに含まれている /usr/lib64/libzstd.so.1.5.7 のライセンスが BSD-3-Clause AND GPL-2.0-only であるとすると、libzstd にリンクするアプリケーションは、ソースコードの提供を含む GPL-2.0-only が定める条件を満たして配布する必要があります。GPL-3.0-only など、互換性のないライセンスの OSS からもリンクができません。zstd のような基本ライブラリに適用されるライセンスとしては少しおかしいです。
では、これは間違いなのでしょうか？あるいは、ケース2のようにパッケージ作成者が意図して、アップストリームとは異なるライセンスを指定したのでしょうか？答えはパッケージの作成者に確認するしかありません。
実際に確認してみた結果がこちらです。特に AND にする意図はなかったようで、次の Fedora の zstd パッケージでは BSD-3-Clause OR GPL-2.0-only に修正されることになりそうです。
過去には、アップストリームのドキュメント内に紛らわしい記述もあったため、このような結果になった可能性もあります。
パッケージのライセンス情報の信頼性を高めるには？
パッケージのライセンス情報は正しい場合も、間違っている場合もあることを説明しました。怪しい場合はパッケージ作成者に確認するしかないのですが、利用者がより妥当性の確認をできるようにし、安心して利用できるようにするには、どうすれば良いでしょうか？
1つ目はパッケージ作成者が意図的にライセンスを変更する場合は、その理由等を含めて明確に宣言することです。また、理由なしにライセンスを変更しないことをポリシーとして宣言することも大切でしょう。ケース2の openssl の例では、パッケージ情報だけでは分かりませんが、パッケージのソースコードでは明確に宣言されていました。
これを行うには、ライセンス情報を表明する単位を細かくすることも重要です。今回、例として取り上げたパッケージは RPM 形式で、RPM ではパッケージ全体に対してライセンス情報を記載します。そのため、意図して異なるライセンスのファイル（例えば、パッチファイル、追加コード）を取り込み、そのライセンスを表明したくても、RPM の標準的な方法で表明することができません。
個々のファイルに対して、ライセンスを表明する方法としては次のような方法があります。
- Debian パッケージの debian/copyright ファイル
- SPDX や CycloneDX などの SBOM 文書フォーマットでファイルにライセンス情報を付与する
- REUSE Specification の reuse.toml ファイルを使用する
ソースコードに対しては、ライセンス情報を細かく表明することを実践しているプロジェクトもありますが、バイナリパッケージに対する詳細なライセンス情報の付与については、まだまだ課題があると感じます。
余談になってしまいますが、細かくライセンス情報を表明することで、SPDX License Expression の AND の取り扱いの曖昧さの解決にもつながります。パッケージに A AND B というライセンス情報が付与されていて、内部に F と G という2つのファイルが含まれているとき、F と G の片方、あるいは両方に A AND B というライセンスが適用されているのか、F と G にそれぞれ A と B のライセンスが適用されているのか、判断できない場合があります。ファイルごとにライセンス情報が付与されていれば、このような曖昧さは解消されます。
おわりに
OSS を活用するためには、パッケージと、パッケージのライセンス情報を活用することは非常に重要ですが、一方で、ライセンス情報がより正しい場合も、誤っている場合もあることを説明しました。
みなさんはどうしますか？パッケージ情報は信頼できないとして、パッケージのソースコードからソフトウェア構成解析ツールを駆使して、正しいライセンスを調査しますか？
このようなライセンス調査をそれぞれが毎回やるのは効率が悪いので、OSS のコミュニティ全体で協力して、パッケージにより詳細で正しいライセンス情報を付与したり、そのもとになるアップストリームのコードにも詳細なライセンス情報を付与していくことが大切ではないかと思います。