🌱 seed2026-07-08

githubライセンスの系譜

GitHubでMITライセンスがよく使われる理由と、OSSライセンスを選ぶときの判断軸を整理するノート。

迷ったらMITでよい場面は多い。ただし、特許、改変版の公開、SaaS化への懸念があるなら、そこで選択肢は変わる。

GitHubでリポジトリを作るとき、LICENSEファイルの選択画面でなんとなく「MIT」を選んでいないだろうか。実際、その直感は数字にも裏付けられている。GitHubが2015年に公開した集計では、ライセンスが検出された公開リポジトリのうちMITが44.69%で1位だった。GitHub Innovation Graphでも、MITはライセンスを宣言しているプロジェクトの中で大きな比率を占める。

GitHubは2013年にChoose a Licenseとライセンスピッカーを用意し、MIT、Apache-2.0、GPLv3のような主要ライセンスを選びやすくした。GitHub Docsは、公開リポジトリであってもライセンスがなければ、通常の意味で利用・改変・再配布を許したことにはならないと説明している。つまり、コードを見せることとOSSにすることは違う。

一方で、2018年頃からMongoDB、Elastic、HashiCorp、Redisのような著名プロジェクトがライセンスを変更する動きも起きており、ライセンスの世界は今も静かに動き続けている。本記事では、自作ツールを公開するときに、この記事だけ見返せば選定できる状態を目指す。法的助言ではなく、判断軸を整理するためのノートとして書く。

GitHubでは何が選ばれているか

GitHubの2015年分析では、MIT、Apache、GPLが明確な上位にあり、約15%はChoose a Licenseに掲載されていない非標準ライセンスやカスタムライセンスだった。つまり「MITだけが使われている」わけではないが、主要ライセンスの中ではMITの存在感がかなり大きい。

企業のOrganizationに絞ると、個人開発とは少し感触が変わる。特許条項や貢献の扱いを明確にしたい大規模・企業寄りのプロジェクトでは、Apache-2.0が選ばれやすい。Kubernetesのようなクラウドネイティブ系プロジェクトでApache-2.0をよく見るのは、この文脈で理解しやすい。

一方で、npmのようなパッケージエコシステムではMITやISCが強い。小さなライブラリは、広く依存されること自体が価値になりやすい。そのため、利用者側の法務・再配布・商用利用の摩擦を減らすパーミッシブなライセンスが選ばれやすい。

なぜMITが選ばれるのか

MITが選ばれやすい理由は、法律的な強さというより、短さとわかりやすさにある。著作権表示とライセンス文を残せば、次の利用を広く許す。

商用利用
改変
再配布
クローズドソースへの組み込み

利用者や企業の法務レビューの負担も比較的小さい。

GitHubで長年ライセンス周りを扱ってきたBen Balter氏の記事も、開発者にとってMITが扱いやすい理由を示している。MITは短く、できることと免責が分かりやすく、法律の専門家でなくても読みやすい。ここで重要なのは、MITが最も強いライセンスだから選ばれるのではなく、開発者と利用者の両方にとって摩擦が少ない点である。

整理すると、MITの強さは次のあたりにある。

条文が短く、読むコストが低い
改変後のソースコード公開義務がない
npmなどのエコシステムで慣習化している
GitHubのライセンスピッカーやChoose a Licenseで選びやすい
React、Node.js、Ruby on Rails、jQueryなど著名プロジェクトの採用例がある

ただしMITには、特許許諾が明示されていないという弱点がある。そこで企業やクラウドネイティブ系の基盤ソフトでは、Apache-2.0が選ばれやすい。Apache-2.0はMITと同じく寛容型だが、次の点を明確に書く。

特許権の許諾
変更箇所の表示
商標を許諾しないこと

Kubernetesのような大きいプロジェクトで見かける理由は、このあたりにある。

ライセンスの系譜

OSSライセンスは、大きく三つの系統で見ると理解しやすい。

パーミッシブ系: BSD、MIT、ISC、Apache

一つ目は、BSD、MIT、ISC、Apache-2.0のようなパーミッシブ系である。大学や研究機関、基盤ソフトウェアの文化から広がり、「使ってよい、ただし表示は残してほしい」という発想が中心にある。

ただし、この系統を「だいたい同じ寛容なライセンス」とだけ見ると、なぜ種類が分かれているのかが見えにくい。実際には、条件の数と、特許・変更履歴・商標を明示的に扱うかどうかで少しずつ枝分かれしている。

ライセンス	主な条件	特許への言及	位置づけ
BSD 4-Clause	著作権表示の保持、広告での謝辞義務	なし	古い原型。広告条項が扱いにくく、現在はほぼ使われない。
BSD 3-Clause	著作権表示の保持、名前を宣伝に無断利用しない	なし	現在の標準的なBSD。広告条項を削り、名前の悪用だけを禁じる。
BSD 2-Clause	著作権表示の保持	なし	3-Clauseからさらに条件を削った短いBSD。
MIT	著作権表示の保持	なし	BSD 2-Clauseに近い効果を持つ、短く普及した文面。
ISC	著作権表示の保持	なし	MITに近いが、さらに簡潔な文面。
Apache-2.0	著作権表示の保持、変更箇所の表示、NOTICEの継承	明示あり	特許許諾、特許訴訟時の失効、商標を許諾しないことまで書く。

実務上は、MIT、BSD、ISCは「短く、表示を残せば広く使える」系統として近い。Apache-2.0だけは、特許、変更履歴、商標を条文で明確に扱う点で一段違う。企業や大規模プロジェクトでApache-2.0を見かける理由は、この差分にある。

コピーレフト系: GPL、LGPL、AGPL

二つ目は、GPL、LGPL、AGPLのようなコピーレフト系である。こちらは「使ってよいが、改変版や派生物を閉じすぎないでほしい」という発想が中心にある。

この系統の違いは、どこまで公開条件を及ぼすかで見ると分かりやすい。

ライセンス	公開条件が効く範囲	位置づけ
GPL	配布する改変版や派生物	コピーレフトの基本形。配布するなら同じ条件で公開する。
LGPL	主にライブラリ本体の改変部分	ライブラリとして使われる用途に配慮した緩和版。
AGPL	ネットワーク越しに提供するサービス利用まで	SaaSとして動かす場合にもソース公開を求めうる強化版。

自分のコードから派生したものも開かれたままにしたいなら、この系統が候補になる。ただし、企業利用や商用プロダクトへの組み込みでは敬遠されることもある。利用を広げたいのか、再配布時の公開条件を強くしたいのかで判断が分かれる。

中間系: MPL

三つ目は、MPLのような中間系である。MPLはファイル単位のコピーレフトに近く、MPLのファイルを改変した場合はその変更をMPLで公開する必要があるが、プロジェクト全体を同じライセンスで覆うわけではない。

MITほど自由に流したくはないが、GPLほど強く縛りたくない場合に理解しておきたい位置である。TerraformやVaultが以前採用していたMPL-2.0も、この中間的な性格を持っていた。

近年の揺れ

2018年以降は、クラウド事業者がOSSをマネージドサービスとして提供する問題が、ライセンス変更の大きな背景になった。MongoDBはSSPLへ移行し、Elasticは2021年にApache-2.0からSSPLとElastic Licenseのデュアルライセンスへ移った。HashiCorpは2023年にTerraformなどをBusiness Source Licenseへ変更し、Redisも2024年にBSD-3-ClauseからRSALv2/SSPLv1へ移行した。

これらは、ソースは見えるが、OSIの意味ではオープンソースとは言いにくい Source Available の流れである。BSLは一定期間後にApache-2.0などのOSSライセンスへ移る設計を取れるが、その期間中は商業利用に制限が残る。個人の小さなツールで採用することは多くないが、SaaS化や商用化を強く意識する場合には、知っておく価値がある。

一方で、揺り戻しもある。Elasticは2024年にAGPLを追加し、Redisも2025年にAGPLv3を追加した。AGPLは強いコピーレフトだが、OSI承認ライセンスであり、クラウド時代にOSSの看板を維持しながらサービス化への牽制を残す選択肢として再評価されているように見える。

個人の小さなツールでは、ここまで複雑に考えなくてよいことが多い。ただし、最初に一度だけ考えておきたい問いはある。

将来そのままSaaS化されると困るか
企業に組み込まれても構わないか
派生物を開かせたいか

後からライセンスを変えると、既存利用者やコミュニティとの関係が難しくなる。

自分のツールで選ぶなら

次に自分のツールをOSSにするときは、まず目的で分ける。

目的をはっきりさせる

最初に見るのは**「なぜOSS化するのか」**である。

多くの人に使ってほしいのか
企業に組み込まれてもよいのか
改変されたら還元してほしいのか
SaaSとしてそのまま使われると困るのか

目的によって候補は変わる。

目的	候補
とにかく多くの人に使ってほしい	`MIT`
MITに近いが、特許許諾を明確にしたい	`Apache-2.0`
改変版も同じ条件で公開してほしい	`GPL-3.0`
SaaSとして使われた場合も公開を求めたい	`AGPL-3.0`
ライブラリ利用は広く許しつつ、変更部分は返してほしい	`MPL-2.0` または `LGPL`
商用利用や用途を制限したい	OSSではなく、独自ライセンスやSource Availableとして扱う

依存ライブラリと矛盾しないか確認する

次に、依存しているライブラリのライセンスと矛盾しないかを確認する。

GPL系のライブラリを組み込んでいる場合: 自分のプロジェクトだけを自由にMITへできないことがある
MIT、BSD、Apache系のコードを利用する場合: 表示義務やライセンス文の同梱を守りつつ、自分のプロジェクトには別のライセンスを選べることが多い

改変後に公開してほしいか決める

実質的な分岐は、**「改変後に公開してほしいか」**で決まる。

改変版を非公開のまま商用利用されても構わない: MIT / Apache-2.0 / BSD
配布される改変版は同じ条件で公開してほしい: GPL
ライブラリとして使われるだけなら緩くしたい: LGPL
SaaSとして使われる場合も公開を求めたい: AGPL

エコシステムの慣習を見る

さらに、言語やエコシステムの慣習も見る。

Node.js/npmパッケージ: MIT がかなり自然
Pythonパッケージ: MIT または Apache-2.0、研究系では BSD-3-Clause
クラウドネイティブ、インフラ系: Apache-2.0
学術・研究コード: BSD-3-Clause や MIT

研究でBSD-3-Clauseが出てくるのは、大学や研究機関由来のソフトウェアでBSD系ライセンスが長く使われてきたためである。MITと同じくパーミッシブ系統だが、著作権表示、免責、名前を宣伝に無断利用しないことを3つの条項として明示する。

迷ったらMIT、ただし将来を一度だけ想像する

結論として、強いこだわりがなければMITを初期値にしてよい場面は多い。ただし公開前に一度だけ、次の問いを考える。

このプロジェクトが将来、そのままクラウドサービス化されたら困るか。

困るなら、最初からAGPLやデュアルライセンスを検討する余地がある。

ライセンスは思想表明でもあるが、実務上は**「他人が安心して使うための条件表」**でもある。まずは次の地図で十分だと思う。

迷ったら: MIT
特許を意識するなら: Apache-2.0
派生物を開かせたいなら: GPL / AGPL
ファイル単位で戻してほしいなら: MPL

次に残る問い

個人開発の小さなツールで、SaaS化への懸念をどこまで先に考えるべきか。
Source Available とOSSの境界は、利用者にどの程度伝わっているのか。
ライセンス選択を、思想表明ではなく運用上の条件表としてどう見せるか。

参考・出典

GitHub Blog: Open source license usage on GitHub.com
2015年時点のGitHub上の主要ライセンス比率を確認した。
GitHub Innovation Graph: Licenses
GitHub上で使われる主要ライセンスの近年の傾向を確認した。
GitHub Docs: Licensing a repository
GitHubでのライセンス設定、未設定時の扱い、検出方法を確認した。
Choose a License
MIT、Apache-2.0、GPLv3の説明と「ライセンスなし」の扱いを確認した。
Open Source Initiative: The Open Source Definition
OSIのオープンソース定義を確認した。
SPDX License List
ライセンス識別子の標準表記を確認した。