AIREITERModular 推出的 Python 风格系统编程语言 Mojo，已于 2026 年 8 月 18 日全面开源：编译器、工具链以及构建这门语言所需的源代码，均采用附 LLVM 例外条款的 Apache 2.0 许可证。不过，这并不意味着所有限制都已消失。Modular 计划在 2026 年底前继续冻结编译器相关的 pull request；GPU 推理服务栈也仍依赖采用独立许可证的预构建组件。本文将厘清开源边界，帮你判断现在是否适合将 Mojo 用于实际项目。
Mojo 的开源之路：从 2024 年到现在分三步完成
Mojo 语言并非在某一天突然“一键开源”。由 LLVM 与 Swift 创始人 Chris Lattner 创立的 Modular，用两年多时间逐步开放代码：先是标准库和内核代码，最后才轮到编译器。
| 日期 | 开放内容 | 外部 PR |
|---|---|---|
| 2024 年 3 月 | 标准库，采用附 LLVM 例外条款的 Apache 2.0 许可证 | 接受 |
| 2024–2025 年 | Mojo GPU/CPU 内核；Modular 报告称，截至 2025 年 5 月，代码量已超过 450,000 行 | 接受 |
| 2026 年 8 月 11 日 | Mojo 1.0.0 稳定版发布；语言采用 semver，并保持六周发布节奏 | - |
| 2026 年 8 月 18 日 | 编译器、工具链和构建源代码（在 ModCon 宣布） | 冻结至 2026 年底 |
查资料时要注意时效性：所有早于 2026 年 8 月 18 日的资料，通常都会将 Mojo 编译器描述为闭源。例如，Mojo 的 Wikipedia 词条在 2026 年 8 月 12 日的编辑版本中，仍将编译器列为采用专有的 Modular Community License；而六天后，它才正式开源。
附 LLVM 例外条款的 Apache 2.0，到底允许你做什么
仓库中的 LICENSE 文件采用与 LLVM 相同的宽松许可证模板。两项 LLVM 例外并非无关紧要的法律术语，而是会直接影响你如何发布软件。
基础的 Apache 2.0 许可证给予商业用户一套标准权利：可以复制、修改、再许可，并以源代码或目标代码形式分发；每位贡献者还会授予明确的专利许可。只有在你起诉对方、主张该作品侵犯你的专利时，这项专利授权才会终止。再分发时，通常仍需附带许可证副本、标注修改内容，并保留 NOTICE 文件中的声明（第 4 节）。
LLVM 例外条款则额外免除了两类要求：
- 嵌入式目标代码。 如果编译你的代码时，部分 Mojo 代码会被嵌入到产物中，那么 Apache 许可证第 4(a)、4(b) 和 4(d) 节不再适用——Mojo 编译器生成的每个二进制文件都不必附带 Apache 许可证文本。
- 与 GPLv2 代码组合。 如果将 Mojo 编译产物与 GPLv2 代码组合，而法院认定 Apache 的专利或赔偿条款与 GPLv2 冲突，则可针对该组合作品豁免冲突条款。
但这份许可证不会授予你 Mojo 和 Modular 名称的商标权，也不提供担保或责任保护。此外，仓库源代码只是许可证图景的一半：根据仓库 README，MAX、Mojo 和 Modular 的使用与分发另受 Modular Community License 约束。
哪些已开源，哪些仍在仓库之外
“完全开源”具体覆盖哪些内容？截至 2026 年 8 月 19 日，modular/modular 仓库拥有 53,617 次提交、26.9k stars 和 2.9k forks。下表列出了仓库内外的实际边界。
| 组件 | 位置 | 状态 |
|---|---|---|
| Mojo 编译器 | /KGEN 目录 | 自 2026 年 8 月 18 日起开源；PR 仍冻结 |
| 标准库 | /mojo/stdlib | 自 2024 年 3 月起开源；接受 PR |
| MAX GPU/CPU 内核 | /max/kernels | 开源；接受贡献 |
| 推理服务器、模型流水线 | /max/python/max/serve, /max/pipelines | 开源 |
| MAX 平台预构建版本 | 在仓库外部分发 | Modular Community License |
| MAX 内核/模型定制工作流 | - | 仍需要预构建的 Mojo 编译器二进制文件 |
最后一行并非社区猜测，而是 Modular 自己的说明：其8 月 18 日公告明确表示，定制 MAX 内核或模型时，预构建编译器“仍然是必需的”。对于面向 GPU 的 AI 工程师而言，这正是开源组件与受许可组件目前的交界处，也是发布当天用户最集中提出异议的地方。r/ProgrammingLanguages 公告帖中的 u/benreynwar 写道：
“看起来，要编译到 GPU，仍然需要很多没有开源的东西。”——u/benreynwar，r/ProgrammingLanguages
本地 CPU 构建则是文档明确支持的路径：克隆仓库、用 Bazel 构建、运行即可。只有在定制 GPU 内核和模型时，才会触发对预构建编译器的依赖。
贡献通道并未完全打开：标准库可以，编译器要等到 2026 年底
开源不等于开放治理，而 Mojo 目前只有前者。公告文章说得很直接：“我们尚未准备好接受对编译器和工具链的贡献。”Modular 给出的目标是在 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 会使用本地检出的代码编译编译器；--config=prebuilt-mojo 则会下载 nightly 二进制文件（公告中有说明）。在决定 fork 之前，还应知道：main 分支跟踪 nightly 构建，稳定版每六周发布一次；而在编译器贡献仍关闭期间，Modular 依然掌握维护者控制权。正如 r/programming 讨论帖中的 u/Fidodo 所说：
“开源不代表社区治理。哪些内容能合并，最终仍由维护者决定。”——u/Fidodo，r/programming
Python 互操作：能做什么，又会卡在哪里
官方网站展示了当前可行的方向：创建 40 个 Float64 值，交给 NumPy，再用 Matplotlib 绘图并保存为 plot.png——全过程都由 Mojo 完成。如今有两条真实可用的互操作路径：Mojo 可通过 CPython 运行时导入 Python 模块；而Python 也能通过 C 兼容绑定调用 Mojo 函数。对 AI 工程师而言，后者尤其值得关注：把性能热点内核写进 Mojo，训练和服务代码则继续留在 Python。
真正不成立的是 Mojo 在 2023 年发布时曾强调的“Python 超集”叙事。当前情况如下：
- Mojo 并不与 Python 3 源代码兼容，现有 Python 代码不能不经修改直接运行。
- 官方路线图如今表示，Mojo“可能会，也可能不会演进为 Python 的完整超集”；第一阶段明确跳过了无类型的 Python 风格代码和 Python 库兼容性。
- Mojo 没有 Python 的类系统，而是使用带 trait 的 struct，对象模型不同。
- 类、继承和无类型变量被放在路线图的第三阶段；该阶段尚未启动。第二阶段的工具链和打包功能仍在进行中。
- 即使在 1.0 之后，除非明确标为稳定，标准库 API 仍可能变化。
实际尝试迁移的用户，说法比文档更直白。r/MojoLang 的 Mojo 状态讨论帖中写道：
“将 Python 作为超类支持，仍然非常遥远。”——u/newtestdrive，r/MojoLang
“它显然还不是 Python 的超集。”——@eatonphil，X
同一位 u/newtestdrive 还表示，将 Python 脚本转换过来“会损害可读性，而且有时根本无法转换”。Modular 的官方 FAQ提供了三种迁移思路：学习文档列出的 Python 与 Mojo 差异；使用 Mojo AI skills 辅助翻译；或从已有 Python 代码中逐步暴露 Mojo 绑定。更合适的定位是：一门带有 Python 风格的内核语言，而不是 Python 的替代品。
Mojo 目前适合放在 AI 技术栈的什么位置
GPU 性能方面已有独立证据。橡树岭国家实验室的一项研究在 SC25 WACCPD workshop 发布，并获得该会议最佳论文。研究在 NVIDIA H100 和 AMD MI300A 上，将四类内核——七点 stencil、BabelStream、miniBUDE 和 Hartree-Fock——与 CUDA、HIP 进行了对比。对于内存受限型负载，Mojo 总体上具备竞争力；但在大量原子操作和启用 fast-math 的计算受限场景中，差距仍然明显。
| 你的工作负载 | 建议 |
|---|---|
| 编写可移植的 GPU/CPU 内核 | 值得试点——ORNL 数据支持其在内存受限负载上的同级表现；原子操作密集的 AMD 代码应先自行基准测试 |
| 在 MAX 上运行生产级模型服务 | 先阅读 Modular Community License 条款；对预构建二进制文件的依赖仍然存在 |
| 替换通用 Python 应用代码 | 不建议——第三阶段尚未完成，源码不兼容，且包管理尚未启动 |
| 学习加速器编程 | 可以——源码易读、可本地构建，并提供带 LSP 和调试器的 VS Code 扩展 |
平台规划还需注意：Mojo 原生支持 Linux 和 macOS，Windows 仅能通过 WSL 使用。至于隐私，SDK 的遥测政策涵盖基础系统信息、崩溃报告和 LSP 聚合耗时数据，不会传输源代码。
常见问题
Mojo 语言现在算完全开源了吗？
算。自 2026 年 8 月 18 日起，编译器、工具链、标准库和构建源代码均位于 modular/modular GitHub 仓库，采用附 LLVM 例外条款的 Apache 2.0 许可证。不过，MAX 平台的预构建版本仍采用独立的 Modular Community License。
Mojo 使用什么许可证？
仓库源代码及贡献采用附 LLVM 例外条款的 Apache License 2.0；MAX 平台的使用和分发则另受 Modular Community License 约束。
我可以为 Mojo 编译器贡献代码吗？
暂时不行。标准库、MAX 内核、示例和文档接受外部 PR；自 2024 年以来，已有约 200 名外部贡献者的 PR 被合并。但编译器和工具链 PR 将冻结至 Modular 设定的 2026 年底目标。
Mojo 与 Python 兼容吗？
部分兼容。Mojo 可以通过 CPython 运行时导入 Python 模块，也能通过 C 兼容绑定供 Python 调用；但它不与 Python 3 源代码兼容、没有类系统，且其路线图明确表示它“可能会，也可能不会”成为完整超集。
从现在到 2027 年，重点关注这三件事
这次发布能否发展成一个真正由社区参与的项目，取决于三个有明确时间线的节点：Modular 在 2026 年底前开放编译器和工具链贡献的目标；路线图第三阶段的推进情况——类、继承和无类型变量将在这一阶段出现，任何严肃的 Python 兼容性也会在此体现；以及在 1.0 后的 semver 政策下，标准库 API 被标记为稳定的速度。