オープンソフトウェアライセンスについてまとめてみた

ライセンス

2012年のものですが、興味深い記事を見つけました。
GitHub needs to take open source seriously | InfoWorld
GitHubに存在する全プロジェクトのうち、半数はライセンスの定義がなされていない、ということです。

このことがどういった問題を引き起こすのか。記事には次のように書かれています。

You don't have to include a copyright statement for your creative work to be under copyright. In any country that's a signatory to the Berne Convention, copyright -- or stronger -- is the default as soon as something is created.

拙訳:コピーライト保護下に置くために、あなたの創造的な作品に対して、コピーライト宣言を含めるような必要はありません。ベルヌ条約の加盟国であるどんな国においても、コピーライト(あるいはそれより強力なもの)が、何かが創造された瞬間にそれに付与されるためです。

GitHub does not include any useful default licensing terms in its terms of service; the most likely scenario is that any use of the copyrighted material in one of those no-license projects is formally a breach of copyright.

拙訳:GitHubはterms of serviceに何らかの有用なライセンスの付与について、初期状態(訳者注:プロジェクトにライセンスの明記がない状態)での条件を記していません:最も起こりそうなシナリオは、そうしたライセンスのないプロジェクトのうちのコピーライトで保護されたものを使うことは、明確にコピーライト違反にあたる、というものです。

まとめると、次のようになります。

  • 制作物は全て創造された瞬間にコピーライトが付与される。
  • GitHub上にはライセンスのないプロジェクトが多くあったが、それらの扱いを決めていない。
  • そのため、ライセンスのないプロジェクトは、自動的にコピーライトが付与される。
  • したがって、たとえパブリックに公開されていても、それらのコードを使うことはコピーライト違反にあたる。


さて、初めに書いたように、この記事は2012年に書かれたものです。2015年、今のGitHubでは、ライセンスのないプロジェクトの扱いはどうなっているのでしょうか。探してみました。

まず、No License - Choose a Licenseでは、どのライセンスを選ぶかどうか、あるいはライセンスをプロジェクトに含めるかどうかは、ユーザーの自由であるとしながらも、ライセンスのないプロジェクトにはコピーライトが付与され、法律によって守られる、としています。つまり、そういったプロジェクトを他のユーザーは閲覧、フォークはできますが、複製、再配布、二次的な制作物の作成をすることはできません。

たとえ他のユーザーに向けてプロジェクトを公開しても、様々に利用することが違反なら、それはプログラマーと彼らのプロジェクトが集うGitHubにとっては皮肉なことです。そこでGitHubはオープンソフトウェアライセンスの使用をすすめています。

Choosing an open source license doesn’t need to be scary - Choose a License
上記のページでは、次の3つの主なオープンソフトウェアライセンスを紹介しています。

MIT License

「シンプルで寛容的がいい」
MITライセンスは短く要点に絞った寛容なライセンスです。作者に帰属し、また、作者に責任を求めない限り、自由にコードを扱うことができます。

使い方

プロジェクトのルートにファイル(基本的にはLICENSEかLICENSE.txt)を作り、そこにライセンスのテクストをコピーします。現在の西暦とコピーライト保持者のフルネームが必要です。

必要なこと
  • ライセンスとコピーライトの表記
許可されること
  • 商用利用
  • 再配布
  • 改変
  • 私用利用(再配布することなしにソフトウェアを修正し、使用できます)
  • 再許諾(ソフトウェアを修正し、配布するために第三者にサブライセンスを付与できます)
禁止されること
  • 責任の追求(ソフトウェアは保証無しに提供されます。ソフトウェア作成者、ライセンス保持者は損害に対して責任を負いません)

Apache License

「特許はどうなってます?」
ApacheライセンスはMITライセンスによく似た寛容的なライセンスですが、作者からユーザーに対し、特許の使用許可を明記しています。

使い方

プロジェクトのルートにファイル(基本的にはLICENSEかLICENSE.txt)を作り、そこにライセンスのテクストをコピーします。

Note:The Apache Foundationはそれぞれのソースファイルのヘッダに、ボイラープレートの表記を加えることを推奨しています。(ボイラープレートは割愛します)

必要なこと
  • ライセンスとコピーライトの表記
  • 変更点
許可されること
  • 商用利用
  • 再配布
  • 改変
  • 特許の使用
  • 私用利用
  • 再許諾
禁止されること
  • 責任の追求
  • 商標の使用

GPL

「改良の共有を大事にします」
GPLは作成者のコードや二次制作物の配布に際し、そのソースを同じ条件下で利用可能にすることを要求する、コピーレフトライセンスです。

使い方

プロジェクトのルートにファイル(基本的にはLICENSEかLICENSE.txt)を作り、そこにライセンスのテクストをコピーします。

Note:Free Software Foundationははそれぞれのソースファイルのヘッダに、ボイラープレートの表記を加えることを推奨しています。(ボイラープレートは割愛します)

必要なこと
  • ソースの開示
  • ライセンスとコピーライトの表記
  • 変更点
許可されること
  • 商用利用
  • 再配布
  • 改変
  • 特許の使用
  • 私用利用
禁止されること
  • 責任の追求

No license

使い方

シンプルに何も表記しません。コピーライトの表記は推奨されていますが。

必要なこと

ライセンスやコピーライトの表記

許可されること
  • 商用利用
  • 私用利用
禁止されること
  • 再配布
  • 改変
  • 再許諾

ライセンスの付与

上で紹介したような方法の他に、GitHubでは新しくリポジトリを作る際、ライセンスを選ぶだけですごく簡単にライセンスをプロジェクトに付与することができます。

f:id:uraway:20151211013439p:plain
既存のリポジトリで、create a new fileから新しくLICENSEファイルを作ることでも簡単に付与できます。 f:id:uraway:20151211021642p:plain

まとめ

あなたが他の人の参画を狙ってプロジェクトをパブリックに公開しても、No licenseではコピーライトに守られているため、それができません。
そんなことが起きないように、ちゃんと正しくライセンスを表記しておきましょう。