Mojo als Open Source: Lizenz, Grenzen und die Python-Realität

Mojo, die von Modular entwickelte Systemprogrammiersprache mit Python-Anmutung, ist seit dem 18. August 2026 vollständig Open Source. Compiler, Werkzeuge und der Quellcode zum Bauen der Sprache stehen unter Apache 2.0 mit LLVM-Ausnahmen bereit. Ganz ohne Einschränkungen ist das aber nicht: Pull Requests für Compiler und Tooling bleiben bis zu Modulars Zieltermin Ende 2026 eingefroren. Zudem setzt der GPU-Serving-Stack weiterhin auf separat lizenzierte vorkompilierte Komponenten. Hier ist die genaue Trennlinie – damit klar wird, worauf sich mit Mojo heute schon verlässlich aufbauen lässt.

Mojo wurde seit 2024 in drei Etappen geöffnet

Die Programmiersprache Mojo wurde nicht mit einem einzigen Schalter Open Source. Modular, gegründet von Chris Lattner, dem Schöpfer von LLVM und Swift, veröffentlichte die Bestandteile über mehr als zwei Jahre hinweg. Den Anfang machten Standardbibliothek und Kernel-Code, der Compiler folgte zuletzt.

Wichtig bei älteren Quellen: Alles vor dem 18. August 2026 beschreibt den Compiler meist noch als geschlossen. Der Wikipedia-Artikel zu Mojo führte ihn in der Fassung vom 12. August 2026 beispielsweise noch unter der proprietären Modular Community License – sechs Tage vor der Veröffentlichung.

Was Apache 2.0 mit LLVM-Ausnahmen erlaubt

Die LICENSE-Datei des Repositories nutzt dasselbe freizügige Lizenzmodell wie LLVM selbst. Die beiden LLVM-Ausnahmen sind dabei mehr als juristisches Beiwerk: Sie beeinflussen unmittelbar, was sich ausliefern lässt.

Apache 2.0 liefert kommerziellen Nutzern das übliche Paket: Der Code darf reproduziert, verändert, unterlizenziert und als Quell- oder Objektcode weitergegeben werden. Hinzu kommt eine ausdrückliche Patentlizenz aller Mitwirkenden. Sie endet nur dann, wenn jemand klagt und behauptet, das Werk verletze eigene Patente. Bei der Weitergabe müssen normalerweise Lizenzkopien, Änderungshinweise und die NOTICE-Datei erhalten bleiben, wie es Abschnitt 4 vorsieht.

Die LLVM-Ausnahmen heben zwei dieser Anforderungen auf:

1. Eingebetteter Objektcode. Wenn beim Kompilieren eigener Programme Teile von Mojo im erzeugten Artefakt landen, entfallen die Abschnitte 4(a), 4(b) und 4(d). Nicht jeder mit dem Mojo-Compiler erzeugten Binärdatei muss also ein Apache-Lizenztext beigelegt werden.
2. Kombinationen mit GPLv2. Wird von Mojo erzeugter Code mit GPLv2-Code kombiniert und stellt ein Gericht fest, dass die Patent- oder Freistellungsklauseln von Apache mit GPLv2 kollidieren, können die widersprüchlichen Abschnitte für dieses Gesamtwerk ausgesetzt werden.

Was die Lizenz nicht einräumt: Markenrechte an den Namen Mojo und Modular, Garantien oder einen Haftungsausschluss. Außerdem ist der Repository-Code nur eine Seite der Lizenzlage. Nutzung und Distribution von MAX, Mojo und Modular unterliegen laut README des Repositories zusätzlich der Modular Community License.

Welche Komponenten offen sind – und welche nicht

„Vollständig Open Source“ bezieht sich auf das Repository modular/modular. Es zählte am 19. August 2026 53.617 Commits, 26,9k Stars und 2,9k Forks. Was darin steckt und was weiter außerhalb liegt, zeigt diese Übersicht.

Die letzte Zeile ist keine Vermutung der Community, sondern Modulars eigene Aussage. In der Ankündigung vom 18. August heißt es, ein vorkompilierter Compiler bleibe bei der Anpassung von MAX-Kerneln oder -Modellen „weiterhin notwendig“. Für KI-Entwickler, die GPUs ansteuern wollen, treffen genau dort aktuell Open-Source- und lizenzierte Komponenten aufeinander. Entsprechend kam an dem Tag auch Kritik auf. u/benreynwar schrieb im Ankündigungsthread von r/ProgrammingLanguages:

"Es scheint weiterhin vieles nicht Open Source zu sein, das man braucht, um für GPUs zu kompilieren." - u/benreynwar, r/ProgrammingLanguages

Für lokale CPU-Builds ist der dokumentierte Weg klar: klonen, mit Bazel bauen, ausführen. Erst bei der Anpassung von GPU-Kerneln und Modellen greift die Abhängigkeit vom vorkompilierten Compiler.

Beiträge ja – aber nicht zum Compiler vor Ende 2026

Open Source bedeutet nicht automatisch offene Projektsteuerung. Bei Mojo ist derzeit nur Ersteres gegeben. Der Ankündigungsbeitrag formuliert es eindeutig: „we aren't ready to take contributions to the compiler and tooling“. Externe Beiträge zu Compiler und Tooling sollen laut Zielsetzung bis Ende 2026 möglich werden.

Bei der Standardbibliothek sieht es anders aus. Sie nimmt seit 2024 externe Beiträge an. Zum Start von Mojo 1.0 berichtete Modular von fast 200 Mitwirkenden mit gemergten Pull Requests: mehr als 1.100 PRs mit Änderungen an über 200.000 Zeilen. Für Compiler und Tooling gilt das weiterhin nicht.

So lässt sich selbst prüfen, ob der Quellcode baut:

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 baut den Compiler aus dem lokalen Checkout. --config=prebuilt-mojo lädt stattdessen die Nightly-Binärdatei herunter, wie in der Ankündigung beschrieben. Vor einem Fork sollte außerdem klar sein: Der Branch main folgt den Nightly-Builds, stabile Releases erscheinen alle sechs Wochen, und Modular behält die Kontrolle als Maintainer, solange Compiler-Beiträge geschlossen bleiben. u/Fidodo fasste es im Thread von r/programming treffend zusammen:

"Open Source bedeutet nicht, dass die Community bestimmt. Maintainer entscheiden weiterhin letztlich, was gemergt wird." - u/Fidodo, r/programming

Python-Interop: Was funktioniert und wo die Grenzen liegen

Die offizielle Startseite demonstriert die funktionierende Richtung: 40 Float64-Werte erzeugen, an NumPy übergeben, mit Matplotlib plotten und als plot.png speichern – alles aus Mojo heraus. Aktuell gibt es zwei echte Interop-Wege: Mojo kann über die CPython-Runtime Python-Module importieren, und Python kann über C-kompatible Bindings Mojo-Funktionen aufrufen. Gerade Letzteres ist für KI-Entwickler relevant: den rechenintensiven Kernel in Mojo schreiben, während Training und Serving in Python bleiben.

Nicht mehr haltbar ist dagegen die „Superset“-Erzählung, mit der Mojo 2023 gestartet ist. Der aktuelle Stand:

• Mojo ist nicht quellcodekompatibel zu Python 3 – Python-Code läuft nicht unverändert.
• Die offizielle Roadmap erklärt inzwischen, Mojo könne sich „may or may not“ zu einem vollständigen Python-Superset entwickeln. Phase 1 ließ untypisierten Python-artigen Code und die Kompatibilität zu Python-Bibliotheken ausdrücklich aus.
• Mojo besitzt kein Python-Klassensystem, sondern Structs mit Traits – also ein anderes Objektmodell.
• Klassen, Vererbung und untypisierte Variablen stehen in Phase 3 der Roadmap. Diese Phase hat noch nicht begonnen; Phase 2 mit Tooling und Packaging läuft.
• APIs der Standardbibliothek bleiben instabil, sofern sie nicht ausdrücklich als stabil markiert sind – auch nach 1.0.

Nutzer, die eine Migration versucht haben, formulieren es noch direkter. Aus dem State-of-Mojo-Thread bei r/MojoLang:

"Die Unterstützung von Python als Oberklasse ist noch sehr weit entfernt." - u/newtestdrive, r/MojoLang

"Es ist definitiv noch kein Superset von Python." - @eatonphil, X

Auch u/newtestdrive berichtete, das Übertragen von Python-Skripten beeinträchtige „die Lesbarkeit und sei manchmal nicht möglich“. Modulars eigene FAQ empfiehlt drei Migrationswege: die dokumentierten Unterschiede zwischen Python und Mojo lernen, Mojo AI skills für assistierte Übersetzungen verwenden oder Mojo-Bindings schrittweise aus bestehendem Python-Code heraus anbinden. Mojo sollte derzeit als Kernel-Sprache mit Python-Akzent gelten, nicht als Python-Ersatz.

Wo Mojo heute in den KI-Stack passt

Unabhängige Daten zur GPU-Performance gibt es: Eine Studie des Oak Ridge National Laboratory, die beim SC25-WACCPD-Workshop vorgestellt und dort als Best Paper ausgezeichnet wurde, verglich vier Kernel – Seven-Point Stencil, BabelStream, miniBUDE und Hartree-Fock – mit CUDA und HIP auf einer NVIDIA H100 sowie einer AMD MI300A. Bei speichergebundenen Workloads war Mojo breit konkurrenzfähig. Bei atomics-lastigen und durch Fast Math rechengebundenen Fällen blieben jedoch deutliche Abstände.

Für die Plattformplanung: Mojo läuft nativ unter Linux und macOS, unter Windows nur über WSL. Die Telemetrie-Richtlinie des SDK umfasst grundlegende Systeminformationen, Absturzberichte und aggregierte LSP-Zeiten. Quellcode wird nicht übertragen.

FAQ

Ist die Programmiersprache Mojo jetzt vollständig Open Source?

Ja. Seit dem 18. August 2026 liegen Compiler, Tooling, Standardbibliothek und Build-Quellcode im GitHub-Repository modular/modular unter Apache 2.0 mit LLVM-Ausnahmen. Vorkompilierte MAX-Plattform-Builds unterliegen weiterhin der separaten Modular Community License.

Unter welcher Lizenz steht Mojo?

Repository-Quellcode und Beiträge stehen unter der Apache License 2.0 mit LLVM-Ausnahmen. Nutzung und Distribution der MAX-Plattform werden separat durch die Modular Community License geregelt.

Kann ich zum Mojo-Compiler beitragen?

Noch nicht. Standardbibliothek, MAX-Kernel, Beispiele und Dokumentation akzeptieren externe PRs. Seit 2024 kamen dabei rund 200 Mitwirkende mit gemergten Beiträgen zusammen. PRs für Compiler und Tooling bleiben bis zu Modulars Zieltermin Ende 2026 eingefroren.

Ist Mojo mit Python kompatibel?

Teilweise. Mojo importiert Python-Module über die CPython-Runtime und bietet C-kompatible Bindings für Aufrufe aus Python. Es ist aber nicht quellcodekompatibel mit Python 3, besitzt keine Klassen, und laut eigener Roadmap kann es sich „may or may not“ zu einem vollständigen Superset entwickeln.

Was bis 2027 entscheidend wird

Drei datierbare Meilensteine werden zeigen, ob aus diesem Release ein von der Community getragenes Projekt wird: Modulars Ziel, bis Ende 2026 Beiträge zu Compiler und Tooling anzunehmen, Phase 3 der Roadmap mit Klassen, Vererbung und untypisierten Variablen – dort würde ernsthafte Python-Kompatibilität sichtbar – sowie die Geschwindigkeit, mit der APIs der Standardbibliothek unter der Semver-Politik nach 1.0 als stabil markiert werden.