Mojo's compiler goes Apache 2.0 while MAX stays source-available

On August 18, 2026, Modular released the entire Mojo compiler and toolchain under the Apache 2.0 license with LLVM exceptions. This closes a gap that had been open since the language's first public release: the standard library was open-sourced in 2024, hundreds of thousands of lines of MAX kernel code written in Mojo followed in 2025, but the compiler itself stayed closed. Modular is now owned by Qualcomm, which completed its acquisition on July 29, 2026, so the newly open compiler ships under Qualcomm's ownership.

The license choice is the part that changes an engineering decision. Apache 2.0 with the LLVM exceptions is the same arrangement LLVM itself uses, and Modular calls out the specific reason: the exceptions expand your freedom to build and distribute binaries compiled from Mojo source. If you were holding off on Mojo because the compiler was a closed dependency you could not audit, fork or retarget, that objection is gone.

What the announcement does not do is make the whole stack Apache 2.0. MAX is a separate matter, and the boundary between the two is where the practical answers live for anyone who wants to write a custom kernel and ship it.

All Mojo language code is in the main modular GitHub repository. Modular's stated scope is the compiler, the tooling, and everything else you need to build the language. The build is Bazel-driven, and a single command bootstraps the compiler and standard library from source and runs a file through it.

If you are not modifying the compiler, --config=prebuilt-mojo swaps the from-source build for the latest nightly binary distribution and saves the compile time. That is the path most application developers will take. The from-source path matters for anyone who wants to extend the language or bring it to a new platform, which Modular explicitly names as a use case for the permissive license.

Mojo's stated purpose is unlocking GPUs, AI accelerators and other advanced compute, and there is production evidence that the kernel workflow is real. Modular serves MiniMax's M3 on a dedicated deployment at billions of tokens per minute, and getting there required implementing M3 natively in MAX and building and tuning specialized kernels for MiniMax Sparse Attention, the model's sparse-attention scheme that selectively attends to relevant KV blocks. That is a custom attention kernel written for a novel architecture and put into production serving.

The constraint sits one layer down. Modular states plainly that a prebuilt Mojo compiler is still necessary today if you are customizing MAX kernels or models. So the fully self-hosted story — build the compiler from source, then use that compiler for your kernel work — does not yet hold for MAX. You can read the compiler source, and you can read the kernel source released in 2025, but the toolchain you actually point at MAX kernels is still a binary Modular ships.

MAX's licensing moved too, in a smaller step. The MAX license no longer contains device usage restrictions, and MAX is becoming source-available with an open alliance program. Source-available is not Apache 2.0, and the announcement does not spell out what the alliance program requires of participants or what the resulting license permits. Treat MAX as a dependency whose terms you need to read, not as an open-source component.

Modular Cloud is already serving production workloads on both NVIDIA and AMD GPUs, and the platform has added AWS Trainium, Google TPUs, Qualcomm Cloud AI 100 Ultra and Qualcomm Dragonfly. All of them run through the same Modular Platform with the same modeling APIs, serving workflows, programming language and core abstractions, which is the portability claim: author a model once and move it to a different architecture without rebuilding the stack around it. Modular says each bringup took more than a 10x reduction in engineering effort versus what enabling new AI hardware traditionally requires.

Two caveats belong next to that. The new accelerator targets are not in production yet; Modular says it will be bringing them into production over the coming months. And the announcements do not enumerate what proprietary vendor components remain underneath — nothing in either post describes the driver or runtime layer any of these backends sit on, so the question of what NVIDIA-specific software is still required to run a Mojo GPU kernel is not answered by these sources.

Contributions are the clearest remaining gate. The standard library has accepted contributions since 2024, but the compiler and tooling do not.

Modular attributes the caution partly to the era of AI coding and the need to be deliberate about how contributions are handled. Practically, that means you can fork the compiler today but you cannot upstream to it, and a fork you maintain against a repository that does not take patches is a maintenance cost you own alone until that changes.

Platform coverage has a gap too. Mojo has supported macOS and Linux for years and Windows developers have used it through WSL. Native Windows support is coming through a collaboration with the Microsoft Windows team, with a quote from Windows CVP Logan Iyer in the announcement, but no ship date is given. If your team develops on Windows, WSL remains the path.

The honest summary for a team deciding today: the language is a safe dependency, with a 1.0 source-stability guarantee and a permissive license on the compiler. The serving layer above it is not open on the same terms, and the answer to whether you can write a GPU kernel entirely on open, buildable tooling is currently no — not because the kernel language is closed, but because MAX kernel work still routes through a compiler binary you did not build.