Mojo en open source : licence, limites et réalité de l’interop Python

Mojo peut désormais se présenter comme un langage open source de bout en bout : depuis le 18 août 2026, Modular a publié le compilateur, les outils et les sources nécessaires à la construction du langage sous licence Apache 2.0 avec exceptions LLVM. Mais le tableau mérite quelques nuances. Les pull requests sur le compilateur restent gelées jusqu’à l’objectif fixé par Modular pour la fin 2026, tandis que la pile de serving GPU s’appuie encore sur des composants précompilés distribués sous une licence distincte. Voici où passe précisément la frontière, afin d’évaluer ce sur quoi il est raisonnable de bâtir avec Mojo aujourd’hui.

Mojo est devenu open source en trois étapes depuis 2024

Le langage Mojo n’est pas passé à l’open source d’un seul coup. Modular, l’entreprise fondée par Chris Lattner, créateur de LLVM et Swift, a étalé l’ouverture sur plus de deux ans : la bibliothèque standard et le code des kernels ont été publiés avant le compilateur.

Attention à la date des sources : celles qui précèdent le 18 août 2026 décrivent très souvent le compilateur comme fermé. L’article Wikipédia consacré à Mojo, par exemple, le répertoriait encore sous la licence propriétaire Modular Community License dans sa version du 12 août 2026, soit six jours avant la publication.

Ce que permet réellement Apache 2.0 avec exceptions LLVM

Le fichier LICENSE du dépôt reprend le même modèle permissif que LLVM. Les deux exceptions LLVM ne relèvent pas du simple jargon juridique : elles ont des conséquences concrètes sur ce que vous pouvez distribuer.

La base Apache 2.0 accorde aux utilisateurs commerciaux les droits habituels : reproduire, modifier, sous-licencier et distribuer le code sous forme source ou objet. Elle comprend aussi une concession explicite de brevets par chaque contributeur, qui ne prend fin que si vous engagez une action en affirmant que l’œuvre enfreint vos propres brevets. En règle générale, la redistribution impose de fournir la licence, de signaler les modifications et de conserver le fichier NOTICE, conformément à la section 4.

Les exceptions LLVM ajoutent ensuite deux dérogations :

1. Code objet embarqué. Si la compilation de votre code incorpore des portions de Mojo dans vos artefacts compilés, les sections 4(a), 4(b) et 4(d) ne s’appliquent plus : vous n’avez pas à joindre le texte de la licence Apache à chaque binaire produit par le compilateur Mojo.
2. Combinaisons avec GPLv2. Si vous combinez des formes compilées avec Mojo à du code GPLv2 et qu’un tribunal estime que les clauses de brevet ou d’indemnisation d’Apache entrent en conflit avec la GPLv2, les sections en cause peuvent être écartées pour cette œuvre combinée.

En revanche, la licence ne vous accorde pas de droits sur les marques, notamment les noms Mojo et Modular, ni garantie ou protection contre la responsabilité. Et les sources du dépôt ne constituent qu’une partie du cadre : l’utilisation et la distribution de MAX, Mojo et Modular sont aussi régies séparément par la Modular Community License, comme le précise le README du dépôt.

Ce qui est ouvert, et ce qui ne l’est pas encore

Voici ce que recouvre concrètement l’expression « entièrement open source » dans le dépôt modular/modular — 53 617 commits, 26,9 k étoiles et 2,9 k forks au 19 août 2026 — et ce qui reste en dehors.

Cette dernière ligne ne relève pas d’une supposition de la communauté : l’annonce du 18 août de Modular indique qu’un compilateur précompilé « remains necessary » pour personnaliser des kernels ou modèles MAX. Pour les ingénieurs IA visant les GPU, c’est ici que se rejoignent aujourd’hui l’open source et les composants sous licence — et c’est précisément ce point qui a suscité des critiques le jour de l’annonce. u/benreynwar écrivait dans le fil d’annonce de r/ProgrammingLanguages :

« Il semble qu’il reste encore beaucoup de choses qui ne sont pas open source et dont vous avez besoin pour compiler vers le GPU. » — u/benreynwar, r/ProgrammingLanguages

La voie documentée pour le CPU local est simple : cloner, compiler avec Bazel, puis exécuter. C’est au moment de personnaliser des kernels GPU ou des modèles que la dépendance au compilateur précompilé entre en jeu.

Contributions : la stdlib oui, le compilateur non avant fin 2026

Open source ne signifie pas nécessairement gouvernance ouverte, et Mojo ne coche pour l’instant que la première case. L’article d’annonce est explicite : « we aren't ready to take contributions to the compiler and tooling », avec un objectif d’acceptation fixé à la fin 2026.

La situation est différente pour la bibliothèque standard. Elle reçoit des contributions externes depuis 2024 et, le jour de la sortie de Mojo 1.0, Modular indiquait compter près de 200 contributeurs ayant vu leurs pull requests fusionnées : plus de 1 100 PR représentant plus de 200 000 lignes modifiées. Pour le compilateur et les outils, les PR ne sont toujours pas acceptées.

Vous pouvez vérifier vous-même que les sources se compilent :

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 compile le compilateur depuis votre copie locale ; --config=prebuilt-mojo télécharge à la place le binaire nightly, selon l’annonce. Avant de forker le projet, gardez également à l’esprit que la branche main suit les builds nightly, que les versions stables paraissent toutes les six semaines, et que Modular conserve le contrôle de la maintenance tant que les contributions au compilateur restent fermées. Comme le résumait u/Fidodo dans le fil r/programming :

« Open source ne veut pas dire que la communauté gouverne. Les mainteneurs ont toujours le dernier mot sur ce qui est fusionné. » — u/Fidodo, r/programming

Interop avec Python : ce qui fonctionne et ce qui bloque

La page d’accueil officielle illustre le cas d’usage qui fonctionne : créer 40 valeurs Float64, les transmettre à NumPy, tracer le résultat avec Matplotlib, puis enregistrer plot.png, le tout depuis Mojo. Deux voies d’interop sont aujourd’hui bien réelles : Mojo peut importer des modules Python via le runtime CPython, et Python peut appeler des fonctions Mojo par l’intermédiaire de bindings compatibles C. C’est surtout cette seconde voie qui intéressera les ingénieurs IA : écrire le kernel critique en Mojo, tout en conservant le code d’entraînement et de serving en Python.

En revanche, l’idée de « sur-ensemble » de Python, mise en avant au lancement de Mojo en 2023, ne correspond pas à la réalité actuelle :

• Mojo n’est pas compatible au niveau du code source avec Python 3 : du code Python ne s’exécute pas tel quel.
• La feuille de route officielle indique désormais que Mojo « may or may not evolve into a full superset of Python », et sa phase 1 écartait explicitement le code non typé de style Python ainsi que la parité avec les bibliothèques Python.
• Mojo ne possède pas de système de classes Python : il utilise des structs avec des traits, soit un modèle objet différent.
• Les classes, l’héritage et les variables non typées relèvent de la phase 3 de la feuille de route, qui n’a pas commencé ; la phase 2, consacrée aux outils et au packaging, est en cours.
• Les API de la bibliothèque standard restent instables, sauf indication explicite de stabilité, y compris après la 1.0.

Les utilisateurs ayant tenté la migration se montrent plus directs que la documentation. Dans le fil sur l’état de Mojo de r/MojoLang :

« La prise en charge de Python comme superclasse est encore très loin. » — u/newtestdrive, r/MojoLang

« Ce n’est clairement pas encore un sur-ensemble de Python. » — @eatonphil, X

Le même u/newtestdrive rapporte que convertir des scripts Python « nuit à la lisibilité et est parfois impossible ». La FAQ de Modular recommande elle-même trois approches de migration : apprendre les différences documentées entre Python et Mojo, utiliser les compétences IA de Mojo pour une traduction assistée, ou exposer progressivement des bindings Mojo depuis un code Python existant. Il faut donc le considérer comme un langage de kernels aux accents Python, et non comme un remplaçant de Python.

La place de Mojo dans une stack IA aujourd’hui

Il existe des données indépendantes sur les performances GPU : une étude de l’Oak Ridge National Laboratory, présentée à l’atelier SC25 WACCPD et récompensée comme meilleur article, a comparé quatre kernels — stencil à sept points, BabelStream, miniBUDE et Hartree-Fock — à CUDA et HIP sur une NVIDIA H100 et une AMD MI300A. Mojo se montre globalement compétitif sur les charges limitées par la mémoire ; les cas intensifs en opérations atomiques et les calculs limités par la puissance avec fast-math conservent des écarts notables.

Quelques éléments à intégrer à votre planification : Mojo fonctionne nativement sous Linux et macOS ; Windows n’est pris en charge que via WSL. La politique de télémétrie du SDK couvre des informations système de base, les rapports de crash et des mesures agrégées de temps LSP ; aucun code source n’est transmis.

FAQ

Le langage Mojo est-il désormais entièrement open source ?

Oui. Depuis le 18 août 2026, le compilateur, les outils, la bibliothèque standard et les sources de build sont disponibles dans le dépôt GitHub modular/modular sous licence Apache 2.0 avec exceptions LLVM. Les builds précompilés de la plateforme MAX restent sous la Modular Community License distincte.

Sous quelle licence Mojo est-il distribué ?

Les sources du dépôt et les contributions relèvent de l’Apache License 2.0 avec exceptions LLVM ; l’utilisation et la distribution de la plateforme MAX sont régies séparément par la Modular Community License.

Puis-je contribuer au compilateur Mojo ?

Pas encore. La bibliothèque standard, les kernels MAX, les exemples et la documentation acceptent des PR externes — près de 200 contributeurs ont vu leurs contributions fusionnées depuis 2024 — mais les PR sur le compilateur et les outils sont gelées jusqu’à l’objectif annoncé par Modular pour la fin 2026.

Mojo est-il compatible avec Python ?

Partiellement. Mojo importe des modules Python via le runtime CPython et expose des bindings compatibles C pour être appelé depuis Python, mais il n’est pas compatible au niveau du code source avec Python 3, ne possède pas de classes, et sa propre feuille de route indique qu’il « may or may not » devenir un sur-ensemble complet.

Les trois points à suivre d’ici 2027

Trois échéances permettront de juger si cette sortie évolue vers un projet réellement porté par sa communauté : l’objectif de fin 2026 pour l’acceptation des contributions au compilateur et aux outils, la phase 3 de la feuille de route — classes, héritage et variables non typées, là où une compatibilité Python sérieuse pourrait émerger — et la rapidité avec laquelle les API de la bibliothèque standard seront marquées comme stables dans le cadre de la politique semver post-1.0.