著者 Linuxカーネルの歴史と現在も残る重要な決定
Linuxカーネルの0.01から7.xまでをたどり、1992年のGPL移行、マイクロカーネル論争、gitの誕生、LTSモデルがサーバー運用に与えた意味を解説します。
Linux カーネルの歴史を簡単に振り返る
Linux カーネルの歴史は、1991 年 9 月のバージョン 0.01 から、現在サーバーで起動している 7.x 系列まで続いています。リリース一覧は、歴史の中で最も重要な部分ではありません。いくつかの決定が全体の形を定めており、その一つ一つが、今日借りるサーバーにも影響しています。
ここで示す日付とバージョン番号は、kernel.org と同サイトが公開するリリース履歴に基づいています。2026 年 8 月時点の状況は次のとおりです。7.0 は 2026 年 4 月 12 日にリリースされ、7.1 は 2026 年 6 月 14 日にリリースされ、7.2 はリリース候補版の段階です。
1992 年に GPL を選択したことが現在も重要な理由
Version 0.01 は 1991 年 9 月 17 日、Torvalds が自ら作成したライセンスの下で公開されました。このライセンスはソースコードの配布を義務付け、さらに重要な一文を加えていました。「料金を取って配布してはならない。『取り扱い』費用であっても同様とする」。1991 年当時、ソフトウェアはフロッピーディスクで配布され、フロッピーディスクの複製や発送には費用がかかりました。この条項により、商用 Linux ディストリビューションは不可能になりました。
Torvalds はこの方針を変更しました。GNU General Public License (GPL) への移行は、1992 年 1 月の 0.12 release notes で告知され、1992 年 2 月 1 日に発効しました。1992 年 3 月の Version 0.95 が、GPL の下で公開された最初のリリースです。その後 Linux を基盤として構築されたすべてのビジネスは、この変更の上に成り立っています。
Kernel は GPL version 2 のみを採用しており、version 3 には移行していません。Torvalds は 2007 年に移行を拒否しました。主な理由は GPLv3 の anti-tivoisation rule です。この規則では、GPL code を搭載して出荷するデバイスに、そのコードの改変版も受け入れさせることを求めています。Torvalds は、ロックされたハードウェアをメーカー自身の事業上の判断として扱いました。2017 年、kernel developers は Kernel Enforcement Statement を公開しました。これは GPLv3 の要素を 1 つ取り入れています。違反の通知を受けた後に違反を是正した人は、最初の違反時にライセンスを永久に失うのではなく、ライセンスを維持できます。
サーバーでは、2 つの結果が生じます。起動する kernel binary には、対応する source code を入手する権利が伴います。そのため、誰も検査や再ビルドができない Linux kernel を渡すことはできません。また、kernel の著作権表示には、通常の system call で kernel services を利用する user programs はこのライセンスの対象外であると記載されています。これが、proprietary databases や monitoring agents が Linux 向けに出荷されても問題にならない理由です。Permissive licence では逆の圧力が生じます。プラットフォームを選ぶ前に、この違いを理解しておく価値があります。サーバープラットフォームとしての Linux と FreeBSD を参照してください。
実運用でモノリシックカーネルが主流になった理由
1992年1月29日、Andrew Tanenbaum は comp.os.minix ニュースグループに「LINUX is obsolete」という題名のメッセージを投稿しました。彼は2つの主張を示しました。ドライバーとファイルシステムが1つの特権アドレス空間内で動作するモノリシックカーネルは1970年代の設計であり、それらが通常のプロセスとして動作するマイクロカーネルが将来の方式だという主張です。もう1つは、Linux は Intel 386 に強く依存しているため、他の環境へ移植されることはないという主張でした。
移植によって、移植性に関する主張には反論が示されました。1995年3月の Version 1.2 では Alpha、SPARC、MIPS が追加されました。1996年6月の Version 2.0 では、64-bit Alpha への移植が追加されました。
設計に関する主張には、折衷案で応えました。Linux はマイクロカーネルにはなりませんでした。その代わり、loadable kernel modules が導入されました。これは実行中のカーネルに挿入したり、後から削除したりできる object file です。そのため、ドライバーをカーネル binary とは別にリリースできます。
lsmod | head
modinfo virtio_net | head -5lsmod は現在ロードされているものを一覧表示します。modinfo は、モジュールの取得元ファイルと、モジュールが受け付けるパラメーターを表示します。仮想サーバーでは、ディスクとネットワークの処理経路の大部分がモジュールで構成されています。そのため、これまで認識したことのないハードウェアでも、1つのカーネルイメージで起動できます。
モジュールによって、マイクロカーネル設計に伴うコストを負担せずに柔軟性を得られました。ドライバーを専用プロセスに分離すると、呼び出しのたびにコンテキストスイッチとメッセージ送信のコストが発生します。1992年当時、そのコストは大きなものでした。
Linux が引き受けたコストは、運用時に考慮する必要があります。モジュールは完全なカーネル権限で動作するため、不正なモジュールが1つのプロセスではなくマシン全体を停止させる可能性があります。この問題が特に現れるのが、out-of-tree モジュールです。mainline に含まれないベンダードライバーは、新しいカーネルごとに再ビルドする必要があります。アップグレード中にこれを行うのが DKMS です。このビルドに失敗すると、再起動後にデバイスが単に利用できなくなります。
SMP の完成に 15 年かかった理由
Linux 2.0 は 1996 年 6 月に、対称型マルチプロセッシング（SMP）をサポートした最初のカーネルとして登場しました。これは、1 つのカーネルを複数の CPU で実行する仕組みです。最初の実装では、big kernel lock（BKL）という単一のロックを使用していたため、カーネルコード内に入れるプロセッサは常に 1 つだけでした。そのため、2 つ目の CPU はユーザー空間で計算するワークロードには効果がありましたが、システムコールを多用するワークロードにはほとんど効果がありませんでした。システムコールは同じロックの後ろで待機したためです。
このロックの削除には 15 年かかりました。残っていた利用箇所は、主に Arnd Bergmann によって細粒度ロックへ移行され、BKL は 2011 年 5 月 18 日にリリースされた 2.6.39 で削除されました。スケジューラの進化にも同じように長い時間がかかりました。2.6.0 では O(1) scheduler、2007 年の 2.6.23 からは Completely Fair Scheduler（CFS）、そして 2023 年 10 月の 6.6 では CFS に代わる EEVDF が導入されました。
この取り組みがあったからこそ、現在では 4 vCPU のプランは珍しくありません。ただし、知っておくべき限界もあります。共有仮想サーバーでは、カーネルがスレッドをスケジュールし、ハイパーバイザーがそのカーネルをスケジュールします。top を実行して %st フィールドを確認してください。steal time とは、カーネルが使用できる状態だった CPU 時間をホストが別のゲストに割り当てた時間です。そのため、カーネル内のチューニングで取り戻すことはできません。
2.6 系列でカーネルのビルド方法が変わった理由
2.6 より前は、バージョン番号が2つの系列に分かれていました。2番目の番号が偶数なら安定版系列（2.4）、奇数なら開発系列（2.5）でした。2.4 は 2001 年 1 月 4 日に、2.6 は 2003 年 12 月 17 日にリリースされたため、ユーザーは次の安定版系列をほぼ3年間待つ必要がありました。ディストリビューションは待てなかったため、修正をバックポートしました。2つのベンダーがどちらも「2.4」を出荷していても、搭載されるカーネルは数千個のパッチ分も異なることがありました。
この分割は 2.6 の後に廃止されました。現在のメインラインは約2週間のマージウィンドウを開いて新しい変更を受け入れ、その後、静かになるまでリリース候補版を公開し、9〜10週間ごとにリリースします。この周期は現在も kernel.org が案内しています。モデルのもう一方の部分は、2005 年 3 月 4 日に最初の stable tree がリリースされたことで始まりました。これは 2.6.11 に対する修正のみの更新で、Greg Kroah-Hartman と Chris Wright が保守しました。stable tree は修正を受け入れますが、新機能は受け入れません。
副作用として、バージョン番号は保証を示さなくなりました。3.0、4.0、5.0、7.0 は書き直された新しいカーネルではありません。Torvalds は、2番目の番号が大きくなって気になると最初の番号を上げます。そのため、2026 年 4 月には 6.19 の後に 7.0 が続きました。サーバーで重要なのは、ディストリビューションがどのブランチを追跡しているか、そしてそのブランチにまだ修正が提供されているかどうかです。
2005 年 4 月、BitKeeper の決裂から git が生まれた経緯
2002 年 2 月から、カーネルは 2.5 系列で開発され、Larry McVoy の会社 BitMover が提供するプロプライエタリな分散バージョン管理システム BitKeeper で管理されていました。BitMover は、条件付きでカーネル開発者に無償ライセンスを提供していました。競合するバージョン管理ツールの開発に携わってはならず、BitKeeper をリバースエンジニアリングしてはならないという条件です。多くの開発者は、内容を読むことを許されていないツールで自由なカーネルを開発することに不満を持っていました。
2005 年 4 月、Andrew Tridgell が BitKeeper リポジトリと通信するプログラムを実演した後、関係は決裂しました。BitMover はこれをリバースエンジニアリングと判断し、無償ライセンスを撤回しました。カーネルは開発サイクルの途中でバージョン管理システムを失いました。
git の開発は 2005 年 4 月 3 日に始まりました。Torvalds は 4 月 6 日に発表しました。4 月 7 日には git 自身が git で管理されていました。これは、git 自身の履歴がすでに git に保存されていたという意味です。複数のブランチを初めてマージしたのは 4 月 18 日です。2005 年 6 月には、git で 2.6.12 のリリースを管理しました。その後まもなく、Torvalds は保守を Junio Hamano に引き継ぎ、カーネル開発に戻りました。
設計は、この問題から直接導かれました。何千人もの貢献者が存在し、誰も信頼していないネットワークを介してメンテナー同士が変更を取り込む環境です。すべてのオブジェクトは内容のハッシュで名前が付けられるため、古い履歴の 1 バイトを変更すると、それ以降のすべてのコミットの名前が変わります。これが、clone が主張ではなく証拠になる理由です。すべてのデプロイパイプライン、すべての設定リポジトリ、多くのチームが push するコードホスト、そして 自分で運用できる git サーバーは、カーネルをめぐるライセンス上の議論から生まれました。
LTS モデルが保証すること、保証しないこと
Mainline は通常運用で使うものではありません。Mainline リリースは 9〜10 週間後に後続リリースへ置き換えられます。stable ツリーには、各リリース後の数週間にわたって修正が提供されます。通常 LTS と表記される Longterm ブランチには、修正が数年間提供されます。ディストリビューションは通常、これらのブランチを基盤に構築されます。
2009 年 12 月にリリースされた 2.6.32 で、このモデルの有効性が証明されました。RHEL 6、Debian 6、SUSE Linux Enterprise 11 SP1、Ubuntu 10.04 LTS はすべてこのバージョンを採用し、このブランチは登場から 6 年以上経過した 2016 年 2 月まで保守されました。
保守期間の保証は、これまでに複数回変更されています。当初は 2 年間でしたが、一部のブランチでは 6 年間になりました。2023 年、stable のメンテナーは標準の保守期間を 2 年間に戻しました。古いツリーへのバックポートにはメンテナーの時間がかかり、古いブランチは実際のテストが少ないためです。2026 年 2 月 25 日、Greg Kroah-Hartman は、それらのブランチに依存する企業との協議を経て、より長い見通しを再び発表しました。現在の枠組みでは、保守期間は 3〜6 年です。
The data behind this chart
[
{
"kernel": "5.10",
"released": "2020-12-13",
"eol_projected": "Dec 2026",
"maintained_for": 6.0
},
{
"kernel": "5.15",
"released": "2021-10-31",
"eol_projected": "Dec 2026",
"maintained_for": 5.1
},
{
"kernel": "6.1",
"released": "2022-12-11",
"eol_projected": "Dec 2027",
"maintained_for": 5.0
},
{
"kernel": "6.6",
"released": "2023-10-29",
"eol_projected": "Dec 2027",
"maintained_for": 4.2
},
{
"kernel": "6.12",
"released": "2024-11-17",
"eol_projected": "Dec 2028",
"maintained_for": 4.1
},
{
"kernel": "6.18",
"released": "2025-11-30",
"eol_projected": "Dec 2028",
"maintained_for": 3.1
}
]2026 年 8 月時点で、kernel.org には 6 個の Longterm ブランチが掲載されています。最も古い 5.10 は、Dec 2026 に終了する時点で、6.0 年間修正が提供されたことになります。最も新しい 6.18 は Dec 2028 まで維持される見込みで、修正の提供期間は 3.1 年間です。
これらの日付は契約上の保証ではなく、最低限の目安として扱ってください。6.6 と 6.12 の見通しは、どちらも 2026 年 2 月に延長されました。一方、利用者のいないブランチは、予定より早く廃止される可能性があります。通常は、ディストリビューションが使用するカーネルを選択するため、利用者が自分で選ぶ必要はありません。Debian 13 は 6.12 を採用し、Ubuntu 26.04 LTS は 7.0 を採用しています。この差が、サーバーで LTS と中間リリースのどちらを選ぶかという問題の実際の内容です。また、Ubuntu 24.04 を 26.04 にアップグレードする際に、実際に下で変更されるものでもあります。
ここから、1 つ注意点が生じます。Ubuntu 24.04 で uname -r を実行すると、6.8.0-51-generic のような結果が表示されます。これは上流のベースにディストリビューション独自のバックポートを加えたものであり、番号から分かるのはブランチの開始点だけです。そこにどの修正が含まれているかは、番号からは分かりません。まさにこの理由から、カーネルをバージョン文字列だけで判定するスキャナーは、ディストリビューションのカーネルに対して誤警告を出します。
カーネルで現在議論されていること
現在、2 つの議論が進んでおり、どちらも作業を誰が担うかが論点です。
Rust は 2022 年 12 月の 6.1 で基盤機能として導入されました。7.0 では実験的というラベルが外れたため、カーネルの中核言語は C、assembly、Rust となり、ビルドに nightly compiler は不要になりました。争点は保守です。C のメンテナーがインターフェースを変更すると、確認していない Rust のバインディングを壊す可能性があります。その修正を誰の責任で行うのかが議論されています。
2 つ目の議論は、AI による貢献です。機械の支援を受けたパッチがメーリングリストに届く数が増えたことを受け、Sasha Levin は 2025 年 7 月にポリシーを提案しました。この文書は 2025 年 12 月 23 日にコミットされ、現在はカーネル独自のプロセス文書である docs.kernel.org/process/coding-assistants.html に置かれています。AI エージェントは Signed-off-by タグを追加してはいけません。この行は Developer Certificate of Origin (DCO) を証明するものであり、証明できるのは人だけだからです。支援は Assisted-by: タグで申告します。ツールは作者ではないため、レビュー中に Co-developed-by: から変更されました。生成されたコードは GPL-2.0-only と互換性が必要です。パッチを送信する人がレビューし、その責任を負います。
このポリシーの背景にある課題は、レビュー時間です。パッチの生成には数秒しかかかりませんが、1 つのパッチのレビューにはメンテナーの午後が費やされます。タグを付けても、この不均衡は解消されません。維持されるのは来歴です。履歴には各変更について誰が署名したかが記録され続けます。これは、DCO が 2004 年に保護するために導入された特性です。
サーバーをレンタルする際に、この歴史が意味すること
- ライセンスがあるため、プロバイダーが起動するカーネルを読み取り、再構築できます。また、プロプライエタリソフトウェアもその上で動作します。
- モノリシック設計のため、1 つのドライバーのバグでマシン全体が再起動します。また、out-of-tree モジュールはカーネルをアップグレードするたびに再構築する必要があります。
- リリースモデルのため、バージョン番号から分かることは多くありません。一方、ブランチとその end-of-life 日からは、ほぼすべてを判断できます。
- 仮想化の種類によって、実行できる操作が決まります。KVM では独自のカーネルを起動してモジュールを読み込めます。ホストカーネルを共有するコンテナ仮想化では、
uname -rでホストのバージョンが表示され、modprobeは失敗し、複数の sysctl が読み取り専用になります。
FAQ
Linux カーネルはなぜ GPLv3 ではなく、今も GPLv2 なのですか？
Torvalds は、主に反ティボ化要件を理由として、2007 年に GPLv3 の採用を見送りました。この要件では、GPL コードを搭載して出荷するデバイスに、そのコードの改変版も受け入れさせることが求められます。Torvalds は、ハードウェアをロックするかどうかはメーカーの事業上の判断だと考えています。実際には、再ライセンスもほぼ不可能です。カーネルの著作権は数千人の貢献者が保有しており、代わりに依拠できる著作権譲渡契約もないためです。カーネルは GPL-2.0-only で提供されるため、GPLv3 のみで提供されたコードはマージできません。
Linux カーネルはモノリシックカーネルですか、それともマイクロカーネルですか？
ロード可能なモジュールを備えたモノリシックカーネルです。ドライバーとファイルシステムはカーネルのアドレス空間内で実行され、lsmod には現在ロードされているものが表示されます。一方では速度が得られますが、他方では障害の影響範囲が大きくなります。障害のあるモジュールによってマシン全体が panic する可能性があるためです。マイクロカーネルでは、通常は 1 つのプロセスが失われるだけです。1992 年以降、ユーザー空間で動作する FUSE ファイルシステムや、実行前にカーネルが検証する eBPF プログラムにより、この違いは小さくなっています。
mainline、stable、longterm カーネルの違いは何ですか？
mainline は Torvalds のツリーで、9 から 10 週間ごとにリリースされ、新機能は最初にここへ取り込まれます。stable は直近の mainline リリースを基にし、数週間にわたってバグ修正を受け取ります。longterm ブランチは数年間にわたって修正を受け取り、ディストリビューションは通常これを基にカーネルを構築します。kernel.org には、現在の longterm ブランチと、それぞれの予定された end-of-life 日が掲載されています。
Linux カーネルは AI が作成したコードを受け入れますか？
はい。2025 年 12 月に確定したポリシーの下で受け入れられます。ツールは Assisted-by: タグ内に記載する必要があり、AI エージェントが Signed-off-by 行を追加してはなりません。また、生成されたコードは GPL-2.0-only と互換性が必要です。人間の提出者は sign-off を行います。これは、パッチをレビューし、Developer Certificate of Origin に基づく責任を負うことを意味します。
サーバーではどのカーネルバージョンを実行すべきですか？
ほとんどの場合、ディストリビューションが保守しているものを使用します。ディストリビューションのカーネルは、longterm ブランチにバックポートされた修正とベンダーによるテストを加えたものであり、プロバイダーのイメージやサポート契約もこれを前提にしています。特定のドライバーや機能が必要な場合は、より新しい mainline カーネルを構築します。そのブランチへ移行する前に、end-of-life 日を確認してください。