Mojo Open Source: licença, limites e a realidade da integração com Python

O Mojo, linguagem de sistemas da Modular com sintaxe inspirada em Python, passou a ser totalmente open source em 18 de agosto de 2026. Compilador, ferramentas e todo o código-fonte necessário para montar a linguagem ficaram disponíveis sob a licença Apache 2.0 com exceções LLVM. Mas há duas ressalvas importantes: pull requests para o compilador continuam congelados até a meta da Modular para o fim de 2026, e a pilha de serving para GPU ainda depende de componentes pré-compilados sob licença separada. Este guia delimita exatamente o que está aberto para ajudar a avaliar onde o Mojo já é uma aposta segura.

O caminho do Mojo até o código aberto teve três etapas desde 2024

A linguagem Mojo não ficou open source de uma vez só. A Modular, fundada por Chris Lattner, criador do LLVM e do Swift, liberou os componentes ao longo de mais de dois anos: primeiro vieram a biblioteca padrão e o código dos kernels; o compilador foi a última peça.

Vale um alerta sobre a atualidade das fontes: materiais anteriores a 18 de agosto de 2026 costumam dizer que o compilador era fechado. O artigo do Mojo na Wikipedia, por exemplo, ainda o listava sob a licença proprietária Modular Community License na edição de 12 de agosto de 2026, seis dias antes da abertura.

Na prática, o que permite a Apache 2.0 com exceções LLVM

O arquivo LICENSE do repositório usa o mesmo modelo permissivo adotado pelo LLVM. As duas exceções LLVM não são mero juridiquês: elas afetam diretamente o que pode ser distribuído.

A base Apache 2.0 entrega o pacote habitual para uso comercial: permite reproduzir, modificar, sublicenciar e distribuir em formato de código-fonte ou objeto, além de conceder uma licença explícita de patentes por parte de cada colaborador. Essa concessão só termina se você processar alguém alegando que o trabalho viola suas patentes. Em geral, a redistribuição exige incluir cópias da licença, avisos sobre modificações e preservar o arquivo NOTICE, conforme a Seção 4.

As exceções LLVM criam duas dispensas:

1. Código objeto incorporado. Se a compilação do seu código incorporar partes do Mojo aos artefatos gerados, as Seções 4(a), 4(b) e 4(d) deixam de valer. Ou seja, não é preciso enviar o texto da licença Apache junto com cada binário produzido pelo compilador Mojo.
2. Combinações com GPLv2. Ao combinar formas compiladas pelo Mojo com código GPLv2, caso um tribunal conclua que cláusulas de patente ou indenização da Apache conflitam com a GPLv2, as seções conflitantes podem ser dispensadas para esse trabalho combinado.

O que a licença não concede: direitos sobre marcas, incluindo os nomes Mojo e Modular, garantia ou proteção contra responsabilidade. E o código do repositório é apenas metade do cenário de licenciamento: segundo o próprio README, o uso e a distribuição de MAX, Mojo e Modular são regidos separadamente pela Modular Community License.

O que está aberto e o que continua fora do repositório

É isto que o termo “totalmente open source” abrange no repositório modular/modular — que tinha 53.617 commits, 26,9 mil estrelas e 2,9 mil forks em 19 de agosto de 2026 — e o que ainda permanece fora dele.

A última linha não é especulação da comunidade, mas uma admissão da própria Modular: o anúncio de 18 de agosto afirma que um compilador pré-compilado “continua necessário” para customizar kernels ou modelos do MAX. Para engenheiros de IA que miram GPUs, é justamente nesse ponto que os componentes open source encontram os licenciados — e foi exatamente aí que surgiram críticas no dia do anúncio. u/benreynwar escreveu no tópico de anúncio em r/ProgrammingLanguages:

"Parece que ainda há muita coisa que não foi aberta e de que você precisa para compilar para GPU." - u/benreynwar, r/ProgrammingLanguages

Para builds locais de CPU, o caminho documentado é simples: clonar, compilar com Bazel e executar. A dependência do compilador pré-compilado entra em cena ao customizar kernels e modelos para GPU.

Contribuições ao compilador seguem bloqueadas até o fim de 2026

Código aberto e governança aberta são coisas diferentes, e o Mojo hoje só tem a primeira. O post de anúncio é explícito: “ainda não estamos prontos para aceitar contribuições ao compilador e às ferramentas”, com a meta declarada de começar a aceitá-las até o fim de 2026.

A situação da biblioteca padrão é outra. Ela recebe contribuições externas desde 2024 e, no lançamento do Mojo 1.0, a Modular informou ter quase 200 colaboradores com pull requests integrados: mais de 1.100 PRs alterando mais de 200.000 linhas. Já PRs para compilador e ferramentas não são aceitos.

Você pode verificar por conta própria se o código-fonte 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 o compilador a partir do seu checkout local; já --config=prebuilt-mojo baixa o binário nightly, conforme o anúncio. Antes de fazer um fork, considere também que a branch main acompanha as builds nightly, os lançamentos estáveis chegam a cada seis semanas e a Modular mantém o controle dos mantenedores enquanto as contribuições ao compilador permanecem fechadas. Como resumiu u/Fidodo em um tópico de r/programming:

"Open source não significa que a comunidade manda. Os mantenedores continuam tendo a palavra final sobre o que entra no projeto." - u/Fidodo, r/programming

Integração com Python: o que funciona e onde estão os limites

A página oficial mostra a direção que já funciona: criar 40 valores Float64, passá-los ao NumPy, gerar um gráfico com Matplotlib e salvar plot.png, tudo a partir do Mojo. Hoje há duas vias reais de integração: o Mojo importa módulos Python pelo runtime CPython, e o Python pode chamar funções Mojo por bindings compatíveis com C. Esta segunda via é a mais relevante para engenheiros de IA: escrever o kernel crítico em Mojo e manter o código de treino e serving em Python.

O que não se sustenta é a ideia de “superset” com que o Mojo foi lançado em 2023. O cenário atual é este:

• Mojo não é compatível com Python 3 no nível do código-fonte: código Python não roda sem alterações.
• O roadmap oficial agora diz que o Mojo “pode ou não evoluir para um superset completo de Python”, e a Fase 1 deixou explicitamente de fora código não tipado no estilo Python e paridade com bibliotecas Python.
• O Mojo não tem um sistema de classes Python; usa structs com traits, ou seja, outro modelo de objetos.
• Classes, herança e variáveis não tipadas estão na Fase 3 do roadmap, que ainda não começou; a Fase 2, sobre ferramentas e empacotamento, está em andamento.
• As APIs da biblioteca padrão são instáveis, salvo quando marcadas explicitamente como estáveis, inclusive após a versão 1.0.

Quem tentou migrar é mais direto que a documentação. Em uma discussão sobre o estado do Mojo em r/MojoLang:

"O suporte a Python como superclasse ainda está muito distante." - u/newtestdrive, r/MojoLang

"Definitivamente ainda não é um superset de Python." - @eatonphil, X

O mesmo u/newtestdrive relatou que converter scripts Python “prejudica a legibilidade e, às vezes, não é possível”. A FAQ da própria Modular recomenda três rotas de migração: aprender as diferenças documentadas entre Python e Mojo, usar habilidades de IA do Mojo para tradução assistida ou expor bindings Mojo gradualmente a partir de código Python existente. Encare-o como uma linguagem para kernels com sotaque de Python, não como substituto do Python.

Em que lugar o Mojo entra em uma stack de IA hoje

Há evidência independente sobre o desempenho em GPU: um estudo do Oak Ridge National Laboratory, apresentado no workshop SC25 WACCPD e premiado como melhor artigo, comparou quatro kernels — stencil de sete pontos, BabelStream, miniBUDE e Hartree-Fock — com CUDA e HIP em uma NVIDIA H100 e uma AMD MI300A. O Mojo foi, em linhas gerais, competitivo em cargas limitadas por memória; casos com uso intenso de operações atômicas e computação limitada por desempenho com fast-math mantiveram diferenças relevantes.

Algumas observações de plataforma para o planejamento: o Mojo roda nativamente em Linux e macOS; no Windows, apenas via WSL. A política de telemetria do SDK abrange informações básicas do sistema, relatórios de falha e métricas agregadas de tempo do LSP — nenhum código-fonte é transmitido.

Perguntas frequentes

O Mojo é totalmente open source agora?

Sim. Desde 18 de agosto de 2026, o compilador, as ferramentas, a biblioteca padrão e o código de build estão no repositório modular/modular no GitHub, sob Apache 2.0 com exceções LLVM. Os builds pré-compilados da plataforma MAX continuam sob a Modular Community License separada.

Qual é a licença do Mojo?

O código do repositório e as contribuições usam Apache License 2.0 com exceções LLVM; o uso e a distribuição da plataforma MAX são regidos separadamente pela Modular Community License.

Posso contribuir para o compilador do Mojo?

Ainda não. Biblioteca padrão, kernels MAX, exemplos e documentação aceitam PRs externos — desde 2024, cerca de 200 colaboradores tiveram contribuições integradas —, mas PRs para compilador e ferramentas estão congelados até a meta da Modular para o fim de 2026.

O Mojo é compatível com Python?

Parcialmente. O Mojo importa módulos Python pelo runtime CPython e disponibiliza bindings compatíveis com C para chamadas a partir do Python, mas não é compatível com Python 3 no nível do código-fonte, não tem classes e seu próprio roadmap diz que ele “pode ou não” se tornar um superset completo.

O que acompanhar até 2027

Três marcos com data definem se este lançamento vai amadurecer como um projeto conduzido pela comunidade: a meta para o fim de 2026 de aceitar contribuições ao compilador e às ferramentas, a Fase 3 do roadmap — classes, herança e variáveis não tipadas, onde surgiria uma compatibilidade séria com Python — e a velocidade com que as APIs da biblioteca padrão receberão a marcação de estáveis sob a política semver pós-1.0.