Open Source for About a Day

For roughly one day in September 2026, G8KEPR was going to be an open source project.

On September 9 I decided Apache-2.0 was the way to go. On September 10 I reversed that and kept it proprietary. That's the whole timeline. It's a short post's worth of history, but the reasoning on both days is worth keeping, partly so I don't have to rebuild it from scratch the next time the question comes up.

The case I made on September 9

I don't think the open source argument was a whim. For a product like this, it's a serious one.

Security tools run on trust. G8KEPR sits in-path inside the customer's own VPC. It sees API traffic, MCP tool definitions, prompts and model answers. That's a lot to ask someone to hand to a black box. Being able to read the code that's watching your traffic is a strong answer to "why should I trust this?"

It's self-hosted anyway. G8KEPR already deploys with Helm or Terraform into the customer's environment, and it's designed so that zero bytes leave their VPC. When the software already lives entirely on the customer's side, publishing the source feels like a smaller step than it would for a hosted service.

Adoption is hard for one person. I'm building this on my own, evenings and weekends. Open source is one of the few ways a solo project can get in front of engineers without a sales team.

Apache-2.0 is the friendly choice. It's a permissive license: people can use, modify and redistribute the code, including commercially, and it includes an explicit patent grant from contributors. Companies' legal teams tend to be comfortable with it. If you're going to open source something and want people to actually use it, it's a sensible pick.

The case that won on September 10

The same property that makes Apache-2.0 friendly is the problem.

A permissive license lets anyone take the code and build on it commercially. For most of G8KEPR, that might not matter much. A WAF rule set or a rate limiter isn't a secret, and there are plenty of them around.

But I'd just narrowed the whole product around one idea: the cross-pillar correlation engine, which scores signals that co-occur across the API, MCP, gateway and model-output checkpoints. That engine is the reason G8KEPR exists as a company rather than a collection of useful parts. It's the thing with commercial value.

Publishing it under Apache-2.0 would mean the most valuable part of the company is free for anyone to use, including in a competing product. Once code is released under a license like that, you can't meaningfully take it back. Whoever has a copy keeps the rights they got with it.

So the decision came down to one question: is the correlation engine something I'm selling, or something I'm giving away? The answer was selling. Proprietary it is.

Both sides, side by side

	Open source (Apache-2.0)	Proprietary
Trust	Anyone can read the code watching their traffic	Trust has to be earned other ways
Reach	Easier for engineers to find and try	Needs deliberate outreach
The correlation engine	Free for anyone, including competitors	Stays the thing customers pay for
Reversibility	Hard to undo once released	Can still open parts later

The deciding reason was the correlation engine row, but the last one is worth a word too. Staying proprietary keeps options open. Going open source closes some for good. When one path is reversible and the other mostly isn't, and you're not sure, the reversible one deserves the benefit of the doubt.

The trust question doesn't go away

The trust argument didn't go away just because I picked proprietary. It's still a fair question to ask of any security product, and I'd rather answer it than ignore it.

Part of the answer is in how G8KEPR is built. It runs in the customer's own VPC, nothing leaves by design, and detection is deterministic regex plus classical ML rather than an LLM making judgment calls. Those are properties someone can check in their own environment.

Part of it is the go-to-market plan. The idea is a free MCP security CLI scanner as the front door: something useful that people can run without buying anything. That's a plan, not a shipped thing, and I'll write about it when it's real.

And part of it is being public about how good the product actually is, which is what the scorecard is for.

Was the day wasted?

I don't think so. Changing your mind after one day is cheaper than changing it after a release. The September 9 version of me made a real argument, and the September 10 version had to answer it rather than wave it off. The answer was specific enough to write down, and now it is.