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

GitHubに見るOSSライセンスの最新動向

現在、最も利用されているOSSホスティングサイトといえばGitHubです。

図1：GitHubの画面とマスコットのOctocat

つい先日となる、 2013年12月23日のGitHubのblogでは、リポジトリの数が1,000万を超えたとされています。またリンク先のグラフを見るとリポジトリ数の増え方の伸びが著しく、今後も登録数の増加が予想されます。

1,000万という数字はあまりに大きいのですが、他のホスティングサイトと比較してみるとどのくらいの規模なのかが分かります。少し前まで世界最大といわれていたSourceForge.jpは、本稿執筆時点（2014年2月）で約20万プロジェクトです。これを見てもGitHubのプロジェクト数が飛び抜けていることがよく分かります。

これほどメジャーなホスティングサイトとなったGitHubですが、課題もあり、これまで2つの問題が指摘されていました。

1つ目の問題は、既存のOSSのクローンが容易に作成できるため、どのサイトがOSSのオリジナルのサイトなのかが分かりにくくなることです。ソフトウェアの検査を実施していますと、同じOSSのプロジェクトがGitHub上とそれ以外のサイトに存在することも少なくありません。
ただ、これは単にオリジナルが分かりにくくなるというだけです。複製・再配布はOSSライセンスで許諾されている行為ですのでライセンス上は問題ありません。

もう1つの問題はより深刻で、OSSライセンスが登録されていないリポジトリが非常に多いということです。この問題は海外のカンファレンスでは2012年の初頭で既に報告されていました。
私が最初にこの問題を知ったのは、2012年のOSBC（Open Source Business Conference）です。あるセッションではこの問題について「ライセンスのないコードがGitHubに登録され増殖するのは、OSSのムーブメントに対する脅威だ」といった趣旨の発言がありました。それに対して議論がヒートアップしたことを覚えています。

それと同様の議論をこのブログで現在でも見ることができます。これによれば、GitHubに登録されているリポジトリの50%は、ライセンスや著作権の情報が簡単には分からないという状態です。ソースコードを参照すればなんとかライセンスが判明するものが30%。ライセンスがきちんと提示されており、利用条件が明白なものはわずか20%ということです。
先に述べたようにGitHubには非常に多くのリポジトリがあるため、その半分がライセンス不明ということは、利用条件が不明なソースコードが大量に公開されているということになります。

それでは、このようなライセンスが不明なソースコードは利用することができるのでしょうか。

GitHubではNo Licenseのページで次のように説明しています。

「OSSライセンスが設定されていないソースコードには著作権法が適用され、著作権者がすべての権利を留保します。」

つまり、このソフトウェアを使用（実行・ソースコードの閲読・コンパイル）することはできますが、利用（複製・再配布・二次著作物の作成）することができないのです。これはリポジトリを作成してソースコードを公開した著作権者側、そして利用者側両方にとって不幸な出来事です。誰かに利用されることを意図して公開したソースコードが、その意図とは外れて誰にも利用されない、利用することができない状態になっているからです。

この問題に対して、GitHubでのリポジトリ作成時にOSSライセンスを選択・登録させるフローを設けるべきだという意見がありました。それにGitHub側が対応したのが2013年7月で、次の2つのサイトが用意されました。

「Add A License」と「Choosing an OSS license doesn’t need to be scary」です。

図2：ライセンス選択を促す2つのサイト（クリックで拡大）

OSSライセンスが登録されていない既存のリポジトリについては「Add A License」でライセンスの登録を促し、新たにリポジトリを作る場合には「Choosing an OSS license doesn’t need to be scary」でOSSライセンスを選択することは恐れることはない、としています。

「Choosing an OSS license doesn’t need to be scary」の方では、どのライセンスを選んでよいか分からない初心者のために以下の3つの選択肢を用意しています。

• I want simple and permissive.（シンプルで寛容な条件がいい）→ MIT Liense
• I'm concerned about patents.（特許について心配している）→ Apache License
• I care about sharing improvements.（改善を共有することを大切にしたい）→GPL

このような誘導があれば、OSSライセンスをよく知らない人でもそのプロジェクトに適したOSSライセンスを選択できます。利用者に条件をあまり課したくない人にはMIT License。特許について心配しているならApache License。改善を共有したい、すなわち前回の記事で説明したコピーレフトの思想を持つならGPL、と自分の思想にあったライセンスを選択できるようになっています。

GitHubのこの対策により、リポジトリにOSSライセンスが適用され、著作権者にとっても利用者にとっても良い方向に進むのではないかと筆者は期待しています。

AGPL の適用

もう一つ、OSSライセンスの気になる動向はAGPLライセンスの適用です。前回では、AGPLはGPLがカバーできない範囲を補うために2007年に作成されたライセンスであるという説明をしました。

2013年は、このAGPLがOSSプロジェクトに適用されたというニュースをいくつか目にしました。特に、Berkeley DBのライセンスがSleepycat LicenseからAGPLに変更されたということは日本でも話題になりました。

現在、AGPLが適用された有名なOSSとしてはmongo DBやiTextが挙げられます。Berkeley DBも含めたこれら3つのプロジェクトに共通するのは、いずれもAGPLと商用ライセンスのデュアルライセンスであるという点です。Berkley DBがAGPLにライセンスを変更した際には、米国の開発者サイトで「コピーレフト性の強いライセンスを適用して商用ライセンスを利用させる戦略ではないか」というような意見もありました。真の意図は明らかではありませんが、今後の動向については注視しておく必要があります。

また、同様にAGPLが適用されたプロジェクトが増えることも予想されます。利用している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ライセンスについて開発者の方が最低限知っておくべきことはご説明できたと考えています。特にこの最終回では手軽に始められるライセンスチェックの方法と、ライセンステキストの添付方法をご説明しました。読者の皆さんのソフトウェアでお試し頂けますと幸いです。