Githubによる、オープンソースライセンスの選び方

※「オープンソース・ライセンスの談話室」から移動したページです。

「オープンソースライセンスは、分かりにくい。」
まだまだ、このように感じているソフトウェア開発者が多いようです。
たしかに、オープンソースライセンスをお手軽に解説した記事は、かなり人気があります。

ソースコード共有サービスとして人気のGithubの利用者にとっても、これは例外ではないようです。

Githubでは、オープンソースプロジェクトには無償でレポジトリを提供していますが、「GitHub 上で公開されているソースコードの半分はライセンス的に問題あり」と指摘されていました。公開リポジトリの多くに、ライセンス文が設定されていなかったのです。ライセンスが設定されていないソースコードは、著作権者の明示的な許可が得られていないので、自由に複製・配布・改変できません。

そこで、ここでは、2013年7月にGithubが設置したライセンス選択サイト「Choosing an OSS license doesn’t need to be scary」(OSSのライセンス選択は、怖くない。以下、同サイト)について解説します。

Githubは使ってないけど、オープンソースライセンスの概略を知りたい人にも、役立つかも知れません。

とりあえず、オススメの3つ

同サイトでは、はじめに、「あなたの状況に、いちばんよく当てはまるのは、次のうちどれですか？」とたずねています。そこで、次の3つの中から、自分のシチュエーションにぴったりなパターンを選びます。

  • 単純で寛容な条件にしたい(I want it simple and permissive.)
  • 特許のことを心配している(I’m concerned about patents.)
  • 改善の共有に配慮したい(I care about sharing improvements.)

license_best3

たくさんの選択肢があると、人間は不自由を感じてしまうと言われています。たしかに、せいぜい3つくらいから選ぶのが、ちょうどいいですよね。

同サイトでは、この3つのパターンについて、手ごろなオープンソースライセンスと代表的な適用例を下記のように紹介しています。

  • 単純で甘い条件にしたい(I want it simple and permissive.)
    MITライセンス(日本語参考訳)は、短くポイントを押さえた、寛容なライセンスです。あなた(作者)の名前を示し、作者に一切の責任を求めない限り、好きなように扱うことを許します。
    jQuery と Rails はMITライセンスを採用しています。
  • 特許のことを心配している(I’m concerned about patents.)
    Apache v2ライセンス(日本語参考訳)は、MITライセンスに似た寛容なライセンスですが、貢献者(作者)から利用者への特許権の許可を明確にします(図解：Apache License2.0の特許条項)。
    Apache HTTPサーバ、 Subversion 、 NuGet はApacheライセンスを使用しています。
  • 改善の共有に配慮したい(I care about sharing improvements.)
    GPL(バージョン2：日本語参考訳またはバージョン3：日本語参考訳)は、あなたの作品またはその派生物(改造された作品)の配布に、必ず利用可能なソースコードと同一条件(GPLでの配布)を要求する「コピーレフトライセンス」です。バージョン3はバージョン2に似ていますが、ソフトウェアの改変を禁止するハードウェアでの利用に制限があります。
    Linux、 Git、そして WordPress はGPLを採用しています。

いずれも実績の多い特徴的なライセンスなので、この中から選ぶのは妥当な選択だと思います。

残りのライセンスパターン

同サイトのトップページの下のほうには「もしもピッタリのがなかったら? あるいは、他の権利を保持したかったら」として、残りの代表的なライセンスの特徴を解説しています。

オープンソースライセンスは、さきほどの3つ以外にもたくさんあります。このページでは、「必須事項」「許可されること」「禁止事項」という3つの特徴で、ライセンスを整理しています。

これについては、下記で日本語訳が公開されています。

もっといろいろなライセンスの中から選びたいという人は、こちらを読んでみましょう。

ライセンスを明示しないと(No Licesne)

さらに、同サイトのトップページには、もうひとつリンクがあります。「もしも、ライセンスを選ばないなら?」として、「ライセンスを明示しないと、どうなるのか」についても説明しています。リンク先の「No Licesne」ページでは、次のように説明しています。

ライセンスを選ぶことは、義務ではありません。あなたは、コードやプロジェクトでライセンスを選ばない権利を持っています。しかし、オープンソースライセンスの選択を見合わせても、著作権法を見合わせることにならない点は、覚えておいてください。

あなた独自のプロジェクトに関しては顧問弁護士に相談する必要がありますが、一般的には、ライセンスを明示しないと、既定の著作権法が適用されます。

この場合、あなたはソースコードに対するすべての権利を保有することになり、第三者によるソースコードの複製・再配布・改変は許可されません。これは、あなたの意図したこととは、違っている可能性があります。

明示的なライセンスファイルなしで、Githubのパブリックリポジトリで公開する場合、あなたは、Githubの利用条件に同意して、他のGithubユーザーにいくつかの権利を与えていることになります。この場合、あなたのレポジトリは閲覧されたり分岐されたりするでしょう。

あなたのソースコードを他の人と共有したいなら、ぜひ、オープンソースライセンスの選択について熟考しましょう。

というように、オープンソースにするつもりがないにも関わらず、Githubの公開リポジトリを利用している人に、注意を促しています。

これに加えて、もうひとつの考え方もあると思います。ソースコードを自由に利用しても構わないけれど、ライセンス文を設定するのが面倒だという場合です。たしかに、Githubで公開すれば、そこの利用条件に従うことになるので、ライセンスを適用しなくても、みんな自由に使ってくれるかも知れません。

でも、ライセンスがなにも明示されていないと、自由に使ってほしいのか、自由に使ってほしくないのでライセンスを適用していないのか、どちらなのか区別が付きません。それに、そのソースコードが複製・配布流用した先では、ライセンス文がなければ、利用条件は分かりません。

というわけで、Githubでソースコードを公開するとき、自由に利用してほしいなら、ぜひオープンソースライセンスを明示しましょう。

Githubでのライセンス選択

さて、現在のGithubでは、新しいレポジトリーを作るときに公開レポジトリ(Public)を選択すると、Githubで無視させるファイル(gitignore)とライセンスを選択できるようになっています。

そして、「Initialize this repository with a README」のチェックボックスをオンにしておくと、選択したライセンスに合わせて、ライセンス文書ファイルを自動的に配置してくれます。

license_best3

これは便利ですね。

これでも、まだライセンスを選ぶのが面倒ならば、MITライセンス一択でいいんじゃないでしょうか。そして、素直な形で適用する。MITライセンスのライセンス文書をLICENCE.txtというファイル名で同梱し、各ソースコードファイルの先頭に、「このファイルは、MITライセンスを適用する!」と書く。とりあえず、そんだけです。

追記

「自作ソースコードに、MITライセンスを適用する３つのやり方」を公開しました(2013-09-27)。

以上、ライセンス選択サイト「Choosing an OSS license doesn’t need to be scary」(OSSのライセンス選択は、怖くない)について解説しました。

Githubのおかげで、ソースコードの公開と共有がとても手軽になりました。ライセンスの選択と設定についても、これを機会に手軽に取り組むといいかもしれませんね。

参考リンク

備考

-----