Mojo open source: licenza, limiti e realtà dell'interoperabilità con Python

Mojo, il linguaggio di sistema di Modular con una sintassi che richiama Python, è diventato completamente open source il 18 agosto 2026. Compilatore, tool e sorgenti necessari per costruire il linguaggio sono ora disponibili con licenza Apache 2.0 ed eccezioni LLVM. Restano però due confini importanti: le pull request per compilatore e tooling sono bloccate fino all'obiettivo fissato da Modular per la fine del 2026, mentre lo stack di serving GPU dipende ancora in parte da componenti precompilati con licenza separata. Ecco dove passa esattamente il confine, per capire su cosa sia sensato basare un progetto Mojo oggi.

Mojo open source: un rilascio in tre fasi dal 2024

Il linguaggio Mojo non è diventato open source dall'oggi al domani. Modular, fondata da Chris Lattner, creatore di LLVM e Swift, ha distribuito l'apertura del codice nell'arco di oltre due anni: prima la libreria standard e il codice dei kernel, infine il compilatore.

Attenzione alla data delle fonti: quelle precedenti al 18 agosto 2026 descrivono spesso il compilatore come chiuso. Per esempio, la pagina Wikipedia di Mojo riportava ancora il compilatore sotto licenza proprietaria Modular Community License nella revisione del 12 agosto 2026, appena sei giorni prima del rilascio.

Apache 2.0 con eccezioni LLVM: cosa permette davvero

Il file LICENSE del repository usa lo stesso modello permissivo adottato da LLVM. Le due eccezioni LLVM non sono semplice linguaggio legale: incidono concretamente su ciò che si può distribuire.

La base Apache 2.0 garantisce agli utenti commerciali il pacchetto standard: riproduzione, modifica, sublicenza e distribuzione in formato sorgente o oggetto, oltre a una concessione esplicita dei brevetti da parte di ogni contributore. Tale concessione termina soltanto nel caso in cui si avvii una causa sostenendo che l'opera violi propri brevetti. In genere, la ridistribuzione richiede di includere la licenza, segnalare le modifiche e conservare il file NOTICE, come previsto dalla Sezione 4.

Le eccezioni LLVM introducono invece due deroghe:

1. Codice oggetto incorporato. Se la compilazione del proprio codice inserisce parti di Mojo negli artefatti compilati, le Sezioni 4(a), 4(b) e 4(d) non si applicano: non è necessario allegare il testo della licenza Apache a ogni binario prodotto dal compilatore Mojo.
2. Combinazioni con GPLv2. Se si combinano forme compilate con Mojo e codice GPLv2, e un tribunale stabilisce che le clausole Apache su brevetti o indennizzo sono incompatibili con GPLv2, le sezioni in conflitto possono essere derogate per quell'opera combinata.

La licenza non concede invece diritti sui marchi, inclusi i nomi Mojo e Modular, né garanzie o protezione dalla responsabilità. Inoltre, il codice del repository è solo una parte del quadro: utilizzo e distribuzione di MAX, Mojo e Modular restano disciplinati separatamente dalla Modular Community License, come indica il README del repository.

Cosa è aperto e cosa resta fuori dal repository

Ecco cosa comprende davvero la definizione di "completamente open source" nel repository modular/modular — 53.617 commit, 26,9k stelle e 2,9k fork al 19 agosto 2026 — e cosa rimane invece esterno.

L'ultima riga non nasce da speculazioni della community, ma da una dichiarazione di Modular: l'annuncio del 18 agosto afferma che un compilatore precompilato "rimane necessario" per personalizzare kernel o modelli MAX. Per gli ingegneri AI che lavorano su GPU, è qui che codice open source e componenti soggetti a licenza si incontrano oggi; ed è proprio questo il punto contestato dagli utenti il giorno del lancio. u/benreynwar ha scritto nel thread di annuncio su r/ProgrammingLanguages:

"Sembra che ci siano ancora molte cose non open source necessarie per compilare per GPU." - u/benreynwar, r/ProgrammingLanguages

Per una build CPU locale, il percorso documentato è semplice: clonare, compilare con Bazel ed eseguire. La dipendenza dal compilatore precompilato entra in gioco quando si personalizzano kernel GPU e modelli.

Contributi al compilatore bloccati fino alla fine del 2026

Open source e governance aperta non sono la stessa cosa, e al momento Mojo offre soltanto il primo dei due aspetti. L'articolo di annuncio è esplicito: "non siamo pronti ad accettare contributi al compilatore e al tooling", con l'obiettivo dichiarato di iniziare entro la fine del 2026.

La libreria standard segue un percorso diverso. Accetta contributi esterni dal 2024 e, al giorno del rilascio di Mojo 1.0, Modular riportava quasi 200 contributori con pull request integrate: oltre 1.100 PR che hanno modificato più di 200.000 righe. Le PR per compilatore e tooling, invece, non vengono accettate.

È possibile verificare personalmente che i sorgenti compilino:

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 compila il compilatore dal checkout locale; --config=prebuilt-mojo scarica invece il binario nightly, come indicato nell'annuncio. Prima di creare un fork, conviene inoltre sapere che il branch main segue le build nightly, le release stabili arrivano ogni sei settimane e Modular mantiene il controllo dei maintainer finché i contributi al compilatore restano chiusi. Come ha sintetizzato u/Fidodo nel thread su r/programming:

"Open source non significa governo della community. I maintainer hanno comunque l'ultima parola su ciò che viene integrato." - u/Fidodo, r/programming

Interoperabilità con Python: cosa funziona e dove si ferma

La homepage ufficiale mostra la direzione già funzionante: creare 40 valori Float64, passarli a NumPy, generare un grafico con Matplotlib e salvare plot.png, tutto da Mojo. Oggi esistono due percorsi concreti di interoperabilità: Mojo può importare moduli Python tramite il runtime CPython e Python può richiamare funzioni Mojo attraverso binding compatibili con C. È il secondo scenario a essere più interessante per gli ingegneri AI: il kernel critico in Mojo, training e serving in Python.

A non reggere più è l'idea di Mojo come "superset" di Python, con cui il linguaggio era stato presentato nel 2023. La situazione attuale è questa:

• Mojo non è compatibile a livello di sorgente con Python 3: il codice Python non viene eseguito senza modifiche.
• La roadmap ufficiale afferma ora che Mojo "potrebbe o meno evolvere in un superset completo di Python"; la Fase 1 ha escluso esplicitamente il codice non tipizzato in stile Python e la parità con le librerie Python.
• Mojo non dispone di un sistema di classi Python: usa struct con trait, quindi un modello a oggetti differente.
• Classi, ereditarietà e variabili non tipizzate appartengono alla Fase 3 della roadmap, che non è ancora iniziata; la Fase 2, dedicata a tooling e packaging, è in corso.
• Le API della libreria standard sono instabili salvo indicazione esplicita di stabilità, anche dopo la 1.0.

Chi ha provato la migrazione usa toni più netti della documentazione. Dal thread sullo stato di Mojo in r/MojoLang:

"Il supporto di Python come superclasse è ancora molto lontano." - u/newtestdrive, r/MojoLang

"Non è decisamente ancora un superset di Python." - @eatonphil, X

Lo stesso u/newtestdrive ha riferito che convertire script Python "peggiora la leggibilità e talvolta non è possibile". La FAQ di Modular suggerisce tre strade per la migrazione: studiare le differenze documentate tra Python e Mojo, usare le competenze AI di Mojo per una traduzione assistita oppure esporre gradualmente binding Mojo dal codice Python esistente. Va considerato come un linguaggio per kernel con un accento Python, non come un sostituto di Python.

Dove collocare Mojo in uno stack AI oggi

Esistono dati indipendenti sulle prestazioni GPU: uno studio dell'Oak Ridge National Laboratory, presentato al workshop SC25 WACCPD e premiato lì come miglior paper, ha confrontato quattro kernel — seven-point stencil, BabelStream, miniBUDE e Hartree-Fock — con CUDA e HIP su NVIDIA H100 e AMD MI300A. Mojo è risultato generalmente competitivo nei carichi limitati dalla memoria; i casi compute-bound con molte operazioni atomiche e fast-math mostravano invece divari rilevanti.

Qualche nota di piattaforma utile per pianificare: Mojo gira nativamente su Linux e macOS, mentre su Windows solo tramite WSL. La policy di telemetria dell'SDK copre informazioni di sistema di base, crash report e tempistiche aggregate dell'LSP; non viene trasmesso alcun codice sorgente.

FAQ

Mojo è ora completamente open source?

Sì. Dal 18 agosto 2026, compilatore, tooling, libreria standard e sorgenti di build sono disponibili nel repository GitHub modular/modular con licenza Apache 2.0 ed eccezioni LLVM. Le build di piattaforma MAX precompilate restano sotto la Modular Community License separata.

Con quale licenza viene distribuito Mojo?

I sorgenti del repository e i contributi usano Apache License 2.0 con eccezioni LLVM; utilizzo e distribuzione della piattaforma MAX sono regolati separatamente dalla Modular Community License.

Posso contribuire al compilatore Mojo?

Non ancora. Libreria standard, kernel MAX, esempi e documentazione accettano PR esterne; dal 2024 sono stati integrati contributi di circa 200 persone. Le PR per compilatore e tooling restano bloccate fino all'obiettivo dichiarato da Modular per la fine del 2026.

Mojo è compatibile con Python?

Solo in parte. Mojo importa moduli Python attraverso il runtime CPython ed espone binding compatibili con C per essere richiamato da Python, ma non è compatibile a livello di sorgente con Python 3, non dispone di classi e la sua roadmap dichiara che "potrebbe o meno" diventare un superset completo.

Cosa monitorare da qui al 2027

Tre tappe datate diranno se questo rilascio evolverà in un progetto davvero guidato dalla community: l'obiettivo di fine 2026 per l'accettazione di contributi a compilatore e tooling, la Fase 3 della roadmap — classi, ereditarietà e variabili non tipizzate, dove dovrebbe emergere qualsiasi compatibilità Python sostanziale — e la rapidità con cui le API della libreria standard verranno contrassegnate come stabili secondo la policy semver successiva alla 1.0.