AIREITERModular 打造、帶有 Python 語感的系統程式語言 Mojo，已在 2026 年 8 月 18 日全面開源。編譯器、工具鏈，以及建置這門語言所需的原始碼，如今都採用附 LLVM 例外條款的 Apache 2.0 授權。不過，「全面開源」並不代表所有限制都消失：Modular 預計在 2026 年底前仍不接受編譯器 Pull Request，而 GPU 服務堆疊也仍依賴個別授權的預先建置元件。以下拆解實際邊界，協助你判斷 Mojo 目前適不適合作為專案基礎。
Mojo 如何走向開源：從 2024 年開始的三個階段
Mojo language 並非一夕之間改為開源。由 LLVM 與 Swift 創作者 Chris Lattner 創立的 Modular，花了兩年多分階段釋出內容：先公開標準函式庫與 kernel 程式碼，最後才釋出編譯器。
| 日期 | 開放內容 | 外部 PR |
|---|---|---|
| 2024 年 3 月 | 標準函式庫，採附 LLVM 例外條款的 Apache 2.0 | 接受 |
| 2024–2025 年 | Mojo GPU/CPU kernels；Modular 表示截至 2025 年 5 月已有 450,000+ 行程式碼 | 接受 |
| 2026 年 8 月 11 日 | Mojo 1.0.0 穩定版；語言採用語意化版本控制，每六週發布一次 | - |
| 2026 年 8 月 18 日 | 編譯器、工具鏈與建置原始碼，在 ModCon 宣布 | 凍結至 2026 年底 |
查閱資料時要留意時效。2026 年 8 月 18 日以前的來源，往往仍將編譯器描述為封閉元件。例如，Mojo 的 Wikipedia 條目在 2026 年 8 月 12 日的版本中，仍將編譯器列為專有的 Modular Community License 授權；距離開源發布僅差六天。
Apache 2.0 加上 LLVM 例外條款，實際給了你什麼權利？
儲存庫內的LICENSE 檔案採用與 LLVM 相同的寬鬆授權範本。兩項 LLVM 例外條款不只是法律文字，而是會直接影響你的交付方式。
Apache 2.0 作為基礎授權，提供商業使用者完整的常見權利：可重製、修改、再授權，也可用原始碼或物件碼形式散布；每位貢獻者還會提供明確的專利授權。只有當你提告主張該作品侵害你的專利時，這項專利授權才會終止。一般而言，重新散布時仍須附上授權副本、標示修改內容，並保留 NOTICE 檔案，詳見第 4 節。
LLVM 例外條款則額外豁免了兩種情況：
- 內嵌的物件碼。 當編譯你的程式碼時，部分 Mojo 內容被內嵌至編譯產物，便可免除第 4(a)、4(b) 與 4(d) 節要求；換言之，不必隨每個由 Mojo 編譯器產生的二進位檔附上 Apache 授權文字。
- 與 GPLv2 的組合。 若你將 Mojo 編譯後的形式與 GPLv2 程式碼結合，且法院認定 Apache 的專利或賠償條款與 GPLv2 衝突，該組合作品可豁免衝突的條文。
但這份授權沒有給你的東西，包括商標權，例如 Mojo 與 Modular 名稱，也不提供保固或責任保護。此外，儲存庫原始碼只涵蓋授權全貌的一半；依儲存庫 README 說明，MAX、Mojo 與 Modular 的使用和散布，另受 Modular Community License 規範。
哪些已開放、哪些仍在儲存庫之外？
「全面開源」在 modular/modular 儲存庫中的涵蓋範圍如下。截至 2026 年 8 月 19 日，該儲存庫有 53,617 次 commit、26.9k stars 與 2.9k forks；而下表也列出仍不在其中的部分。
| 元件 | 位置 | 狀態 |
|---|---|---|
| Mojo 編譯器 | /KGEN 目錄 | 自 2026 年 8 月 18 日開源；PR 仍凍結 |
| 標準函式庫 | /mojo/stdlib | 自 2024 年 3 月開源；接受 PR |
| MAX GPU/CPU kernels | /max/kernels | 開源；接受貢獻 |
| 推論伺服器、模型管線 | /max/python/max/serve、/max/pipelines | 開源 |
| MAX 預先建置的平台版本 | 於儲存庫外散布 | Modular Community License |
| MAX kernel／模型客製化流程 | - | 仍須使用預先建置的 Mojo 編譯器二進位檔 |
最後一列不是社群猜測，而是 Modular 自己的說法。其8 月 18 日公告明確指出，客製化 MAX kernels 或模型時，預先建置的編譯器「仍然必要」。對鎖定 GPU 的 AI 工程師而言，這正是開源元件與授權元件目前交界之處，也是發布當天使用者最主要的質疑點。r/ProgrammingLanguages 公告討論串中的 u/benreynwar 寫道：
「看起來要編譯到 GPU，仍有很多必需的東西沒有開源。」－u/benreynwar，r/ProgrammingLanguages
若要在本機建置 CPU 版本，官方已有文件化流程：clone、以 Bazel 建置、執行。至於 GPU kernel 與模型客製化，則會碰上預先建置編譯器的相依性。
貢獻規則很清楚：標準函式庫可以，編譯器要等到 2026 年底
開源不等於開放治理，而 Mojo 目前只有前者。公告文章說得直接：「我們還沒準備好接受對編譯器與工具鏈的貢獻」，目標是在 2026 年底前開始接受。
標準函式庫的情況則不同。它自 2024 年起便接受外部貢獻；到 Mojo 1.0 發布當天，Modular 表示已有近 200 位貢獻者的 PR 被合併，超過 1,100 個 PR 修改了 200,000+ 行程式碼。至於編譯器與工具鏈 PR，目前仍不接受。
你可以自行驗證原始碼是否可建置：
git clone https://github.com/modular/modular.git
cd modular
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo
./bazelw test --config=build-mojo mojo/stdlib/test/...--config=build-mojo 會從本機 checkout 編譯編譯器；--config=prebuilt-mojo 則改為下載 nightly 二進位檔，公告中已有說明。在 fork 之前，還有幾件事值得知道：main 分支追蹤 nightly builds、穩定版本每六週發布，而且在編譯器貢獻尚未開放期間，Modular 仍保有維護者控制權。正如 r/programming 討論串中的 u/Fidodo 所說：
「開源不代表由社群治理。哪些內容能被合併，最終仍由維護者決定。」－u/Fidodo，r/programming
Python 互通性：能用的路徑與踩雷點
官方首頁展示了可行的一端：建立 40 個 Float64 值，交給 NumPy，再用 Matplotlib 繪圖並儲存成 plot.png，全程都由 Mojo 執行。目前有兩條確實可行的互通路徑：Mojo 可透過 CPython runtime 匯入 Python 模組；而 Python 也能透過與 C 相容的 bindings 呼叫 Mojo 函式。後者尤其值得 AI 工程師關注：把效能熱點 kernel 寫成 Mojo，訓練與服務程式仍留在 Python。
真正不成立的，是 Mojo 在 2023 年推出時所塑造的「Python 超集」說法。現況如下：
- Mojo 不與 Python 3 原始碼相容，Python 程式碼無法原封不動執行。
- 官方 roadmap如今寫明，Mojo「可能會，也可能不會演進為 Python 的完整超集」；Phase 1 也明確略過無型別的 Python 風格程式碼與 Python 函式庫對等性。
- Mojo沒有 Python 的 class 系統，而是採用帶 traits 的 structs，物件模型不同。
- classes、繼承與無型別變數位於 roadmap 的 Phase 3，目前尚未開始；Phase 2 的工具鏈與封裝功能正在進行中。
- 即使已進入 1.0，除非明確標示為 stable，標準函式庫 API 仍不穩定。
實際嘗試遷移的使用者，說法比文件更直白。r/MojoLang 的 Mojo 現況討論串中寫道：
「支援 Python 作為超類，離實現還非常遠。」－u/newtestdrive，r/MojoLang
「它絕對還不是 Python 的超集。」－@eatonphil，X
同一位 u/newtestdrive 也表示，把 Python 腳本轉成 Mojo「會傷害可讀性，有時甚至無法轉換」。Modular 的官方 FAQ建議三種遷移方式：先了解文件列出的 Python 與 Mojo 差異、使用 Mojo AI skills 協助翻譯，或從既有 Python 程式中逐步暴露 Mojo bindings。比較務實的定位是：它是一門帶有 Python 語感的 kernel 語言，而不是 Python 的替代品。
Mojo 目前在 AI 技術堆疊中的位置
GPU 效能已有獨立證據可參考。Oak Ridge National Laboratory 的研究在 SC25 WACCPD workshop 發表，並在該活動獲得最佳論文。研究以 NVIDIA H100 與 AMD MI300A，將 seven-point stencil、BabelStream、miniBUDE 與 Hartree-Fock 四種 kernels 與 CUDA、HIP 比較。Mojo 在記憶體受限工作負載上的表現整體具競爭力；但在大量使用 atomics，以及採用 fast-math 的運算受限案例中，仍有明顯差距。
| 你的工作負載 | 建議 |
|---|---|
| 撰寫可攜式 GPU/CPU kernels | 值得試點導入：ORNL 資料支持記憶體受限場景可與對手並駕齊驅；大量 atomics 的 AMD 程式碼則應先做 benchmark |
| 在 MAX 上進行正式環境模型服務 | 先閱讀 Modular Community License 條款；仍有預先建置二進位檔相依性 |
| 取代一般 Python 應用程式碼 | 不建議：Phase 3 尚未完成、不與原始碼相容，且套件管理尚未開始 |
| 學習加速器程式設計 | 可以：原始碼易讀、可本機建置，並有含 LSP 與偵錯器的 VS Code extension |
平台規劃也要納入考量：Mojo 原生支援 Linux 與 macOS，Windows 僅能透過 WSL 執行。至於SDK telemetry 政策，蒐集項目包括基本系統資訊、當機報告與彙總後的 LSP 時間資料，不會傳送原始碼。
FAQ
Mojo 現在已經完全開源了嗎？
是。自 2026 年 8 月 18 日起，編譯器、工具鏈、標準函式庫與建置原始碼都位於 modular/modular GitHub 儲存庫，採附 LLVM 例外條款的 Apache 2.0 授權。不過，MAX 預先建置的平台版本仍採另一份 Modular Community License。
Mojo 使用什麼授權？
儲存庫原始碼與貢獻採 Apache License 2.0 加 LLVM 例外條款；MAX 平台的使用與散布則另受 Modular Community License 規範。
我可以貢獻 Mojo 編譯器嗎？
目前還不行。標準函式庫、MAX kernels、範例與文件接受外部 PR；自 2024 年以來，約有 200 位貢獻者的 PR 被合併。但編譯器與工具鏈 PR 仍凍結，直到 Modular 所訂的 2026 年底目標。
Mojo 與 Python 相容嗎？
部分相容。Mojo 可經由 CPython runtime 匯入 Python 模組，也能提供與 C 相容的 bindings 讓 Python 呼叫；但它不與 Python 3 原始碼相容、沒有 classes，且其 roadmap 也表示它「可能會，也可能不會」成為完整超集。
從現在到 2027 年，值得持續觀察的事
有三個帶明確時間或路線圖意義的觀察點，將決定這次發布能否發展成社群參與的專案：2026 年底開始接受編譯器與工具鏈貢獻的目標、roadmap 的 Phase 3，也就是 classes、繼承與無型別變數，任何嚴肅的 Python 相容性都會在此出現，以及 1.0 後語意化版本控制政策下，標準函式庫 API 會以多快速度標示為 stable。