AIREITERMojo, el lenguaje de sistemas con sabor a Python creado por Modular, es totalmente open source desde el 18 de agosto de 2026. El cambio abarca el compilador, las herramientas y el código necesario para construir el lenguaje, todo bajo Apache 2.0 con excepciones de LLVM. Pero el titular tiene dos matices importantes: los pull requests para el compilador seguirán bloqueados hasta el objetivo de Modular de finales de 2026, y la pila de serving para GPU aún depende de componentes precompilados con una licencia independiente. Esta guía delimita exactamente qué entra y qué queda fuera para valorar si Mojo es una base segura para tus proyectos hoy.
La apertura de Mojo llegó en tres fases desde 2024
El lenguaje Mojo no se hizo open source de golpe. Modular, la empresa fundada por Chris Lattner, creador de LLVM y Swift, escalonó la publicación durante más de dos años: primero liberó la biblioteca estándar y el código de los kernels; el compilador fue lo último en llegar.
| Fecha | Qué se abrió | PR externos |
|---|---|---|
| Marzo de 2024 | Biblioteca estándar, Apache 2.0 con excepciones de LLVM | Aceptados |
| 2024–2025 | Kernels GPU/CPU de Mojo, más de 450.000 LOC reportadas por Modular en mayo de 2025 | Aceptados |
| 11 de agosto de 2026 | Mojo 1.0.0 estable: semver para el lenguaje y cadencia de lanzamientos de seis semanas | - |
| 18 de agosto de 2026 | Compilador, herramientas y código de compilación, anunciado en ModCon | Bloqueados hasta finales de 2026 |
Ojo con la antigüedad de las fuentes: las anteriores al 18 de agosto de 2026 suelen describir el compilador como cerrado. El artículo de Mojo en Wikipedia, por ejemplo, todavía lo listaba bajo la licencia propietaria Modular Community License en su edición del 12 de agosto de 2026, seis días antes de la publicación.
Qué permite realmente Apache 2.0 con excepciones de LLVM
El archivo LICENSE del repositorio emplea la misma plantilla permisiva que LLVM, y sus dos excepciones no son simple letra pequeña legal: afectan directamente a qué puedes distribuir.
Apache 2.0 ofrece a los usuarios comerciales el paquete habitual: reproducir, modificar, sublicenciar y distribuir en formato fuente u objeto, además de una concesión explícita de patentes por parte de cada colaborador. Esta concesión solo termina si demandas alegando que la obra infringe tus patentes. Al redistribuir, normalmente debes incluir copias de la licencia, avisos sobre modificaciones y preservar el archivo NOTICE, según la Sección 4.
Las excepciones de LLVM introducen dos exenciones:
- Código objeto embebido. Si al compilar tu código se incorporan partes de Mojo en los artefactos resultantes, se eximen las Secciones 4(a), 4(b) y 4(d): no tienes que adjuntar el texto de la licencia Apache a cada binario generado por el compilador de Mojo.
- Combinaciones con GPLv2. Si combinas formas compiladas con Mojo con código GPLv2 y un tribunal determina que las cláusulas de patentes o indemnización de Apache entran en conflicto con GPLv2, las secciones incompatibles pueden quedar exentas para esa obra combinada.
Lo que la licencia no concede son marcas comerciales, incluidos los nombres Mojo y Modular, ni garantías o protección frente a responsabilidad. Además, el código del repositorio es solo una parte del panorama: el uso y la distribución de MAX, Mojo y Modular se rigen por separado mediante la Modular Community License, según el propio README del repositorio.
Qué está abierto y qué sigue fuera del repositorio
Esto es lo que cubre la expresión «totalmente open source» dentro del repositorio modular/modular, que tenía 53.617 commits, 26,9k estrellas y 2,9k forks a 19 de agosto de 2026, y lo que continúa fuera de él.
| Componente | Ubicación | Estado |
|---|---|---|
| Compilador de Mojo | Directorio /KGEN | Abierto desde el 18 de agosto de 2026; PRs bloqueados |
| Biblioteca estándar | /mojo/stdlib | Abierta desde marzo de 2024; acepta PRs |
| Kernels GPU/CPU de MAX | /max/kernels | Abiertos; acepta contribuciones |
| Servidor de inferencia y pipelines de modelos | /max/python/max/serve, /max/pipelines | Abiertos |
| Compilaciones precompiladas de plataforma MAX | Distribuidas fuera del repositorio | Modular Community License |
| Flujo de personalización de kernels/modelos de MAX | - | Sigue requiriendo un binario precompilado del compilador de Mojo |
La última fila no es una especulación de la comunidad, sino una admisión de Modular: el anuncio del 18 de agosto indica que un compilador precompilado «sigue siendo necesario» al personalizar kernels o modelos de MAX. Para los ingenieros de IA que trabajan con GPU, ahí es donde se cruzan actualmente los componentes open source y los licenciados; precisamente ese punto generó críticas el día del lanzamiento. u/benreynwar escribió en el hilo del anuncio de r/ProgrammingLanguages:
«Parece que todavía hay muchas cosas que no son open source y que necesitas para compilar para GPU». - u/benreynwar, r/ProgrammingLanguages
La vía documentada para CPU local es sencilla: clonar, compilar con Bazel y ejecutar. La dependencia del compilador precompilado aparece al personalizar kernels y modelos para GPU.
El compilador no acepta contribuciones hasta finales de 2026
Open source no equivale a gobernanza abierta, y Mojo por ahora solo cumple la primera condición. El post de anuncio lo dice sin rodeos: «aún no estamos preparados para aceptar contribuciones al compilador y las herramientas», con el objetivo declarado de hacerlo antes de finalizar 2026.
La biblioteca estándar es un caso distinto. Recibe contribuciones externas desde 2024 y, el día de la llegada de Mojo 1.0, Modular informó de casi 200 colaboradores con pull requests integrados: más de 1.100 PRs que modificaron más de 200.000 líneas. Los PRs para el compilador y las herramientas no se aceptan.
Puedes verificar por tu cuenta que el código fuente compila:
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 el compilador desde tu copia local; --config=prebuilt-mojo descarga en su lugar el binario nightly, según el anuncio. Antes de hacer un fork, conviene saber también que la rama main sigue las compilaciones nightly, que las versiones estables se publican cada seis semanas y que Modular conserva el control como mantenedor mientras las contribuciones al compilador permanezcan cerradas. Como resumió u/Fidodo en el hilo de r/programming:
«Open source no significa que mande la comunidad. Los mantenedores siguen teniendo la última palabra sobre lo que se integra». - u/Fidodo, r/programming
Interop con Python: qué funciona y qué no
La página oficial muestra la dirección que sí funciona: crear 40 valores Float64, pasarlos a NumPy, representarlos con Matplotlib y guardar plot.png, todo desde Mojo. Hoy existen dos vías de interoperabilidad reales: Mojo puede importar módulos Python a través del runtime de CPython, y Python puede invocar funciones de Mojo mediante bindings compatibles con C. Esta segunda opción es la más interesante para ingeniería de IA: escribe el kernel crítico en Mojo y mantén en Python el código de entrenamiento y serving.
Lo que no se sostiene es la idea de «superset» con la que Mojo se presentó en 2023. La situación actual es esta:
- Mojo no es compatible a nivel de código fuente con Python 3: el código Python no funciona sin cambios.
- La hoja de ruta oficial afirma ahora que Mojo «puede evolucionar o no hacia un superset completo de Python», y la Fase 1 excluyó explícitamente el código sin tipos al estilo Python y la paridad con las bibliotecas de Python.
- Mojo no cuenta con un sistema de clases de Python: usa structs con traits, un modelo de objetos diferente.
- Las clases, la herencia y las variables sin tipo están en la Fase 3 de la hoja de ruta, que no ha comenzado; la Fase 2, dedicada a herramientas y empaquetado, está en progreso.
- Las API de la biblioteca estándar son inestables salvo que se marquen expresamente como estables, incluso después de la versión 1.0.
Quienes han intentado migrar son más contundentes que la documentación. En el hilo sobre el estado de Mojo de r/MojoLang:
«Que Python sea un superconjunto sigue estando muy lejos». - u/newtestdrive, r/MojoLang
«Definitivamente todavía no es un superset de Python». - @eatonphil, X
El mismo u/newtestdrive explicó que convertir scripts de Python «perjudica la legibilidad y a veces no es posible». La FAQ de Modular recomienda tres rutas de migración: aprender las diferencias documentadas entre Python y Mojo, utilizar Mojo AI skills para traducir con ayuda de asistentes o exponer bindings de Mojo de forma incremental desde código Python existente. Entiéndelo como un lenguaje de kernels con acento Python, no como un reemplazo de Python.
El lugar de Mojo en una pila de IA hoy
Hay evidencia independiente sobre su rendimiento en GPU: un estudio del Oak Ridge National Laboratory, presentado en el taller SC25 WACCPD y premiado allí como mejor artículo, comparó cuatro kernels —seven-point stencil, BabelStream, miniBUDE y Hartree-Fock— frente a CUDA e HIP en una NVIDIA H100 y una AMD MI300A. Mojo fue ampliamente competitivo en cargas limitadas por memoria; los casos intensivos en operaciones atómicas y los de cálculo limitado por cómputo con fast-math mantuvieron diferencias notables.
| Tu carga de trabajo | Veredicto |
|---|---|
| Escribir kernels portables para GPU/CPU | Pruébalo en un piloto: los datos de ORNL respaldan la paridad en cargas limitadas por memoria; el código AMD intensivo en atómicas debe medirse antes |
| Serving de modelos en producción con MAX | Lee primero los términos de la Modular Community License; sigue existiendo la dependencia de binarios precompilados |
| Sustituir código general de aplicaciones Python | No: la Fase 3 está incompleta, no hay compatibilidad de código fuente y la gestión de paquetes no ha empezado |
| Aprender programación para aceleradores | Sí: código fuente legible, compilaciones locales y extensión de VS Code con LSP y depurador |
Notas de plataforma para planificar: Mojo se ejecuta de forma nativa en Linux y macOS; en Windows solo mediante WSL. La política de telemetría del SDK cubre información básica del sistema, informes de fallos y tiempos agregados de LSP; no se transmite código fuente.
Preguntas frecuentes
¿El lenguaje Mojo ya es totalmente open source?
Sí. Desde el 18 de agosto de 2026, el compilador, las herramientas, la biblioteca estándar y el código de compilación están en el repositorio modular/modular de GitHub bajo Apache 2.0 con excepciones de LLVM. Las compilaciones precompiladas de la plataforma MAX siguen bajo la Modular Community License independiente.
¿Qué licencia utiliza Mojo?
El código fuente del repositorio y las contribuciones usan Apache License 2.0 con excepciones de LLVM; el uso y la distribución de la plataforma MAX se rigen por separado mediante la Modular Community License.
¿Puedo contribuir al compilador de Mojo?
Todavía no. La biblioteca estándar, los kernels de MAX, los ejemplos y la documentación aceptan PRs externos —desde 2024, unos 200 colaboradores con cambios integrados—, pero los PRs para el compilador y las herramientas seguirán bloqueados hasta el objetivo declarado por Modular de finales de 2026.
¿Mojo es compatible con Python?
Parcialmente. Mojo importa módulos Python mediante el runtime de CPython y expone bindings compatibles con C para invocarlo desde Python, pero no es compatible a nivel de código fuente con Python 3, no tiene clases y su propia hoja de ruta señala que «puede evolucionar o no» hacia un superset completo.
Qué vigilar de aquí a 2027
Tres hitos con fecha determinarán si este lanzamiento madura hasta convertirse en un proyecto gestionado por la comunidad: el objetivo de finales de 2026 para aceptar contribuciones al compilador y las herramientas, la Fase 3 de la hoja de ruta —clases, herencia y variables sin tipo, donde aparecería cualquier compatibilidad seria con Python— y la velocidad con la que las API de la biblioteca estándar reciban la marca de estables bajo la política semver posterior a 1.0.