Why Arc is AGPL: Our License, Our Intentions, Day One

I've watched the same story play out three times in the last few years.

A company builds an open-source database. They choose a permissive license—Apache 2.0, BSD, MIT—to maximize adoption. The project grows. Developers love it. Companies build their infrastructure on it.

Then AWS shows up.

Amazon takes the open-source code, wraps it in a managed service, and starts printing money. The original company gets nothing. No contributions. No revenue share. Just competition from a trillion-dollar company using their own code against them.

So the company changes their license. The community explodes. Forks appear. Trust evaporates.

I didn't want to do that with Arc. So we started with AGPL.

The Bait-and-Switch Pattern

Let me walk through what happened to three projects I deeply respect.

Redis: BSD to SSPL (March 2024)

Redis ran on the BSD 3-Clause license for 15 years. It became the most popular in-memory data store in the world. AWS launched Amazon ElastiCache for Redis. Google launched Memorystore. Azure launched Azure Cache for Redis.

Redis Labs (now Redis Inc.) watched cloud providers make billions from their work while contributing almost nothing back. In March 2024, they switched to dual SSPL/RSALv2 licensing.

The reaction was immediate. Within a week, the Linux Foundation announced https://github.com/valkey-io/valkey, a BSD-licensed fork backed by AWS, Google Cloud, Oracle, and Ericsson. The community split.

Elasticsearch: Apache 2.0 to SSPL (January 2021)

Elastic's story is similar but more contentious. Elasticsearch was Apache 2.0 licensed. AWS launched Amazon Elasticsearch Service in 2015—and according to Elastic, announced it "in collaboration with" Elastic when it wasn't.

For years, Elastic watched AWS profit from their work. In January 2021, they switched to SSPL. AWS responded by forking the last Apache-licensed version and creating OpenSearch. The Open Source Initiative called Elastic's new license "fauxpen source."

Today, Elasticsearch and OpenSearch are competing projects with divided communities.

MinIO: Apache 2.0 to AGPL (May 2021)

MinIO took a different path. Instead of SSPL (which isn't OSI-approved), they switched to AGPL-3.0—a real open-source license that still protects against the cloud provider problem.

But even with a legitimate open-source license, the sudden change created friction. Companies that had built on Apache-licensed MinIO now faced different obligations. Some felt blindsided.

The Pattern

The pattern is clear:

Start with a permissive license to maximize adoption
Grow the project until it's infrastructure
Watch cloud providers monetize your work
Change the license when you need to make money
Face community backlash and fork creation

Every step makes sense individually. But the end result is broken trust and fractured communities.

Why We Chose AGPL From Day One

When I started Arc, I knew we'd eventually need a business model. Time-series databases are infrastructure software—they take years to build and maintain. I couldn't fund that on good vibes and GitHub stars.

But I also knew I didn't want to pull the rug out from under our users.

So I asked myself: what if we just... told people upfront?

AGPL-3.0 is our answer. Here's what it means:

Transparency. From day one, everyone knows Arc's license and what it requires. No surprises. No "we're changing the rules because AWS hurt our feelings."

Real open source. AGPL is approved by the Open Source Initiative. It's recommended by the Free Software Foundation for network software. Unlike SSPL, it's actually open source—not "source available."

Take and give. Fork Arc. Use it. Improve it. But if you improve it and offer those improvements as a service, share them back. That's not restriction—that's reciprocity.

Commercial path is clear. If AGPL doesn't work for you, we offer commercial licensing. That's the deal, stated clearly from the beginning.

We're not going to build a community on Apache 2.0 and then change the rules when we need money. The rules are already set.

Clearing Up AGPL Misconceptions

AGPL has a reputation problem. Some of it is deserved—it's a complex license. But most of the fear comes from misconceptions that get repeated until they become accepted wisdom.

Let me address the big ones.

Misconception 1: "Using AGPL software means I have to open-source my code"

Reality: Only if you modify and distribute it, or offer the modified version as a service.

If you run Arc internally—for your company, for your team, for your personal projects—you have zero obligations. You don't have to publish anything. You don't have to share your application code. You just use it.

The AGPL only kicks in when you:

Modify Arc's source code AND
Either distribute those modifications OR offer them as a network service to others

Running Arc to store your sensor data? No obligations. Building a dashboard that queries Arc? No obligations. Using Arc as part of your internal infrastructure? No obligations.

As the FSF explains: "If you are not distributing the software or making it accessible to other developers or businesses, AGPLv3 does not require you to share your modified source code."

Misconception 2: "Connecting to an AGPL service infects my application"

Reality: Network interaction is not "conveying." Your client stays your license.

This is the most common fear, and it's unfounded.

If you build an application that connects to Arc over HTTP, your application is not a derivative work of Arc. The AGPL defines "conveying" specifically—and using a program over a network is explicitly not conveying.

Your Python script that queries Arc? It's not AGPL. Your Grafana dashboard? Not AGPL. Your custom analytics application? Not AGPL.

The AGPL FAQ is clear: "The AGPL does not require you to release your software just because you interact with a server running AGPL software."

Misconception 3: "AGPL isn't real open source"

Reality: AGPL is OSI-approved. SSPL is not.

This is where confusion often comes from. SSPL (Server Side Public License) is NOT approved by the Open Source Initiative. It's not recognized as open source by Debian, Red Hat, or most of the community. It's "source available"—you can see the code, but the license doesn't meet the Open Source Definition.

AGPL-3.0 is different. It's:

Approved by the Open Source Initiative
Endorsed by the Free Software Foundation
Used by major projects like https://github.com/grafana/grafana, https://github.com/mastodon/mastodon, https://github.com/mongodb/mongo (before they switched to SSPL), and https://github.com/nextcloud

When we say Arc is open source, we mean it in the way the term was defined—not in the marketing-friendly "source available" sense.

Misconception 4: "You can't use AGPL software commercially"

Reality: Commercial use is explicitly permitted.

From the AGPL itself: "You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you... [various conditions about attribution and source availability]."

Nothing in there says "except for commercial use."

You can:

Use Arc in commercial products
Charge money for services built on Arc
Include Arc in paid offerings

The only requirement is: if you modify Arc and distribute those modifications (or offer them as a service), you share the modified source code under AGPL.

Use Arc without modifications? No source code obligations at all—just use it.

What AGPL Actually Requires: A Simple Breakdown

Let me make this concrete.

What you're doing	AGPL requirement
Run Arc internally for your company	Nothing
Build an app that connects to Arc	Nothing
Use Arc in your commercial product (unmodified)	Nothing
Modify Arc for your internal use	Nothing
Modify Arc and distribute binaries	Share your modifications under AGPL
Fork Arc and run it as a competing SaaS	Share your modifications under AGPL

The threshold is: did you modify Arc AND make those modifications available to others (via distribution or network service)?

If yes: share your modifications. If no: do whatever you want.

The Philosophy: Take and Give

Here's my actual position on open source licensing.

I believe open source should benefit everyone. The developer who builds it. The company that maintains it. The users who deploy it. The community that improves it.

Permissive licenses optimize for adoption. That's great for getting users. But they don't create a sustainable ecosystem. They create a situation where the value flows out—to cloud providers, to companies that wrap the software, to anyone who takes without giving.

AGPL creates reciprocity. You can take Arc and build whatever you want with it. But if you improve Arc itself and share that improvement with others, you share the source code too. The improvement flows back to the community.

This isn't about restriction. It's about fairness.

When AWS takes Redis and offers it as a service, the Redis community gets nothing. When someone forks Arc and offers it as a service, the Arc community gets their improvements. That's the difference.

Why Not SSPL?

If AGPL is about protection from cloud providers, why not use SSPL like Redis and Elastic?

Because SSPL isn't open source.

SSPL requires that if you offer the software as a service, you must open-source your entire stack—not just your modifications to the licensed software, but everything: your deployment scripts, your monitoring, your billing system, everything that makes your service run.

That's a poison pill, not a license. It's designed to be impossible to comply with, forcing anyone who wants to offer a hosted service to buy a commercial license.

The Open Source Initiative rejected SSPL. Debian won't include SSPL software. It's not recognized as free software.

I wanted Arc to be genuinely open source. Not "source available." Not "open source but with a gotcha." Actually open source, with a license that's been vetted by the community for decades.

AGPL gives us protection against cloud providers while remaining true open source. That's the balance I wanted.

The Commercial License Option

AGPL works for most users. But some organizations have policies against AGPL software—often based on the misconceptions I addressed above, but policies are policies.

For those users, we offer commercial licensing. Pay us, and you get Arc under terms that work for your legal department.

This is the business model, stated clearly from day one:

AGPL is free and open source
Commercial license is available for those who need it
No bait-and-switch, no surprise license changes

You know what you're getting into before you write a single line of code against Arc.

Conclusion

The open source licensing landscape is a mess. Companies that started with permissive licenses are switching to restrictive ones. Communities are fracturing over license changes. Trust is eroding.

I didn't want to contribute to that mess.

Arc is AGPL-3.0. It has been since day one. It will stay that way.

If you use Arc, you know exactly what you're agreeing to. If you fork Arc and make it better, those improvements come back to the community. If you need different terms, we have a commercial license.

No surprises. No bait-and-switch. Just honest, reciprocal open source.

That's the deal.

Resources:

Questions about licensing? Email us at enterprise@basekick.net or ask in Discord.

Time-Series Database

Streaming