Apache and AGPL: What It Means for You
The engine is Apache-2.0, the apps are AGPL. What each side lets you do, why the split exists, and why the boundary never reaches into your code.
MonkeyLLM ships under two licenses on purpose: the engine is Apache-2.0 and the apps are AGPL. The split is not an accident of packaging, it is a decision about which parts we want you to absorb into your stack and which parts we want to stay open. Here is what each side lets you do, in plain engineering terms.
The engine is Apache-2.0
The engine is the part your agents touch: the forest itself (nodes carrying curated passports: title, summary, tags), the three moves (Navigate, Plant, Pheromone), and the ten typed tools exposed over MCP with every hop token-budgeted.
Apache-2.0 means you can embed all of that anywhere. Vendor it into a closed-source product. Fork it privately. Wire it into a commercial agent platform and ship that to customers. Keep the license and notice files and you owe nothing else: no copyleft, no obligation to publish your changes, no restriction on selling a service built on top. If MonkeyLLM shows up in your architecture as a library, or as an MCP server your agents call, you are on this side of the split.
The apps are AGPL
The apps are the human surfaces: the Studio console (overview, Ask, Explore, ingest jobs, access control, health) and the browser clipper. AGPL adds one obligation worth knowing about: if you modify an app and let people use it over a network, you make your modified source available to those users.
Running the apps unmodified changes nothing for you, internally or publicly. Self-host Studio for your team and you publish nothing. Patch Studio and offer it as a hosted service to others, and you share the patch. That is the entire trade.
Why split at all
We want zero friction where adoption happens and durable openness where the product lives. Engines get embedded, and an Apache engine can go into any stack, under any license, at any company. That is exactly what we want for the navigation model, because "navigate, don't retrieve" spreads by being built into things. Apps get operated, not embedded, and AGPL keeps improvements to them flowing back to everyone instead of accumulating in private hosted forks.
An all-Apache stack would invite hosted forks of the console that never return a line. An all-AGPL stack would make every architect who wants to embed the engine schedule a meeting first. The split gives each part the license its role needs.
Notice what the split never does: it does not reach into your code. Your agents, your pipelines and your product keep their own licenses when they talk to the engine over MCP; the boundary sits at the protocol.
Four common scenarios
- Embed the engine in a proprietary product: Apache side, go ahead.
- Run the full stack self-hosted for your team: just run it, nothing to publish. Deploy takes four commands, per the deploy guide and the Docker walkthrough.
- Host a modified Studio as a service for others: publish your Studio changes.
- Contribute upstream: welcome on both sides of the split.
The short version
Absorb the engine freely, operate the apps openly, and everything runs on your infra either way: self-hosting is the default posture, not an enterprise tier. The license texts are short and live in the repo; they are the letter where this post is the intent. Read them, then deploy a forest: MonkeyLLM on GitHub and monkeyllm.com.