NVIDIA 開始提供 GPL 授權的核心模組，最主要的原因是其驅動程式架構已發展到足以大幅簡化 Linux 整合、發行與維護流程，同時仍將 GPU 的關鍵智慧財產保留在韌體與使用者空間元件中。

確切來說，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 本身也指出，更緊密的作業系統整合以及更簡單的簽署與發行是主要動機。（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 驅動程式自動且安全地整合至作業系統映像檔與容器平台至關重要。

開放核心模組也引進對 HMM、Confidential Computing 以及 Grace 平台上相干記憶體等技術的支援。在 Grace Hopper 與 Blackwell 等部分新平台上，開放核心模組是強制性的。（NVIDIA Developer）

這讓 NVIDIA 得以透過降低在 Linux 上部署 AI 與雲端基礎架構的營運成本，獲得明確的商業優勢。

5. 與 Linux 生態系統（包含 Nouveau）更佳的協作

原始碼的釋出加上 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 突然採取公司全面開放原始碼的政策，不如說其實際做法更適合以下描述：

透過將硬體控制移至 GSP 韌體，並開放面向 Linux 的核心介面，NVIDIA 簡化了發行、簽署、維護與雲端部署，同時保留其核心 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)