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のライセンスについては常に注意を払っておく必要があります。