AIREITERMojo - the Python-flavored systems language from Modular - became fully open source on August 18, 2026: compiler, tooling, and the source needed to build the language, all under Apache 2.0 with LLVM exceptions. Two limits survive that headline. Compiler pull requests stay frozen until Modular's end-of-2026 target, and the GPU serving stack still leans on separately licensed prebuilt pieces. This guide maps the exact boundary so you can decide what Mojo is safe to build on today.
How the Mojo language went open source: three waves since 2024
The Mojo language did not flip a single open-source switch. Modular, founded by Chris Lattner (creator of LLVM and Swift), staged the release across more than two years: the standard library and kernel code went public first, the compiler last.
| Date | What opened | External PRs |
|---|---|---|
| March 2024 | Standard library, Apache 2.0 with LLVM exceptions | Accepted |
| 2024–2025 | Mojo GPU/CPU kernels, 450,000+ LOC reported by Modular as of May 2025 | Accepted |
| August 11, 2026 | Mojo 1.0.0 stable - semver for the language, six-week release cadence | - |
| August 18, 2026 | Compiler, tooling, and build source (announced at ModCon) | Frozen until end of 2026 |
A freshness caution: sources older than August 18, 2026 routinely describe the compiler as closed. The Mojo Wikipedia article, for example, still listed the compiler under the proprietary Modular Community License as of its August 12, 2026 edit, six days before the release.
What Apache 2.0 with LLVM exceptions actually grants
The repo's LICENSE file is the same permissive template LLVM itself uses, and the two LLVM exceptions are not legal boilerplate - they change what you can ship.
Apache 2.0 as the base gives commercial users the standard package: reproduce, modify, sublicense, and distribute in source or object form, plus an explicit patent grant from every contributor, terminating only if you sue claiming the work infringes your patents. Redistribution normally requires license copies, modification notices, and NOTICE-file preservation (Section 4).
The LLVM exceptions then carve out two waivers:
- Embedded object code. When compiling your code causes parts of Mojo to be embedded in your compiled artifacts, Sections 4(a), 4(b), and 4(d) are waived - you do not ship Apache license text with every binary the Mojo compiler produces.
- GPLv2 combinations. If you combine Mojo-compiled forms with GPLv2 code and a court finds Apache's patent or indemnity clauses conflict with GPLv2, the conflicting sections can be waived for that combined work.
What the license does not grant: trademarks (the Mojo and Modular names), warranty, or liability protection. And repo source is only half the licensing picture - MAX, Mojo, and Modular usage and distribution are separately governed by the Modular Community License, per the repo's own README.
The open-vs-closed map, component by component
Here is what "fully open source" covers in the modular/modular repository - 53,617 commits, 26.9k stars, and 2.9k forks as of August 19, 2026 - and what still sits outside it.
| Component | Location | Status |
|---|---|---|
| Mojo compiler | /KGEN directory | Open since Aug 18, 2026; PRs frozen |
| Standard library | /mojo/stdlib | Open since March 2024; PRs accepted |
| MAX GPU/CPU kernels | /max/kernels | Open; contributions accepted |
| Inference server, model pipelines | /max/python/max/serve, /max/pipelines | Open |
| MAX prebuilt platform builds | Distributed outside the repo | Modular Community License |
| MAX kernel/model customization workflow | - | Still requires a prebuilt Mojo compiler binary |
That last row is Modular's own admission, not community speculation: the August 18 announcement states a prebuilt compiler "remains necessary" when customizing MAX kernels or models. For AI engineers targeting GPUs, this is where the open source and licensed components currently meet, and it is exactly where users pushed back on launch day. u/benreynwar wrote in the r/ProgrammingLanguages announcement thread:
"It seems like there is still lots of stuff that is not open-sourced that you need to compile to GPU." - u/benreynwar, r/ProgrammingLanguages
A local CPU build is the documented path: clone, build with Bazel, run. GPU kernel and model customization is where the prebuilt-compiler dependency kicks in.
The contribution freeze: stdlib yes, compiler no until end of 2026
Open source and open governance are different things, and Mojo currently has only the first. The announcement post is direct: "we aren't ready to take contributions to the compiler and tooling," with a stated target of accepting them by the end of 2026.
The standard library is a different story. It has taken outside contributions since 2024, and by Mojo 1.0 day, Modular reported nearly 200 contributors with merged pull requests - 1,100+ PRs changing 200,000+ lines. Compiler and tooling PRs: not accepted.
Verify the source builds yourself:
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 compiles the compiler from your local checkout; --config=prebuilt-mojo downloads the nightly binary instead (per the announcement). Before you fork anything, also know that the main branch tracks nightly builds, stable releases land every six weeks, and Modular retains maintainer control while compiler contributions stay closed. As u/Fidodo put it in the r/programming thread:
"Open source doesn't mean community rule. Maintainers still have the final say on what gets merged in." - u/Fidodo, r/programming
Python interop: what works, what breaks
The official homepage shows the working direction: create 40 Float64 values, hand them to NumPy, plot with Matplotlib, save plot.png - all from Mojo. Two interop paths are real today: Mojo can import Python modules through the CPython runtime, and Python can call Mojo functions through C-compatible bindings. That second path is the one AI engineers should care about: write the hot kernel in Mojo, keep the training and serving code in Python.
What breaks is the "superset" framing Mojo launched with in 2023. Current reality:
- Mojo is not source-compatible with Python 3 - Python code does not run unchanged.
- The official roadmap now says Mojo "may or may not evolve into a full superset of Python," and Phase 1 explicitly skipped untyped Python-style code and Python library parity.
- Mojo has no Python class system - it has structs with traits, a different object model.
- Classes, inheritance, and untyped variables sit in Phase 3 of the roadmap, which is not started; Phase 2 (tooling, packaging) is in progress.
- Standard library APIs are unstable unless explicitly marked stable, even post-1.0.
Users who attempted the migration are blunter than the docs. From the r/MojoLang state-of-Mojo thread:
"Supporting Python as a superclass is still a long way off." - u/newtestdrive, r/MojoLang
"It is definitely not yet a superset of Python." - @eatonphil, X
The same u/newtestdrive reported that converting Python scripts "hurts readability and sometimes is not possible." Modular's own FAQ recommends three migration routes: learn the documented Python-to-Mojo differences, use Mojo AI skills for assistant-assisted translation, or expose Mojo bindings incrementally from existing Python code. Treat it as a kernel language with a Python accent, not a Python replacement.
Where Mojo fits in an AI stack today
Independent evidence on GPU performance exists: an Oak Ridge National Laboratory study presented at the SC25 WACCPD workshop (and awarded best paper there) benchmarked four kernels - seven-point stencil, BabelStream, miniBUDE, and Hartree-Fock - against CUDA and HIP on an NVIDIA H100 and an AMD MI300A. Mojo was broadly competitive on memory-bound workloads; atomic-heavy and fast-math compute-bound cases kept notable gaps.
| Your workload | Verdict |
|---|---|
| Writing portable GPU/CPU kernels | Pilot it - ORNL data supports memory-bound parity; atomics-heavy AMD code needs benchmarking first |
| Production model serving on MAX | Read the Modular Community License terms first; prebuilt binary dependency remains |
| Replacing general Python application code | No - Phase 3 incomplete, not source-compatible, package management not started |
| Learning accelerator programming | Yes - readable source, local builds, VS Code extension with LSP and debugger |
Platform notes for planning: Mojo runs natively on Linux and macOS, Windows only through WSL. The SDK's telemetry policy covers basic system info, crash reports, and aggregate LSP timing - no source code transmitted.
FAQ
Is the Mojo language fully open source now?
Yes. Since August 18, 2026, the compiler, tooling, standard library, and build source live in the modular/modular GitHub repo under Apache 2.0 with LLVM exceptions. MAX prebuilt platform builds remain under the separate Modular Community License.
What license is Mojo under?
Repository source and contributions use Apache License 2.0 with LLVM exceptions; usage and distribution of the MAX platform are governed separately by the Modular Community License.
Can I contribute to the Mojo compiler?
Not yet. Standard library, MAX kernels, examples, and documentation accept external PRs (since 2024, ~200 merged contributors); compiler and tooling PRs are frozen until Modular's stated end-of-2026 target.
Is Mojo compatible with Python?
Partially. Mojo imports Python modules via the CPython runtime and exposes C-compatible bindings for calling from Python, but it is not source-compatible with Python 3, has no classes, and its own roadmap says it "may or may not" become a full superset.
What to watch between now and 2027
Three dated checkpoints decide whether this release matures into a community-run project: the end-of-2026 target for accepting compiler and tooling contributions, Phase 3 of the roadmap (classes, inheritance, untyped variables - where any serious Python compatibility would appear), and how quickly standard library APIs get marked stable under the post-1.0 semver policy.