Engineering blog

Source-available, on purpose

The agent's code is now public under the Elastic License 2.0. Why not MIT, why we refuse to say 'open source', and what the license does and does not mean for the person auditing it.

As of this week, the full source of our monitoring agent is public at github.com/wakora-io/agent. It is the program we ask you to run as root, on machines that are not ours, sometimes on machines that move money. This post is about the license we picked for it, and about a term we are deliberately not using.

Why publish at all

A monitoring agent's job description is a security reviewer's nightmare: resident, privileged, networked, self-updating. Every vendor in this market asks for the same trust; most ask for it blind. We think the only honest answer to "why should we run this on our servers" is "read it". What the agent executes, what it reads, what leaves the host and what never does — all of that is now checkable instead of claimable. A repository does not replace the rest of the verification story (signed releases, reproducible builds, a published manifest chain — we wrote about that in "Signed everything, now build it yourself"), but it is the floor everything else stands on. You cannot audit a promise.

Why not MIT or Apache

The tempting move is a permissive license. Best optics, zero explaining. But permissive licenses permit the one thing we are genuinely not okay with: someone taking the engine we build and operating it as their own hosted monitoring service, against us, without writing a line. We are a small team. The agent is where years of production lessons live — the discovery logic, the least-privilege probes, the update machinery that refuses to go backwards. Handing that to a hypothetical competitor as a free head start is not humility, it is negligence toward the people who pay for this product to keep existing.

So we needed a license that allows everything an auditor, an operator or a tinkerer wants, and forbids exactly one business model. That license already exists.

What the Elastic License 2.0 actually says

ELv2 fits on one page, which is part of why we chose it. You may read the code, compile it, run it, modify it, and redistribute it. You may not provide it to third parties as a managed service, you may not circumvent license keys (the agent has none), and you may not remove copyright notices. That is the entire delta from open source.

Walk through what a security team actually does with agent source: read it before approving the install, grep it during an incident, rebuild it to verify the shipped binary matches, patch it locally if policy demands. Every one of those is explicitly allowed. The limitations only bite if your plan was to resell our agent as a service — in which case, yes, they bite on purpose.

Why we will not call it "open source"

Open source is a defined term. The definition requires permitting exactly what ELv2 forbids, so ELv2 code is not open source, full stop. Plenty of companies blur this and collect deserved grief for it. We are not going to: our entire pitch is "verify instead of trusting", and you do not get to make that pitch while borrowing a term that does not apply. A reviewer who reads "open source" on our site and then opens the LICENSE file should never find a contradiction, because that contradiction would cost more trust than the word ever bought.

So the site says source-available. The trust pack says published source. The words were changed everywhere this week, before anyone had to ask.

The fork nobody needs

The license legally stops a hosted competitor. It does not stop a fork, and we are relaxed about that, because the license was never the moat. The binary you install carries our endpoint, our certificate pin and our publisher key. Monitoring logic arrives as definitions signed by our key. The backend — ingest, the incident engine, escalations, the phone call at four in the morning — is the product. A fork of the agent alone is an engine on a workbench: excellent for study, which is precisely the use we published it for.

No outside pull requests, and why that is the honest setting

The repository does not accept external pull requests, and the contributing file says so plainly instead of hiding behind a stale queue. That reads unfriendly until you consider what this code is: every line ships, signed, to privileged processes on other people's servers. We review and sign what runs there; accepting drive-by patches into that chain would quietly undermine the reason the repository is public at all. Bug reports are welcome. Security reports are more than welcome — the security policy in the repository describes the channel, and findings get credited.

The repository answers the first question every security review asks us. The rest of the answers were already public. Now the code is too.

More from the engine room

Proving an eBPF fix on kernels we don't have

A struct changed shape in kernel 6.4 and our zero-touch HTTP metrics refused to load on older kernels. The fix was ordinary. Proving it across four kernel generations without owning a single one of them was the interesting part.

Read the story

Two machines, one identity

Clones, templates and restored backups are routine. Monitoring usually answers them by accident: a double host, a gap in the graphs, or a quiet impersonation. We answered on purpose.

Read the story

The retry loop that sent a thousand alerts

A sixty-second network blip, a write-ahead log doing its job too literally, and the messenger whose throttling hid the storm from us for two hours.

Read the story

Stories like this one, live on your own fleet.

Three hosts free, forever. Discovery does the tour for you.