Open source ad ops: an Apache 2.0 commitment

mureo is an open-source framework under Apache 2.0. That sentence is the product of a specific set of choices, not a default. This post explains the choices and the commitments that follow from them.

Why open source, for ad ops specifically

Most ad-ops tooling is proprietary SaaS. The default business model in the category is “we host the platform and your account connection.” That model does three things that mureo needs to avoid:

It opaqueifies the decisions. You cannot read the code that recommended pausing your campaign. You have to trust the vendor’s characterization of the logic. In a domain where the decisions move real money, that trust is disproportionate to the visibility.
It centralizes the credential. Your refresh tokens live on the vendor’s servers. Their breach is your breach.
It couples your operations to the vendor’s roadmap. When the vendor gets acquired, pivots, raises prices, or deprioritizes your use case, the platform you built process around is no longer the platform you have.

Open source does not solve these problems automatically — “OSS” is a necessary condition for operator sovereignty, not a sufficient one. It does, however, change the default: the code is inspectable, the credential path is traceable, and the framework outlives any single maintainer.

Why Apache 2.0 specifically

The Apache 2.0 license was chosen over alternatives for three properties that matter in the ad-ops context:

Explicit patent grant. Apache 2.0 licenses not just the code but any patents the contributors hold over it. In a category where ad-tech patent troll activity is nonzero, this is a material protection for downstream users.
Permissive, with attribution. Agencies can fork, rebrand, integrate, and redistribute. The only requirement is preserving the attribution notice. That’s the right shape for a framework that wants to be embedded into larger agency workflows.
Well-understood governance precedent. ASF projects, Kubernetes, Terraform (pre-BUSL), React — the ecosystem is thick with Apache 2.0 code, legal reviewers know what to say about it, and enterprise procurement paths are built for it.

The alternatives considered:

MIT. Simpler, but no patent grant. Acceptable for leaf libraries; less comfortable for a framework that touches ad accounts.
BSL / SSPL / elastic. Source-available licenses that reserve commercial rights to the original author. These would foreclose the agency-fork pathway, which is central to mureo’s distribution strategy.
AGPL. Keeps modifications open but creates friction for agencies that want to integrate mureo into internal, closed systems. Apache 2.0 is the neutral position.

Apache 2.0 is the conservative, legally-boring choice. For a framework whose users will pass it through infosec review, boring is the feature.

What stays local

One property of the framework worth naming plainly: all of the following stay on the operator’s machine.

Credentials. ~/.mureo/credentials.json or environment variables. They are read by the transport layer, never by the LLM, never by a vendor cloud.
State. STATE.json — campaign snapshots, action log, learned patterns. Append-only, on disk, operator-owned.
Strategy context. STRATEGY.md — persona, USP, goals, and their weighting. Plaintext in the operator’s repository.
Diagnostic knowledge base. What /learn has saved. It is a searchable store of prior decisions, on disk, operator-owned.
All decisions. Every /daily-check, /rescue, /creative-refresh, etc. runs locally against the platform APIs. There is no mureo-operated server that sees any of this.

The only network calls made are:

To the ad platform APIs themselves (Google Ads, Meta, Search Console, GA4), authenticated with the operator’s credentials.
To the LLM provider the operator has configured (Claude, OpenAI, Google, etc.), carrying the operator’s prompts and whatever context the workflow chose to include.

The mureo project does not run a relay. It does not run a telemetry endpoint. The project maintainers cannot see what operators run. This is a structural property, not a promise.

What the project will not do

Some commitments that hold for the duration of the Apache 2.0 OSS framework:

No paid-only features in the OSS codepath. If a workflow, validator, or tool ships in the mureo package, it runs regardless of whether the operator is also a customer of any future hosted service.
No telemetry by default. The framework does not emit usage data to the project maintainers. If that ever changes, it will be opt-in, documented, and reversible.
No lock-in to a specific LLM vendor. mureo works with any MCP- compatible agent. An operator who wants to move from Claude Code to Cursor to a model we haven’t heard of can do so without a migration.
No forced telemetry for bug reports. Diagnostic information for support requests is opt-in and hand-curated; the framework does not send state files, credentials, or action logs to anyone without an explicit operator action.

If a future managed offering exists — see the manifesto — it will be a distinct product at a distinct domain, with its own set of commitments. The OSS commitments above do not apply to it, and it does not weaken them.

How to contribute

The project accepts contributions under its Apache 2.0 contribution flow. The shape of contribution most welcome, in rough priority:

Platform connectors. Adding support for an ad platform mureo doesn’t cover (TikTok Ads, LinkedIn Ads, etc.) with the same validator + rollback discipline.
Diagnostic knowledge base entries. Patterns you’ve seen in real accounts, codified into a form /learn can surface later.
Workflow commands. /competitive-scan, /rescue, etc. are the framework’s external surface. New workflows that meet the strategy-bind + sample-gate + rollback-safety bar are welcome.
Security review. Second eyes on credential-guard, GAQL validator, rollback allow-list. The framework’s trust posture is only as good as its most-recent review.

What is not the right contribution shape: SaaS integration bolt-ons that route through vendor-hosted infrastructure. The framework’s local-first posture is non-negotiable.

For the operator evaluating long-term risk

The question an agency or in-house team should ask, before adopting mureo, is not “is the project well-maintained?” — projects come and go. The correct question is:

If the maintainers disappeared tomorrow, could we keep running mureo, forking it if needed, with the same security properties?

The answer is structurally yes. The license permits the fork. The code is auditable. The credentials and state are on the operator’s machine. No single vendor is in the critical path for operation.

That is the actual durable guarantee of open-source ad ops — not the free price tag, but the ability to keep operating when the upstream goes away. Apache 2.0 is the mechanism that ensures the answer to that question stays yes.