ライセンスをつけないとどうなるの？

GitHub上でプログラムを公開するとき、

• どのライセンスを使えばいいのかわからない
• どうやってライセンスを設定すればいいのかわからない
• ライセンスというもの自体が難しそうでよくわからない

などの理由で、ライセンスを設定しないままになっていることはないでしょうか？

この記事では、個人の開発者によるプログラムにライセンスが設定されていなかった場合にどのようなことが起きるのか、という観点からスタートして、ライセンスについての理解を深めていこうと思います。¹

---

• 注意1: この記事の執筆者は法律に関する専門家ではありません。法律やライセンスに関する言及や解釈は不正確である可能性があります。実際の問題に対しては専門家による助言を受けてください。
• 注意2: この記事の内容は執筆者個人の見解であり、所属企業・部門の見解を代表するものではありません。

---

ライセンスがないということ

プログラムのソースコードは、そのコードを書いた人の著作物にあたる²ため、著作権法による保護の対象となります。
そのため、ライセンスが定められていないプログラムは、その著作者から明示的に許可を受けない限り、ソースコードを複製したり、再頒布したり、手を加えたりすることができません。

ライセンスの定められていないプログラムを無断で再頒布したり手を加えたりすることは、一般にそのプログラムの著作権の侵害にあたるので、本来の著作者からの申し立てによって削除されたり、訴訟の対象になるリスクが生じます。
そのように法律に違反した状態・いつ削除されるかわからない状態では、とてもそのプログラムの開発に参加しようとは思えませんから、ライセンスによってソースコードの修正等が許可されていなければ、コミュニティによる活発なソフトウェアの開発は実現できないでしょう。

ですから、自分の著作物に誰もがアクセスできるようにするためには、ライセンスを設定し、プログラムを自由にコピーしたり改変したりしてよいということを明確に宣言する必要があるのです。

ところで、冒頭で「著作者から明示的に許可を受けない限り」と断りを入れたことに気付かれた方もいるかもしれません。
つまり、作者に許可をとった上であれば、そのプログラムを修正したりしてもかまわないということになります。
また、あなたがそのプログラムの作者だった場合、よほどのことがなければ訴訟なんてしないから、プログラムのバグを修正してくれるのは歓迎だ、と思うかもしれません。

ですが、実際にはすぐに問題が生じてしまいます。

たとえば、Aliceさんが作ったプログラムに、Bobさんが許可を得てバグ修正の変更を加えたとします。
修正後のプログラムのソースコードには、もとの作者であるAliceさんが書いた部分と、修正のためにBobさんが書いた部分が混在しているので、このプログラムはAliceさんの著作物であると同時にBobさんの著作物でもある、ということになります。
ここに第三者がさらに修正を加えようとした場合には、AliceさんとBobさんの双方からの許可を得なければなりません。
しかも、もともとの作者であるAliceさんすら、Bobさんの許可なしにはこのプログラムを変更することができなくなります。
開発に関わった人がさらに増えていった場合には、その全員から許可を得る必要があるということなので、合法的に開発を進めていくことは現実的ではなくなってしまうでしょう。

No license in GitHub

もし明確にライセンスが設定されていなかったとしても、たとえばGitHubのパブリックリポジトリで公開されているプログラムは、誰でもソースコードを見ることができるわけですから、「オープンソース」だといえるのではないでしょうか？

実際にはそうではありません。

GitHub上でソースコードを公開するとき、明示的にライセンスが設定されていないのであれば、それは依然として**「ライセンスなし」の状態のまま**です。
ただし、そのプログラムを公開したユーザーはGitHubの利用規約に同意しているはずですから、その中に含まれる「他のユーザーへの許可」の条項が適用されます。

By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license.

日本語に翻訳されたGitHub利用規約では、この部分は次のように訳されています。

リポジトリを公に表示するように設定することにより、お客様は、他者がリポジトリを表示および「フォーク」できるようになることに同意するものとします (これは、他者が管理するリポジトリ内のお客様のリポジトリから他者が「コンテンツ」の独自の複製を作成できることを意味します)。

お客様が自身のページおよびリポジトリを公に表示するように設定した場合、お客様は GitHub の「サービス」を通じて「あなたのコンテンツ」を使用、表示、および実演し、また GitHub の機能を通じて許可される限りにおいて (フォークなど) のみ GitHub 上で「あなたのコンテンツ」を複製する、非独占的かつ世界的ライセンスを GitHub の各「ユーザ」に付与します。 お客様がライセンスを採用した場合、他の権利を付与することができます。

つまり、パブリックリポジトリに公開されたプログラムは、他のGitHubユーザーが閲覧・フォークすることができるようになっています。
ここで注意するべきなのは、

GitHub の機能を通じて許可される限りにおいて (フォークなど) のみ GitHub 上で「あなたのコンテンツ」を複製する

権利のみが他ユーザーに付与され、「GitHub上以外での複製」や「改変」に関する許可は行われない点です。
文字通りに解釈すると、ライセンスのないリポジトリをフォークすることはできても、そのリポジトリをgit cloneコマンドなどで自分のマシンにダウンロードしたり、修正を加えてプルリクエストを送ったりすることは(GitHubの利用規約上では)一切許可されていないということになります。³

これでは、GitHub上にプログラムが公開されていたとしても、ただソースコードが読めるというだけでソフトウェアに組み込んだりすることもできず、実質的にはほとんど何にも利用できませんね。

余談：オープンソースとは

ところで、ソースコードが公開されていて読めるようになっている、というだけではオープンソースと言えないのであれば、どのような条件を満たしていればオープンソースと呼ぶことができるのでしょうか。

「オープンソース」の定義は、Open Source Initiativeという団体のThe Open Source Definitionによって定められています。
ここでは、自由な再頒布やソースコードへのアクセス、ソフトウェアを変更したものを同じライセンスで頒布できること、誰もが平等に権利を与えられることなど、10の項目をすべて満たしているものが「オープンソース」であるとされます。

利用者が誰でも入手や再頒布・変更を行えるようにすることでソフトウェアをより良いものにしていく、という考えがオープンソースソフトウェア(OSS)の基本的な理念で、この考えを実現できるようなライセンスのことをオープンソースライセンスと呼ぶのです。

ライセンスのないコードの公開によって起きる弊害 (Ruby 1.9.2の例)

ライセンスなしで公開されたソースコードは、時にソースコードを公開しないことよりも悪い結果をもたらしてしまうことがあります。

Ruby 1.9.2のリリースに含まれた、ある脆弱性対応の例を紹介します。
とある脆弱性に対するパッチがRubyの開発者メーリングリストruby-devに公開されたものの、そのパッチのライセンスが明示されていなかったためRubyに取り込むことができなくなった、という話です。

ライセンスがないパッチは、前述のように著作権法による完全な保護を受けた状態ですから、このコードを組み込むとRubyのライセンスに矛盾が生じてしまいます。
さらに問題となるのは、リンク先の記事に書かれているように

• ruby-devを読んだ人はライセンス上安全なパッチを書けない

という点です。
ライセンスされていないパッチが使えない以上新しくパッチを書き起こす必要があるのですが、著作権上完全にオリジナルなパッチを作るためには、もとのパッチを目にしたことがない人の手で実装が行われなければなりません。
一度でも著作権で保護されたパッチを見た(または、その可能性がある)場合、新しいパッチがそれを模倣したものであるという可能性を排除できないためです。
この例では、結果としてruby-devを読んでいない開発者の手によって改めてパッチが作成されています。⁴

ライセンスが明示されていないのは、どんなライセンスよりも厳しいライセンスだ。

アバンダンウェア

インターネット上でハンドルネームを使って活動している人は、現実の人間よりも急に音信不通になりがちですね。
SNSの更新が停止したりメールアドレスが不通になるなど、わずかな接点が途絶えるだけで永遠に連絡がとれなくなったりします。
1990年代後半や2000年代ごろに個人で開発されていたフリーウェア⁵などは、開発者がWebサイトの更新を停止するなどしてサポートが行われなくなり、連絡をとることもできなくなっている例が多くあります。

このようにして著作者との連絡がとれなくなったり、著作権を持っていた企業が倒産するなどして、誰が権利を持っているのかわからなくなった状態のソフトウェアをアバンダンウェアといいます。
アバンダンウェアになったからといって著作権が消滅するというようなことはなく、一般には権利の所在が不明な著作物として、公表から70年が経過して著作権が消滅するのを待つしかありません。
このような状態では「著作者の許可」を得ることは実質的に不可能ですから、適切にライセンスが設定されていなければソースコードへのアクセスは大幅に制限されることになります。

当時のフリーウェアがアバンダンウェアになったとしても依然として利用を続けることはできますが、ソースコードが公開されていない場合や、ソースコードが入手可能になっていてもライセンスの整備が十分でない場合が大半です。
そのようなソフトウェアにセキュリティ上の脆弱性が発見されるなどして修正が必要になったとしても、もとの開発者との連絡がつかない状況では誰も権利的に安全な方法で修正を加えることができません。
そのため、アバンダンウェアは時間の経過とともに利用すら危険な状態になっていくこともあります。
また、他の開発者がそのソフトウェアの開発を引き継ぐといったこともできないため、それまでに蓄積されたソースコードは二度と活用されず、同等のソフトウェアが欲しい場合にはまた新しく作り直さなければなりません。

非常に厄介な例として、ソフトウェアの開発自体は継続していても、過去にライセンスが設定されないまま開発者の引き継ぎが行われ、かつ当初の開発者との連絡がとれなくなっているというようなパターンもあります。
このような場合、現在の開発者が改めてライセンスを設定したいと思ったとしても、プログラム中に含まれる元の開発者のコードの著作権を侵害せずに第三者による再頒布・改変を認めることは不可能ですから、いずれアバンダンウェアとしての道を辿ることは避けられません(このような例に対する法的な救済が可能になればいいのですが……)。

もし適切に設定されたライセンスによってプログラムの再頒布や改変が認められていた場合であれば、当初の開発者が活動を停止しても他の開発者が開発を続けることができ、さらにその次の開発者へとソフトウェアを引き継いでいくことができますし、仮に開発が停止されてメンテナンスが放棄されたソフトウェアであっても、誰かがそれを見つけて復活させることもできます。

ライセンスをつけよう

わたしたちが作ったプログラムにライセンスを整備することにはさまざまなメリットがありますが、アバンダンウェアのような観点から見た場合、適切なライセンスをつけることはソフトウェアの未来を閉ざさないための行為であるといえるでしょう。

近年のGitHubなどの普及のおかげで、ソースコードが公開されたソフトウェアの数は大きく増加したのではないかと思います。
一方で、2015年の時点の情報では、GitHub上のプロジェクトのうち、20%前後にしかライセンスが設定されていないといわれています。
ライセンスが適切に設定されたソフトウェアを増やしていくためには、わたしたち一人ひとりがライセンスのないソフトウェアの問題についてしっかり認識することが重要ですね。

GitHubでライセンスファイルを追加する

では、実際にソフトウェアにライセンスを設定するにはどうすればよいのでしょうか。
GitHubを利用しているプロジェクトであれば、非常に簡単にライセンスを適用させることができます。

新しく作成するリポジトリにライセンスを設定する

GitHub上で新しいリポジトリを作成する際は、"Initialize this repository with:" の中の "Choose a license" にチェックを入れ、使用したいライセンスを選択すると、LICENSEという名前のファイルが含まれた状態でリポジトリが作られます。
これだけでプロジェクト全体にライセンスが適用された状態になるため、他には何もする必要はありません。⁶

既存のリポジトリにライセンスを設定する

既に存在するリポジトリの場合は、まず "Add file" から "Create new file" を選択してファイルの新規作成ページに移動します。

ファイル名の入力を求められるので、LICENSEと入力すると、右側に "Choose a license template" というボタンが出現します。

ライセンスを選択し、必要な項目を入力して(基本的にはデフォルトの状態で問題ありません)、 "Review and submit" ボタンを押すと、LICENSE ファイルの中身が自動的に生成されます。

そのまま "Commit new file" ボタンを押すことで、LICENSEファイルを追加することができます。

どのようなライセンスを選べばいいのか？

さまざまなライセンスのうちから何を採用するかというのは、非常に大切な選択になります。
ですが、あまり恐れる必要はありません。

この記事ではそれぞれのライセンスについて詳細に解説するかわりに、ライセンスを選ぶ際のヒントを提示することにします。

また、英語版しかありませんが、GitHubが開設したWebサイトである https://choosealicense.com/ はライセンスを選択する助けになるかもしれません。

関連するソフトウェアと同じライセンスを使おう

あなたのソフトウェアが他のソフトウェアに関連したものである場合、それと同じライセンスを使うことが望ましいことが多いです。⁷
たとえば、Reactに関連するライブラリを開発した場合は、React本体に採用されているMITライセンスを選ぶのが良いのではないでしょうか。

有名なライセンスを使おう

あなたの開発したソフトウェアに非常に特別な事情がないかぎり、広く使われている有名なライセンス、特に

• MIT License
• GNU GPL v3
• Apache License 2.0

の3つの中から適したライセンスを見つけられるはずです。⁸

大規模なソフトウェアでは、たくさんのライブラリを利用することなどによって、ソフトウェアが複数のライセンスの組み合わせによって構成されていることがあります。
このとき、別々のライセンスはそれぞれ違った文面・条件を持っていることがあるので、それらのライセンスを同時に組み合わせてもよいのかどうかを考える必要があります。
ライブラリごとにそれぞれ独自のライセンスが設定されていると、確認の作業が大変になったり、条件が相反するので特定のライセンスと組み合わせることができないといった事態が発生しやすくなります。
これを「ライセンスの氾濫」といい、かつて問題となったことがありました。⁹
ライセンスの種類を有名なものに絞ることで、ライセンスの管理が簡単になる、同時に利用できないソフトウェアの組み合わせが減るというメリットがあります。¹⁰¹¹

余談の余談：コピーレフトと自由ソフトウェアについて

¹²
オープンソースという語に似た文脈で、フリーソフトウェア(Free Software, 自由ソフトウェア)という言葉を聞いたことがあるかもしれません。
ここでの "Free" は、「無料」ではなく「自由」という意味で、この誤解を避けるために日本語では自由ソフトウェアという名前が使われています。

ほぼ全てのオープンソースソフトウェアは自由ソフトウェアで、ほぼ全ての自由ソフトウェアはオープンソースソフトウェアなので、実際のソフトウェアに関して、この二つの語は基本的に同じものを指しています。
ですが、この二つの語を使用する立場には明確な違いがあります。
前述のように、オープンソースの理念とは「利用者が誰でも入手や再頒布・変更を行えるようにすることでソフトウェアをより良いものにしていく」ことでした。
一方で自由ソフトウェアの理念とは、「誰もがソフトウェアを入手・再頒布・変更できるという自由」を重視し、この自由を守ることを指します。
このような自由が保障されたソフトウェアがなければ、企業が悪意をもってユーザーの情報を盗もうとしたり、ソースコードが公開されていないプログラムにマルウェアが仕込まれるようなことがあった場合に、ユーザーは自らの身を守ることができないという考え方です。

「自由ソフトウェア」と「オープンソース」は異なる考えですが、ほとんどの人がソフトウェアを見る方法において、同一の概念のスロットで競争します。人々が「オープンソース」と言って考えるのが慣習となれば、自由ソフトウェア運動の理念を把握し、それについて考える障害となるでしょう。

(https://www.gnu.org/philosophy/open-source-misses-the-point.html)

これまで10年以上、フリーソフトウェアファウンデーションは、この「オープンソース」による自由ソフトウェア運動の特徴付けに異を唱えてきました。自由ソフトウェアの擁護者は、主に、この枠に対して議論しています。なぜなら、「オープンソース」は、わたしたちの中心的なメッセージである自由を抑制し、わたしたちが作り上げたソフトウェアの成功におけるわたしたちの運動の役割を覆い隠そうとする、明白な活動だからです。わたしたちは、「オープンソース」は基本的に悪い、と言ってきました。なぜなら、人々がソフトウェアの自由について語ることから遠ざけるようにする、からです。

(https://www.gnu.org/philosophy/when-free-software-isnt-practically-superior.html)

と書かれているように、オープンソースと自由ソフトウェアは時に対立する概念であり、オープンソースという言葉を使うことには、裏に「自由ソフトウェアという言葉を使わない」という主張が含まれます。
この意味において、「オープンソース」という語は政治的に中立なものではありません。 ¹³

オープンソースと自由ソフトウェアという相異なる立場に対して、中立な立場としての言及を行いたい場合には、 OSSや自由ソフトウェアという言葉のかわりに、"FLOSS" ("Free/Libre and Open Source Software") という用語を使用します。¹⁴¹⁵

自由ソフトウェアの立場からはGPLライセンス(とその派生ライセンス)のみを使用することが推奨されていますが、その最大の特徴が「コピーレフト」として知られている性質です。
コピーレフトではないFLOSSライセンスが適用されたソフトウェアは、それをもとにしてオープンソースソフトウェアでも自由ソフトウェアでもない、再頒布や改変などに制限を設けたソフトウェアを作ることができます(このようなソフトウェアを、プロプライエタリなソフトウェアといいます)。
あるソフトウェアのバージョン1.00がコピーレフトではないFLOSSライセンスのもとで頒布されていたとして、バージョン1.01では利用者にソースコードの入手や改変・再頒布を許可しないライセンスが適用されることもあり得るのです。
もちろんこのような場合でも、バージョン1.00をもとにして依然とFLOSSライセンスのもとで開発を続行していくことができますが、FLOSSバージョンとプロプライエタリバージョンの2つにソフトウェアの開発が分裂してしまうことでしょう。
コピーレフトの性質とは、コピーレフトであるライセンスが適用されたソフトウェアは、そこから派生して作られたソフトウェアも全てコピーレフトでなければならない、というものです。
これによって、一度コピーレフトが設定されたソフトウェアは将来に渡ってコピーレフトに、ひいては自由ソフトウェアに保たれます。

おわりに

本記事では、ライセンスをつけずに公開されたプログラムがどのような問題を発生させてしまうのかという点を中心に、GitHubを利用した簡単なライセンスの設定方法やライセンスの選び方のヒント、FLOSSライセンスに対する観点などを紹介しました。

ライセンスについて適切に考え、判断を下すことは決して簡単な問題ではありませんが、ライセンスの設定されていないプログラムはわたしたちにとって悲しい結果を招いてしまうことがあります。
アバンダンウェアのような例を生じさせないためにも、わたしたち一人ひとりがライセンスについて考える機会を持つことは大切なことだと思います。
そのためにこの記事が参考になれば幸いです。

1. ソフトウェアライセンスは当然企業が保有するソフトウェアにとっても非常に重要なものですが、本記事ではとくに個人・コミュニティによって開発されるソフトウェアにフォーカスしていくことをご了承ください。 ↩

2. 業務で作成したプログラムの場合は、特に規定がなければその雇い主である法人に権利が帰属します。 https://monolith-law.jp/corporate/copyright-for-the-program-source-code ↩

3. 利用規約に明示的に書かれていないということは著作権など関連する権利に関する法律にそのまま従うということであり、ただちに著作権の侵害などにあたるというわけではありません。たとえば私的使用の範囲内での複製など、定められた条件の下では著作物を自由に使用することができます。 https://www.cric.or.jp/qa/hajime/hajime7.html (@oskbt さんに指摘していただきました。ありがとうございます。) ↩

4. もとのプログラムの情報を一切持たない人間に新しく実装を行わせる手法をクリーンルーム設計やチャイニーズウォールテクニックといい、主に他社製品をリバースエンジニアリングしてクローンを作る際に使われます。 ↩

5. 「自由ソフトウェア」(Free Software)ではない ↩

6. ただし、そのままではリポジトリに含まれているソースコード以外のファイルにも指定したライセンスが適用されることになります。たとえば、リポジトリの中にドキュメントファイルが含まれている場合には、ドキュメント全体にもライセンスが適用されても問題がないか確認したほうがよいかもしれません (https://choosealicense.com/non-software/) 。例として、GPLが適用されるソフトウェアのドキュメントにはGNU FDL 1.3を使用することが推奨されています。 ↩

7. https://choosealicense.com/community/ ↩

8. MITライセンスに類似したライセンスとして、実質的に同等のISCライセンスや2条項BSDライセンス、少し条件が追加された3条項BSDライセンス(修正BSDライセンス)などが使われることがあります。また、GPLのかわりにLGPLかAGPLが使われることもあります。 ↩

9. https://ja.wikipedia.org/wiki/ライセンスの氾濫 https://opensource.org/proliferation ↩

10. ここで挙げたメジャーなライセンスは(GPLのもとでしか頒布できなくなるという点に目を瞑れば)すべて同時に組み合わせることができます。 ↩

11. 上節の「関連するソフトウェアと同じライセンスを使おう」も、関連するソフトウェア群で統一されたライセンスを使用することで同一のメリットを得るねらいがあります。 ↩

12. この記事で扱っているような話題について語るとき、コピーレフトの背景にある考え方について触れずに済ませることは、ソフトウェアの開発に携わる人間としてまっとうな態度であるとは言えないでしょう。そのためにこの章が存在します。 ↩

13. https://opensource.org/faq#free-software > Sometimes people mistakenly assume that users of the term "open source" do not intend to communicate a philosophical point of view via that term, even though many actually do use it that way. ↩

14. https://www.gnu.org/philosophy/floss-and-foss.html ↩

15. OSSという語はバズワードとなって久しく、今更になってOSSではなくFLOSSという用語に置き換えるべきだという考えを執筆者が持っているわけではありません。単に知識として知っておいていただきたいというものです。そもそも執筆者は個人で開発したソフトウェアを非コピーレフトのライセンスで公開しており、自由ソフトウェアの理念に全面的な賛同を示しているわけでもありません。ですが、オープンソースと自由ソフトウェアという二つの異なる考え方はともに尊重されるべきであると考えていて、人々が何も考えずにOSSという言葉を使うとき、その背後にこれらの理念が存在しているということについて意識する機会が奪われてしまっているという意見に同意しています。それぞれの考え方を支持するかどうかは別問題として、それらの理念について人々が考える機会は与えられるべきだと思います。(なお、冒頭に記載したようにこの記事の内容は執筆者個人によるものであり、所属する組織の公式見解ではありません。) ↩