Apache y AGPL: qué significa para ti

MonkeyLLM se distribuye bajo dos licencias a propósito: el motor es Apache-2.0 y las apps son AGPL. La división no es un accidente de empaquetado, es una decisión sobre qué partes queremos que absorbas en tu stack y qué partes queremos que permanezcan abiertas. Esto es lo que cada lado te permite hacer, en términos simples de ingeniería.

El motor es Apache-2.0

El motor es la parte que tocan tus agentes: el bosque en sí (nodos con pasaportes curados: título, resumen, tags), los tres movimientos (Navegar, Plantar, Feromona) y las diez herramientas tipadas expuestas sobre MCP con cada salto sujeto a presupuesto de tokens.

Apache-2.0 significa que puedes incrustar todo eso donde quieras. Vendorizarlo dentro de un producto de código cerrado. Hacerle fork en privado. Cablearlo a una plataforma comercial de agentes y venderle eso a tus clientes. Conserva la licencia y los archivos de aviso y no debes nada más: sin copyleft, sin obligación de publicar tus cambios, sin restricción para vender un servicio construido encima. Si MonkeyLLM aparece en tu arquitectura como una biblioteca, o como un servidor MCP que tus agentes llaman, estás de este lado de la división.

Las apps son AGPL

Las apps son las superficies humanas: la consola Studio (overview, Ask, Explore, trabajos de ingesta, control de acceso, salud) y el clipper de navegador. AGPL agrega una obligación que vale la pena conocer: si modificas una app y dejas que la gente la use por red, pones tu código fuente modificado a disposición de esos usuarios.

Correr las apps sin modificar no cambia nada para ti, ni interna ni públicamente. Autoaloja Studio para tu equipo y no publicas nada. Parcha Studio y ofrécelo como servicio alojado a terceros, y compartes el parche. Ese es todo el trato.

Por qué dividir siquiera

Queremos cero fricción donde ocurre la adopción y apertura durable donde vive el producto. Los motores se incrustan, y un motor Apache puede entrar a cualquier stack, bajo cualquier licencia, en cualquier empresa. Eso es exactamente lo que queremos para el modelo de navegación, porque "navega, no recuperes" se propaga siendo integrado en cosas. Las apps se operan, no se incrustan, y AGPL mantiene las mejoras fluyendo de vuelta a todos en lugar de acumularse en forks alojados privados.

Un stack todo Apache invitaría forks alojados de la consola que nunca devuelven una línea. Un stack todo AGPL obligaría a cada arquitecto que quiera incrustar el motor a agendar una reunión primero. La división le da a cada parte la licencia que su rol necesita.

Nota lo que la división nunca hace: no alcanza tu código. Tus agentes, tus pipelines y tu producto conservan sus propias licencias cuando hablan con el motor sobre MCP; la frontera se asienta en el protocolo.

Cuatro escenarios comunes

• Incrustar el motor en un producto propietario: lado Apache, adelante.
• Correr el stack completo autoalojado para tu equipo: solo córrelo, nada que publicar. El despliegue toma cuatro comandos, según la guía de despliegue y el recorrido con Docker.
• Alojar un Studio modificado como servicio para terceros: publica tus cambios de Studio.
• Contribuir upstream: bienvenido en ambos lados de la división.

La versión corta

Absorbe el motor libremente, opera las apps abiertamente, y todo corre en tu infra de cualquier manera: el autoalojamiento es la postura por defecto, no un tier enterprise. Los textos de las licencias son cortos y viven en el repo; ellos son la letra donde este post es la intención. Léelos y luego despliega un bosque: MonkeyLLM en GitHub y monkeyllm.com.