NVIDIAがGPLライセンスのカーネルモジュールを提供するようになった最大の理由は、そのドライバーアーキテクチャが、GPUの重要な知的財産をファームウェアやユーザー空間コンポーネントに保持しながら、Linuxとの統合・配布・保守を大幅に簡素化できる段階まで進化したためです。

正確には、NVIDIAはドライバースタック全体をオープンソース化したわけではありません。オープンになったのは主に以下のLinuxカーネルモジュールです。

  • nvidia.ko
  • nvidia-drm.ko
  • nvidia-uvm.ko
  • nvidia-modeset.ko

CUDA、OpenGL、Vulkanなどのユーザー空間コンポーネントとGSPファームウェアは、引き続きプロプライエタリです。(NVIDIA Developer)

1. Linuxディストリビューションとの統合を容易にするため

従来、NVIDIAのプロプライエタリカーネルモジュールは、Linuxカーネルとは別にビルド、署名、配布する必要がありました。カーネル更新のたびにモジュールを再ビルドするDKMSベースのワークフローでは、以下のような問題が一般的でした。

  • カーネル更新後にカーネルモジュールがビルドに失敗する
  • Secure Bootにより署名されていないモジュールがブロックされる
  • Linuxディストリビューションが公式パッケージとしてドライバーを維持するのが困難
  • カスタムカーネルやクラウド環境との統合が複雑化

ソースコードを公開することで、Ubuntu、Red Hat、SUSEなどのディストリビューションは、NVIDIAのカーネルモジュールを自社のパッケージング、署名、更新インフラに容易に統合できるようになります。NVIDIA自身も、より緊密なOS統合と署名・配布の簡素化を主要な動機として挙げています。(NVIDIA Developer)

2. デバッグとセキュリティレビューの改善のため

カーネルモジュールは、メモリ管理、割り込み、プロセス間同期、PCI Express、ディスプレイサブシステムなど、オペレーティングシステムの深部と相互作用します。

ソースコードが利用可能になることで、Linuxディストリビューションの開発者やエンタープライズユーザーは以下が可能になります。

  • カーネル内で実行が停止する場所を追跡する
  • GPUイベントとワークロードの相互作用を分析する
  • カスタムカーネルとの非互換性を修正する
  • セキュリティ関連の問題をレビューする
  • NVIDIAにパッチを提出する

NVIDIAは、コミュニティとパートナーによるレビューにより、ドライバーの品質とセキュリティの両方が向上すると述べています。(NVIDIA Developer)

3. 機能がGSPに移行したため

重要な技術的転換点はGSP（GPU System Processor）です。

従来、GPU制御ロジックの多くはホストCPUのカーネルドライバー内で実行されていました。しかし、新しいGPUでは、内部のGSPファームウェアがハードウェアの初期化や管理などの重要なタスクを実行するようになりました。

概念的には、アーキテクチャは以下のように変化しました。

Previous:

Linux kernel module
        ↓ Direct low-level hardware control
GPU

Current:

Linux kernel module
        ↓ Commands / RPC
GSP firmware
        ↓
GPU hardware

Enter fullscreen mode Exit fullscreen mode

これにより、ハードウェア固有の複雑さや機密性の高い実装の詳細は署名済みファームウェア内に留め、Linux向けのカーネルインターフェースのみを公開することが可能になりました。NVIDIAは、最初のオープンソースカーネルモジュールを実現した技術的基盤として、GSPドライバーアーキテクチャの段階的な採用を明確に位置づけています。(NVIDIA Developer)

つまり、NVIDIAは単に企業方針を変更したのではなく、カーネル向け部分をオープンソースとして公開できるように事前にドライバーアーキテクチャを再設計していたのです。

4. AI、クラウド、データセンターの展開を簡素化するため

今日、NVIDIA GPUはデスクトップシステムだけでなく、以下のような環境でも使用されています。

  • Kubernetesクラスタ
  • AIトレーニングサーバー
  • クラウド仮想マシン
  • Grace Hopperシステム
  • Confidential Computing環境
  • 統合メモリアーキテクチャ

これらの環境では、GPUドライバーをOSイメージやコンテナプラットフォームに自動的かつ安全に統合することが不可欠です。

オープンカーネルモジュールは、HMM、Confidential Computing、Graceプラットフォーム上のコヒーレントメモリなどの技術に対するサポートも導入しました。Grace HopperやBlackwellを含む一部の新しいプラットフォームでは、オープンカーネルモジュールが必須となっています。(NVIDIA Developer)

これにより、NVIDIAはLinux上でのAIおよびクラウドインフラ展開の運用コストを削減するという明確なビジネス上の利点を得ています。

5. Nouveauを含むLinuxエコシステムとのより良い協力

ソースコードの公開とGSPファームウェアの導入により、Linuxエコシステムに含まれるオープンソースNVIDIAドライバーであるNouveauの改善も容易になりました。特に電力管理やクロック管理などの機能においてその効果が期待されます。

NVIDIAは、公開されたコードをNouveau開発者がリファレンスとして利用でき、同じGSPファームウェアも利用可能であると説明しています。(NVIDIA Developer)

ただし、NVIDIAのオープンカーネルモジュールはLinuxカーネルのアップストリームに完全にマージされていません。NVIDIAは、ドライバーのコードベースが複数のオペレーティングシステムで共有されており、現在Linuxカーネルのアップストリームコーディング規約に適合していないため、直接の取り込みが困難であると説明しています。(NVIDIA Developer)

なぜ「MIT/GPL」でデュアルライセンスされているのか？

MIT/GPLという表記は、コードがデュアルライセンスされており、GPLv2またはMIT Licenseのいずれかの下で使用可能であることを意味します。(NVIDIA Docs)

大まかな目的は以下の通りです。

  • GPLv2: Linuxカーネルのライセンスモデルとの互換性を確保する。
  • MIT: より許容度の高い再利用、移植、再配布を可能にする。

NVIDIAはコードベースの一部をLinux、他のオペレーティングシステム、複数のGPUファミリー、Jetsonプラットフォーム間で共有しているため、GPLに加えてMITオプションを設けることは実用的な選択です。ただし、NVIDIAはこれが唯一の動機であると公式に述べているわけではなく、この結論は公開されているコード構造とライセンスモデルから推測されるものです。(NVIDIA Developer)

要約

NVIDIAが突然、企業全体の方針としてすべてをオープンソース化するようになったわけではなく、実際のアプローチは以下のように要約するのが適切です。

GPUのハードウェア制御をGSPファームウェアに移行し、Linuxカーネルインターフェース部分のみをオープンソース化することで、配布、署名、保守、クラウド展開を簡素化しつつ、GPUのコアとなる知的財産はプロプライエタリに保つ。

前述の質問に関して、NVIDIAの現在の公式方針は、Turing世代以降の対応GPUではオープンGPUカーネルモジュールがデフォルトかつ推奨オプションであるというものです。これはR560ドライバーシリーズからデフォルトとなりました。Maxwell、Pascal、Volta GPUでは、依然としてプロプライエタリドライバーが必要です。(NVIDIA Developer)

NVIDIAがGPL系のモジュールを提供するようになった最大の理由は、Linuxとの統合・配布・保守を容易にしつつ、GPUの重要な知的財産はファームウェアやユーザー空間に残せる技術構成が整ったからです。

なお、正確には「NVIDIAドライバー全体をGPL化した」のではありません。オープンになったのは主に以下のLinuxカーネルモジュールです。

  • nvidia.ko
  • nvidia-drm.ko
  • nvidia-uvm.ko
  • nvidia-modeset.ko

CUDA、OpenGL、Vulkanなどのユーザー空間コンポーネントとGSPファームウェアは、引き続きプロプライエタリです。(NVIDIA Developer)

1. Linuxディストリビューションに組み込みやすくするため

従来のプロプライエタリモジュールは、Linuxカーネルとは別にビルド・署名・配布する必要がありました。カーネル更新のたびにDKMSで再ビルドする構成では、以下が問題になりやすくなります。

  • カーネル更新後にモジュールがビルドできない
  • Secure Bootで署名されていないモジュールをロードできない
  • ディストリビューション側が正式パッケージとして管理しにくい
  • カスタムカーネルやクラウド環境への組み込みが複雑

ソースを公開することで、Ubuntu、Red Hat、SUSEなどがNVIDIAモジュールを自分たちのパッケージング、署名、更新機構に統合しやすくなりました。NVIDIA自身も「OSとのより緊密な統合」「署名と配布の容易化」を目的として挙げています。(NVIDIA Developer)

2. 障害解析とセキュリティレビューを改善するため

カーネルモジュールは、メモリ管理、割り込み、プロセス間同期、PCI Express、ディスプレイなど、OSの深い部分に関わります。

ソースが見えることで、ディストリビューション開発者や企業ユーザーは、次のような調査が可能になります。

  • カーネル内のどこで停止しているか追跡する
  • GPUイベントとワークロードの相互作用を解析する
  • カスタムカーネルとの非互換性を修正する
  • セキュリティ上の問題をレビューする
  • パッチをNVIDIAに提案する

NVIDIAは、コミュニティやパートナーからのレビューによってドライバーの品質とセキュリティを改善できると説明しています。(NVIDIA Developer)

3. GSPへの機能移動で、公開しやすくなったため

技術的な転換点が GSP（GPU System Processor） です。

以前は、GPU制御の多くをホストCPU上のカーネルドライバーが実行していました。しかし新しいGPUでは、GPU内部のGSPファームウェアが、初期化やハードウェア管理などの重要な処理を担当する構成へ移行しました。

概念的には次のような変化です。

従来:
Linuxカーネルモジュール
    ↓ ハードウェアを直接細かく制御
GPU

現在:
Linuxカーネルモジュール
    ↓ コマンド／RPC
GSPファームウェア
    ↓
GPUハードウェア

Enter fullscreen mode Exit fullscreen mode

これにより、ハードウェア固有の複雑な制御や機密性の高い部分を署名済みファームウェア側に置きながら、Linuxと接続するカーネル側を公開しやすくなりました。NVIDIAも、最初のオープンモジュールが実現した技術的背景としてGSPドライバーアーキテクチャの段階的導入を明示しています。(NVIDIA Developer)

つまり、単に方針を変えたのではなく、ソース公開可能なドライバー構造へ事前に設計変更していたということです。

4. AI・クラウド・データセンター運用を簡単にするため

NVIDIAのGPUは現在、デスクトップ用途だけでなく、以下の環境で大量に使われます。

  • Kubernetesクラスタ
  • AI学習サーバー
  • クラウドVM
  • Grace Hopperシステム
  • Confidential Computing
  • 統合メモリアーキテクチャ

このような環境では、GPUドライバーをOSイメージやコンテナ基盤に自動的かつ安全に組み込めることが重要です。

オープンモジュールでは、HMM、Confidential Computing、Graceプラットフォームのコヒーレントメモリなど、新しい機能も実装されました。Grace HopperやBlackwellなど、一部の新しいプラットフォームではオープンカーネルモジュールが必須になっています。(NVIDIA Developer)

これは、Linux上のAI・クラウド展開における運用コストを下げるという、NVIDIAにとって明確な事業上の利点があります。

5. NouveauなどLinux側との協調

ソース公開とGSPファームウェアの利用によって、Linuxカーネル内のオープンソースドライバーであるNouveauも、電力管理やクロック管理などの機能を改善しやすくなりました。

NVIDIAは、公開コードをNouveau改善の参考にでき、Nouveauからも同じGSPファームウェアを利用できると説明しています。(NVIDIA Developer)

ただし、NVIDIAの公開モジュールそのものがLinuxカーネル本体に完全統合されたわけではありません。NVIDIAは、コードベースが複数OSで共有されており、Linuxカーネルの設計慣例に適合していないため、そのままではupstreamに入れられないと説明しています。(NVIDIA Developer)

なぜ「MIT/GPL」のデュアルライセンスなのか

表示される MIT/GPL は、GPLv2またはMITライセンスの条件で利用できるデュアルライセンスです。(NVIDIA Docs)

大まかな役割は次のとおりです。

  • GPLv2：Linuxカーネルのライセンス体系との親和性を確保する
  • MIT：より制約の少ない再利用、移植、再配布を可能にする

NVIDIAのコードはLinuxだけでなく、複数のOS、GPU、Jetson向けに共有されているため、GPLだけに限定せずMITも選択可能にすることには合理性があります。ただし、この部分はNVIDIAが公式に単一の動機として説明したものではなく、公開されているコード構成とライセンス方式からの推論です。(NVIDIA Developer)

要するに

NVIDIAが急に「すべてをオープンソースにする企業方針」へ変わったというより、

GSPファームウェアにハードウェア制御を移し、Linuxとの接点となるカーネル部分を公開することで、配布・署名・保守・クラウド展開を容易にした

というのが実態に近いです。

なお、前の質問に関しては、現在のNVIDIA公式方針では、Turing以降の対応GPUではオープンカーネルモジュールがデフォルトかつ推奨です。R560系列以降、この方針に移行しています。Maxwell、Pascal、Voltaではプロプライエタリ版が必要です。(NVIDIA Developer)