Apache e AGPL: O Que Significa para Você

O MonkeyLLM é distribuído sob duas licenças de propósito: o engine é Apache-2.0 e os apps são AGPL. A divisão não é um acidente de empacotamento, é uma decisão sobre quais partes queremos que você absorva na sua stack e quais partes queremos que permaneçam abertas. Aqui está o que cada lado permite, em termos claros de engenharia.

O engine é Apache-2.0

O engine é a parte que seus agentes tocam: a floresta em si (nós carregando passaportes curados: título, resumo, tags), os três movimentos (Navegar, Plantar, Feromônio) e as dez ferramentas tipadas expostas via MCP com cada salto orçado em tokens.

Apache-2.0 significa que você pode embutir tudo isso em qualquer lugar. Vendorizar dentro de um produto de código fechado. Fazer um fork privado. Ligar a uma plataforma comercial de agentes e vender isso a clientes. Mantenha a licença e os arquivos de notice e você não deve mais nada: sem copyleft, sem obrigação de publicar suas mudanças, sem restrição a vender um serviço construído em cima. Se o MonkeyLLM aparece na sua arquitetura como biblioteca, ou como um servidor MCP que seus agentes chamam, você está deste lado da divisão.

Os apps são AGPL

Os apps são as superfícies humanas: o console Studio (visão geral, Ask, Explore, jobs de ingestão, controle de acesso, saúde) e o clipper de navegador. A AGPL adiciona uma obrigação que vale conhecer: se você modifica um app e deixa pessoas usarem pela rede, você disponibiliza o código-fonte modificado a esses usuários.

Rodar os apps sem modificação não muda nada para você, interna ou publicamente. Auto-hospede o Studio para o seu time e você não publica nada. Faça um patch no Studio e ofereça-o como serviço hospedado a terceiros, e você compartilha o patch. Essa é a troca inteira.

Por que dividir

Queremos atrito zero onde a adoção acontece e abertura durável onde o produto vive. Engines são embutidos, e um engine Apache pode entrar em qualquer stack, sob qualquer licença, em qualquer empresa. É exatamente o que queremos para o modelo de navegação, porque "navegue, não recupere" (navigate, don't retrieve) se espalha ao ser construído dentro das coisas. Apps são operados, não embutidos, e a AGPL mantém as melhorias fluindo de volta para todos em vez de se acumularem em forks hospedados privados.

Uma stack toda Apache convidaria forks hospedados do console que nunca devolvem uma linha. Uma stack toda AGPL faria cada arquiteto que quer embutir o engine marcar uma reunião antes. A divisão dá a cada parte a licença que o papel dela precisa.

Note o que a divisão nunca faz: ela não alcança o seu código. Seus agentes, seus pipelines e seu produto mantêm as próprias licenças quando falam com o engine via MCP; a fronteira fica no protocolo.

Quatro cenários comuns

• Embutir o engine num produto proprietário: lado Apache, siga em frente.
• Rodar a stack completa auto-hospedada para o seu time: só rode, nada a publicar. O deploy leva quatro comandos, conforme o guia de deploy e o passo a passo com Docker.
• Hospedar um Studio modificado como serviço para terceiros: publique suas mudanças no Studio.
• Contribuir upstream: bem-vindo dos dois lados da divisão.

A versão curta

Absorva o engine livremente, opere os apps abertamente, e tudo roda na sua infra de qualquer jeito: self-hosting é a postura padrão, não um tier enterprise. Os textos das licenças são curtos e vivem no repo; eles são a letra onde este post é a intenção. Leia-os, depois suba uma floresta: MonkeyLLM no GitHub e monkeyllm.com.