GitHubを利用する際に注意したいOSSライセンスのポイントとは

手軽にできるOSSライセンスチェック

ここからは読者の方が手軽に実施できるOSSライセンスのチェックの方法をご説明します。

ソースコードの場合

これまで説明してきましたようにOSSには必ず著作権者が記述されています。通常、ソースコード一番上のヘッダ部分には、著作権者とライセンスが記述されています。この部分を抽出することにより、OSSのライセンスを特定することができます。これはとても簡単で「Copyright」というキーワードでgrep（文字列検索）するだけです。ライセンスには必ずCopyrightの記述があるという性質を利用しています。

著作権者は通常「Copyright 年号 著作権者」という書式で記述されます。読者もしくは読者が属する企業名以外が著作権者として検出されれば、そのソースコードは第三者の著作物です。「Copyright」以外には「license」というキーワードも有効です。ライセンスを特定したら、これまでの連載でご説明したどのライセンスに該当するかをチェックしながら、ライセンス文を精読して利用条件を確認してください。

このように手元にソースコードがあれば上記のような方法で特定できますが、もっと早い段階、つまり利用するOSSをダウンロードした際にそのOSSのライセンスをチェックしておくこともできます。OSSのパッケージをダウンロードしますとLICENSE、COPYING、COPYRIGHT、READMEといったファイルがOSSのトップディレクトリに格納されています。

図3：gettext-0.18.3.1の例

これらのファイルにはそのOSSに適用されたライセンスが記述されています。ソフトウェアにOSSを組み込む際にライセンスをチェックしておくと、出荷前に慌ててチェックする必要がありませんし、いち早くポリシーに合わないOSSを検出することもできます。またこうしてチェックしておいたライセンステキストを保持しておくと、ソフトウェアのリリース時にも添付する際にも利用できます。

ソースコードの場合と書きましたが、上記の「Copyright」というキーワードでのgrepは、.exeや.dllといったバイナリファイルに対しても有効です。ソースコードほどの情報はありませんが、バイナリファイルにも著作権者が埋め込まれていることがあるためです。
筆者が従事している検査サービスの統計では、grepだけで検出できるOSSは、そのソフトウェアに含まれているOSSの80%程度です。さらに正確に特定しようとすると、OSSのデータを保持し、それとマッチングを行うような専門のツールが必要になります。オープンソースとして公開されているFossologyと、商用ソフトウェアのPalamida、Protecode、Protexなどが有名です。

jarのライセンスチェック

Android アプリ開発やWebシステムの開発ではJava言語が利用されています。このような開発ではjar（Javaのライブラリ）が必然的に利用されることになります。次にjarのライセンスをチェックする方法をご説明します。

jarはzipファイルと同様に展開することができます。中にパッケージがツリー構造で格納されておりその中にはclassファイルが含まれていますが、それとは別に必ずMETA-INFというディレクトリも含まれています。この中にはLICENSEというファイル格納されていることがあります。これはそのjarのライセンスを示すものですので、これによりjarのライセンスを特定することができます。

エンベロープOSS

OSSはライセンス条件を順守すれば複製再頒布が可能です。これは商用ソフトウェアに限った場合だけではなく、OSSでも同様です。特に規模の大きいOSSの場合は、既存の別のOSSを流用していることが多く、ライセンスは一枚岩ではないと認識しておくべきです。このようなOSSは、OSSの中に別のライセンスのOSSがある状態を指して「エンベロープ（封筒）OSS」と呼ばれることがあります。

JBossの例を見てみましょう。JBossのライセンスはLGPL v2.1として知られていますが、そのサブプロジェクトはLGPL v2.1ではないものも多数含まれています。

OSSのソースコードがまるごと流用されているケースもありますが、ファイルの形式がjarの場合はこれが顕著になります。OSSのツリー構造の中に「external」や「3rdparty」といったディレクトリがあれば、その下に格納されているjarは、まず別のライセンスと考えた方が良いでしょう。そのOSSから見てexternal（外部）ないし3rdparty（第三者）であるためです。

もっとも、このように外部のjarと分かるようにディレクトリを配置してくれているOSSは親切な方で、外部のjarもそのOSSオリジナルのjarも同じlibディレクトリに格納されているケースもあります。いずれにしてもjarは一つ一つライセンスが異なる可能性が高いですので、慎重に調査する必要があります。

ライセンスの両立性

ライセンスをチェックした結果、複数のOSSライセンスを利用していたことが判明したとします。その複数のOSSライセンスは両立できるものでしょうか。求める条件が別のライセンスに抵触したりはしないでしょうか。

両立しない例として最も有名なのが、BSD 4-Clause License とGPL v2です。BSD 4-Clause License は前回の連載でご説明したとおり「宣伝条項」を持ちます。一方、GPL v2にはGPL v2の条件以上のことを求めてはいけない、という条件があります。この2つの条件は相容れず、一方の条件を順守するともう片方の条件を順守できません。

「さまざまなライセンスとそれらについての解説」に、GPLと両立するライセンス、両立しないライセンスの一覧があります。複数のOSSライセンスが検出された場合には、ライセンス同士が両立するかについても考慮する必要があります。

OSSライセンステキストの添付方法

ソフトウェアを再頒布する際には、ライセンステキストを添付しなければなりません。OSSのライセンスはそのトップディレクトリに置かれていることが多いと先ほど説明しました。これと同様に読者の皆さんがソフトウェアを再頒布する際にも、ソフトウェアを受け取った人がすぐに分かるようにトップディレクトリにライセンステキストを配置しておくことをお薦めします。複数のライセンステキストを添付する場合には、パッケージの直下に「licenses」といったディレクトリを作成し、その中に利用しているOSSのライセンステキストすべてを格納することができます。

ソフトウェアの形式によっては、ソフトウェア自体にライセンステキストを格納することが不可能、もしくはライセンステキストを格納しても利用者がそのライセンステキストを参照する手段がない、ということもあります。その場合にはソフトウェアの取扱説明書の最後にライセンスをまとめて記述するという方法が採られます。この取扱説明書にはオンラインマニュアルも含みます。

最近ではスマートフォンアプリなど、取扱説明書もないというソフトウェアが増えてきています。その場合にはソフトウェアの中で表示するという方法が採られています。例えばアプリケーションを起動し「設定」→「一般」→「著作権情報」や、「Help」→「About」などのように操作すると、そのアプリケーションで利用しているOSSのライセンスがすべて参照できます。この方法は、アプリケーションとOSSライセンス表記の同期が取りやすいという利点があります。アプリケーションをバージョンアップした際に利用しているOSSに変更があった場合でも、OSSライセンス表記の情報もそれと同期を取って配信できるためです。取扱説明書のような紙媒体の場合ですとこのような方法を採ることが難しいです。

スマートフォンをお持ちの読者の方は、ご利用になっているアプリケーションの著作権情報（Third Party Copyright Noticesとも呼ばれます）をチェックされてはいかがでしょうか。「こんなライセンスのOSSを使っていたのか」とOSSライセンスをより身近に感じて頂けると思います。

ここまで3回にわたって「今日から始めるOSSライセンス講座」を連載させていただきました。OSSライセンスについて開発者の方が最低限知っておくべきことはご説明できたと考えています。特にこの最終回では手軽に始められるライセンスチェックの方法と、ライセンステキストの添付方法をご説明しました。読者の皆さんのソフトウェアでお試し頂けますと幸いです。