MITライセンスはなぜ世界標準？大学との関係

GitHubでめぼしいリポジトリを開くと、READMEの末尾に MIT License の一行が当たり前のように並んでいます。ここで多くの人が一度は引っかかるのが、あの有名な工科大学の名前がなぜ自分の書いたコードに出てくるのか、という素朴な疑問です。

結論を先に置くと、この誤解は条文を読めば数分で解けます。とはいえ面白いのはその先で、緩いライセンスは他にもあるのに、なぜMITライセンスばかりが選ばれ続けているのかという問いが残ります。

この記事では、条文の中身とOSI公式の扱い、普及率の実データ、起源をめぐる経緯を確認したうえで、私なりの見立てを最後に置きます。事実と見立ては段落を分けて書き分けますので、判断材料として読んでいただければ幸いです。

この4コマで起きているすれ違いは、ライセンス名を権利者の名前だと読んでしまう誤読から生まれます。実際にはMITライセンスは、ソフトウェアの著作権者が自分の名前を書き込んで使う定型文であり、条文のCopyright行に入るのは配布する本人や組織の名前です。オープンソースの世界では、名前が発祥の呼び名であって権利の所在ではない、という例が珍しくありません。

現場でこの誤解が厄介なのは、確認に時間がかかると導入判断そのものが止まる点です。ライブラリを1つ入れるだけの話が、権利関係の確認待ちで数日寝てしまう場面は、多くのチームが経験しているのではないでしょうか。読み終えるまでの時間が短いこと自体が、導入のしやすさに直結するわけです。

4コマの3コマ目で描いた条文の薄さは、単なる小ネタではありません。読む側の負担が軽いという性質が、後の章で見る普及の広さとどうつながっているのか。ここが本記事の中心テーマになります。

MITライセンスとは何か？MIT大学の許可は必要なのか？

MITライセンスとは、著作権表示と許諾文を残すことだけを条件に、ソフトウェアの利用・複製・改変・結合・公開・配布・サブライセンス・販売までを認める短い許諾条文です。マサチューセッツ工科大学に個別の許可を求めるという定めは、条文のどこにも書かれていません。

オープンソース・イニシアティブ（OSI）が公開している条文では、冒頭で広範な権利が与えられ、その直後に条件がひとつだけ置かれています。実際の一文はこうです。

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

つまり、コピーや実質的な部分を配るときには、著作権表示とこの許諾文を一緒に含めなさい、という指示です。加えて条文の後半には、無保証と責任の否定を大文字で示した段落が続きます。OSIのページでは、このライセンスがOSI承認ライセンスとして扱われ、SPDX識別子が MIT であることも確認できます。

MITライセンスはGPLやApache-2.0と何が違うのか？

MITライセンスとGPL・Apache-2.0の最大の相違点は、コピーレフトの有無と、条文に置かれた条項の数です。GNUプロジェクトはGPLv3を自由ソフトウェアライセンスかつコピーレフトライセンスと明記し、MITライセンスの実体にあたるExpatライセンスとX11ライセンスについては、ゆるやかで寛容な非コピーレフトの自由ソフトウェアライセンスであり、GNU GPLと両立すると説明しています。

条文の構造も対照的です。GPLv3の本文には前文に続いて0番から17番まで番号を振った条項が並び、Apache-2.0には1から9までの条項と付録が置かれています。一方のMITライセンスは、権利の付与・条件・免責という3つの段落だけで完結し、前掲のOSI公開条文で数えると、著作権表示の行を除いた本文はおよそ160語にとどまります。

比較観点	MITライセンス	Apache-2.0	GPLv3
コピーレフトの有無	非コピーレフト（GNUはゆるやかな寛容型と分類）	非コピーレフト	コピーレフト（GNU公式の説明）
条文の構造	番号なしの3段落	1〜9の条項＋付録	前文＋0〜17の番号付き条項
条文上の主な条件	著作権表示と許諾文を複製物に含める	ライセンス写しの同梱、変更の明示、NOTICEの扱いなど	ソースコードの提供など、改変版の配布に関する条件
特許に関する条項	条文に特許ライセンスの節はない	第3条で特許ライセンスの付与を規定	第11条で特許について規定

ここで強調しておきたいのは、この表は優劣を示すものではないという点です。改変版も自由であり続けることを担保したい場面と、社内プロダクトへ組み込みたい場面では、そもそも求めるものが違います。設計思想が異なるだけで、どちらかが上位互換という関係ではありません。

MITライセンスはどれくらい普及しているのか？

MITライセンスの普及度は、複数の調査で一貫して首位クラスに位置しています。もっとも調査ごとに母集団も年も違うため、数字は必ず前提とセットで読む必要があります。

GitHubが公開した2015年時点のシェア

GitHubの公式ブログが2015年3月9日に公開した集計では、ライセンスが付与されたリポジトリのうちMITが44.69%で1位、以下その他が15.68%、GPLv2が12.96%、Apacheが11.19%、GPLv3が8.88%と並びました。11年以上前の数値ですが、GitHub自身が自社データを示した一次情報として今も参照する価値があります。

2025年の監査データに見る現在地

より新しい数字としては、Black Duckが公開しているOSSRAレポート関連の解説があります。同社は、2025年版OSSRAレポートで監査したオープンソースのうち92%でMITライセンスが見つかり、最も一般的なライセンスだったと述べています。こちらは商用ソフトウェアの監査という母集団であり、GitHubのリポジトリ統計とは性質が異なる点に注意してください。

実際にMITを選んだ2つの事例

具体例を2つ挙げます。ひとつはReactです。当時のFacebookは2017年9月22日の技術ブログで、React・Jest・Flow・Immutable.jsをMITライセンスへ再ライセンスすると発表しました。理由として、Reactが広範なエコシステムの土台であり、技術以外の理由で前進を止めたくないこと、従来のライセンスについてコミュニティを説得しきれなかったことが挙げられています。

もうひとつはMicrosoftの.NETです。dotnet/runtimeリポジトリのライセンスファイルはMITライセンスであり、.NET Foundationおよびコントリビューターの著作権表示から始まります。対照的な例として、このブログの土台であるWordPressはGPLv2（またはそれ以降）で配布されていると公式に明記されています。同じオープンソースでも、選ぶ条文は目的によって割れているわけです。

MITライセンスの起源はX11ライセンスなのか？

MITライセンスの起源は、MITのProject Athenaで生まれたX Window Systemの配布条件にさかのぼるとされています。ただし、いつ単一の正典が確定したのかを明快に示せる資料は乏しく、断定は避けるべき領域です。

Opensource.comが2019年4月26日に公開した記事では、Jim Gettys氏の証言として、独自の配布制限が負担になったためMITの法務が許諾文言を用意したこと、IBMが特定のライセンスのないコードを扱いたがらなかったことが紹介されています。そのうえで同記事は、1985年にX Version 6へオープンソース的なライセンスが加わり、1987年のX11でX Consortiumのライセンスとして固まったあたりが単一の答えとしては最良だと整理しています。

ややこしいのはその先です。同記事によれば、OSIが1999年前後に文書化した現行のMITライセンスの文面は、XMLパーサであるExpatに由来する言い回しを取り込んでおり、元のX Consortiumライセンスとは差があります。なぜその移行が起きたのかは分かっておらず、偶発的だった可能性も示唆されています。

GNUのライセンス一覧が、ExpatとX11の両方の項目で同じ注意を繰り返しているのも、この経緯と無関係ではないでしょう。同一覧は、この条文をMITライセンスと呼ぶ人がいるが、MITは多くのライセンスを使ってきたためその呼び方は誤解を招く、と述べています。両者の差は、X Consortiumの名称の使用に関する一段落があるかどうかという点です。

なぜMITライセンスが事実上の標準になったのか？

MITライセンスが事実上の標準になった要因として、私は採用時の摩擦の少なさを最も重く見ています。ここからは事実の整理ではなく、公開情報から逆算した私の見立てとして読んでください。

読む時間が短いという競争力

すでに見たとおり、MITライセンスの本文は3段落しかありません。ライブラリを1つ採用するたびに条文を読み合わせる立場からすると、この分量差は無視できないコストの差になります。技術の良し悪しではなく、確認作業の重さが選択を左右する場面は、多くの開発現場で起きていると考えられます。

キャラクターの持論めいた言い方をすれば、サービスも規約も、機能で選ばれて習慣で生き残ります。MITライセンスの場合、迷ったらこれで良い、という判断がチーム内で習慣化しやすかった。あくまで外から見ての見立てですが、この習慣化こそが最大の武器だったのではないでしょうか。

導線が整えられた時期と重なった可能性

普及の背景として、選び方を案内する導線の存在も見逃せません。GitHubの前掲ブログには、2013年半ばに choosealicense.com とライセンスピッカーを導入したところ、掲載した3つのライセンスの選択が急増したという記述があります。これはGitHub自身の観察として示された事実です。

ただし、その導線が今日のMITライセンス優位を生んだ、と因果を言い切れる一次情報は見当たりません。公式にはこう説明されていますが、私は導線が既存の傾向を加速させた面が大きいと見ています。断定はできない、というのが誠実な整理でしょう。

思想の強さではなく、ひっかからなさが残った

GPLが掲げたコピーレフトは、改変版も自由であり続けることを担保する強い設計思想です。その価値が薄れたとは私は考えていません。一方で企業が自社プロダクトへ組み込む局面では、条件が少ない条文のほうが検討が早く終わります。Reactの再ライセンスが技術以外の理由という言葉で説明されたことは、この力学を象徴していると受け取っています。

一番えらいものが標準になるとは限らず、一番ひっかからないものが標準として残る。使われることを最優先に設計された文書が、結果として最も広く使われたという逆説です。これは私の解釈であり、優劣の評価ではありません。

MITライセンスの話から何を持ち帰るか？

MITライセンスの歴史から持ち帰れる教訓は、標準は正しさではなく通りやすさで決まる場面がある、ということです。生成AIが書いたコードの権利処理や、依存パッケージの棚卸しが当たり前になっていく流れの中で、条文を読む回数はこれから確実に増えます。読む回数が増えるほど、短い文書の優位はさらに効いてくるでしょう。

この教訓を今のトレンドに掛け合わせると、次に起きそうなことは1つに絞れます。AI生成コードの由来表示や部品表の整備が進むにつれ、短くて機械可読な表明が新しい標準の座を取りにいくのではないか、というのが私の予想です。あなたが今使っているライブラリのライセンス表示は、そのとき自信を持って人に説明できる状態でしょうか。

次のアクションとして、自分のリポジトリのLICENSEファイルを1つ開き、Copyright行の名前と年が正しく入っているかだけ確認してみてください。作業は数十秒で終わります。

類似のIT考察

OSSのマスコットに動物が多い理由とは？	OSSプロジェクトの名前や象徴に動物が選ばれてきた背景と、その文化的な意味を考察した記事。
なぜソフトはv0.9のまま1.0にならないのか	バージョン番号を1.0に上げない開発文化の理由と、慣習が固定化していく仕組みを掘り下げた記事。
違法ダウンロードはどこからアウト？視聴との境界線	著作物の利用がどこから問題になるのかを整理し、権利と行為の境界線を確認する記事。

この記事と一緒に知っておきたい用語

用語	この記事との関連
オープンソース	MITライセンスが機能する前提となる、ソースコード公開と自由な利用の枠組み。
コピーレフト	GPLとMITライセンスを分ける最大の論点であり、本記事の比較表の軸。
著作権	MITライセンスが保持を義務づける著作権表示の土台になる権利。
GitHub	ライセンス表示に触れる機会が最も多く、普及率の統計でも母集団になった場。
デファクトスタンダード	公的な決定ではなく実際の採用で標準が決まる現象そのものを指す言葉。

【出典】参考URL

https://opensource.org/license/mit ：MITライセンスの条文全文、著作権表示と許諾文の保持という条件、OSI承認ライセンスとしての扱いおよびSPDX識別子
https://www.gnu.org/licenses/ ：コピーレフトの定義と、GPLv3を含むGNUの各ライセンスの位置づけ
https://www.gnu.org/licenses/license-list.html ：ExpatおよびX11をゆるやかな非コピーレフトの自由ソフトウェアライセンスとする分類、MITライセンスという呼称が誤解を招くという指摘、GPLv3をコピーレフトとする記述
https://opensource.org/license/gpl-3-0 ：GPLv3の前文と0番から17番までの番号付き条項の構成
https://www.apache.org/licenses/LICENSE-2.0.txt ：Apache-2.0の1から9までの条項と付録の構成、第3条の特許ライセンス
https://opensource.com/article/19/4/history-mit-license ：Project Athenaに由来する経緯、1985年および1987年の時点、Expat由来の文面への移行と単一の正典が存在しないという整理（Gordon Haff、2019年4月26日）
https://github.blog/open-source/open-source-license-usage-on-github-com/ ：2015年3月9日公開のライセンス別シェア（MIT 44.69%ほか）と、2013年半ばのchoosealicense.comおよびライセンスピッカー導入に関する記述
https://www.blackduck.com/blog/top-open-source-licenses.html ：2025年版OSSRAレポートで監査したオープンソースの92%にMITライセンスが見つかったという記述
https://engineering.fb.com/2017/09/22/web/relicensing-react-jest-flow-and-immutable-js/ ：React・Jest・Flow・Immutable.jsのMITライセンスへの再ライセンス発表と、その理由
https://github.com/dotnet/runtime/blob/main/LICENSE.TXT ：.NETランタイムがMITライセンスで配布されていること
https://wordpress.org/about/license/ ：WordPressがGPLv2（またはそれ以降）で配布されていること