Why I Chose ELv2 — and What It Means for Invariant

A couple of months ago, I wouldn't have imagined myself building a TypeScript framework.

The idea hadn't even crossed my mind.

I'm a self-taught software engineer. I've always considered myself more of a generalist than an expert in any particular field. What I've always been good at — and what I enjoy the most — is looking at a problem, understanding how the pieces interact, and figuring out how to make the whole system work.

I think naturally in systems.

When AI agents started becoming possible, I became obsessed with them.

Even before MCP existed, and before today's ecosystem of agent frameworks had really taken shape, I was building agentic demos simply because I found them fascinating. I wasn't trying to start an "AI infrastructure company." I was playing with a new kind of software and trying to understand what could be built with it.

But almost immediately, I started running into problems.

And strangely, those problems were the part that excited me the most.

Models could reason surprisingly well, but giving them more responsibility also meant giving probabilistic systems control over things that software traditionally expects to be deterministic.

State. Execution. Recovery. Side effects. Long-running processes. External systems.

The more agents I built, the more I started thinking that maybe one of the important problems of the next decade wouldn't simply be building smarter models.

It would be building software for models.

Because no matter how intelligent models become, they're still probabilistic.

And when you look past the model, almost everything an agent actually does eventually becomes a workflow.

That idea stuck with me.

---

Following the Problem

I didn't sit down one day and design Invariant from first principles.

It emerged gradually.

I kept building AI systems my own way. I discussed the problems with other engineers. I read papers. I studied how other frameworks approached agents. I built things, broke them, rebuilt them, and kept asking myself where the responsibility of the model should end and where the responsibility of infrastructure should begin.

Slowly, the thesis became clearer:

Models should reason. Infrastructure should execute.

The model can decide what should happen.

But infrastructure should own execution, state, recovery, observability, and the guarantees surrounding that decision.

Once I started separating those responsibilities, many of the problems I had been struggling with became much easier to reason about.

At least for me, it worked.

And that eventually became Invariant.

The actual framework came together surprisingly quickly. But I don't think the ideas behind it came together in a few weeks.

They feel like the accumulation of years of building software, debugging systems, making architectural mistakes, learning how abstractions fail, and developing my own criteria for solving problems.

AI changed something else for me too.

As a generalist engineer, I've often had ideas that were larger than what I could realistically implement alone. AI dramatically shortened the distance between understanding an abstraction, designing an architecture, modeling it, and translating it into working code.

Suddenly, building something like Invariant by myself didn't feel impossible.

And then I ran into a completely different problem.

If I want other people to use this, how open should it be?

---

I Want Invariant to Be Open

I've thought about this a lot.

I want you to be able to read Invariant's source code.

I want you to run it on your own infrastructure.

I want you to modify it.

I want you to learn from it.

I want companies to build products with it.

I want someone to discover Invariant, recognize one of the same problems that drove me crazy while building agents, and think:

"This makes my life easier."

Honestly, building a community of engineers who find Invariant useful would probably be one of the most satisfying outcomes of this entire experiment.

And if someday Invariant creates enough value for developers and companies that the project itself can become a sustainable company, that would be a dream come true.

But there's an important reality behind all of this.

Today, I'm still building Invariant while working my full-time job.

There isn't a large engineering organization behind it.

There isn't a large pool of venture capital funding development.

There isn't an established business protecting the project.

There's mostly an idea I believe in, a lot of engineering work, and me trying to see how far I can take it.

That's part of why I chose the Elastic License 2.0 (ELv2) for Invariant.

---

Why ELv2?

Infrastructure software has a strange tension.

The more useful you make it, the easier it can become for another company — potentially one with far more capital, engineers, infrastructure, and distribution — to take that work, package it as a hosted service, and compete directly with the people building it.

For a large company, that can be a strategic problem.

For a tiny one, it can be existential.

I don't think making Invariant available to everyone should require giving another company an unrestricted right to take the framework, put a cloud API in front of it, call it something else, and make the framework itself their product.

ELv2 gives me a balance I'm comfortable with.

It lets me say:

• Build with Invariant.
• Build on Invariant.
• Build a business using Invariant.

Just don't take Invariant itself and turn it into a competing managed service.

That's the boundary.

---

What Does That Mean for You?

For the overwhelming majority of developers interested in Invariant, I don't want the license to get in your way.

• You can inspect the source.
• You can run it yourself.
• You can modify it.
• You can use it inside your company.
• You can build commercial applications with it.
• You can deploy those applications on your own infrastructure.
• You don't need an Invariant Cloud account to build software with Invariant.

And I want to preserve that philosophy.

If Invariant eventually offers a managed cloud platform, I don't want it to succeed because we made self-hosting intentionally painful or because your application becomes trapped behind proprietary APIs.

I'd rather earn your business.

If we eventually charge for managed execution, enterprise capabilities, observability, collaboration, support, or infrastructure that makes running Invariant at scale easier, those products should be worth paying for on their own.

The framework should still be useful without them.

---

Is That Really Open Source?

Technically, no.

And I don't want to play games with that definition.

ELv2 is a source-available license, not an OSI-approved open-source license.

That distinction matters.

I could call Invariant "open source" because the source is available and most developers can do almost everything they would normally want to do with it.

But people in the open-source community have spent decades defining what that term means. I don't think I get to quietly change the definition because another label would be more convenient for marketing.

So I'll call it what it is.

Invariant is source-available under ELv2.

But openness is still extremely important to me.

Especially for this kind of infrastructure.

If you're trusting Invariant with the execution of AI agents, I think you should be able to understand what it's doing.

You should be able to inspect how a workflow executes. You should be able to understand how state is persisted. You should be able to see what happens after a failure. You should be able to debug the runtime.

Infrastructure designed to make probabilistic systems more reliable shouldn't itself require blind trust.

---

Why Not MIT or Apache 2.0?

I considered permissive licenses.

And I understand why developers prefer them.

They're simple. They're familiar. And they give users enormous freedom.

Maybe Invariant's licensing model will evolve someday.

But I have to make decisions based on the project that exists today, not the company I hope might exist five years from now.

And today, Invariant is being built without the resources of a large company behind it.

MIT or Apache would give everyone maximum freedom, but that freedom would also extend to a well-funded organization taking Invariant and commercializing the framework itself as a managed service.

I'm not comfortable taking that risk right now.

More importantly, I'd rather establish that boundary now.

Before there are hundreds of contributors. Before businesses depend on Invariant. Before there's a large community whose expectations could be affected by a licensing change.

I'd rather tell you exactly what the deal is from day one than start permissively, build adoption, and pull the rug later.

---

What I Hope Invariant Becomes

I don't know exactly what Invariant will look like several years from now.

That's part of what makes this exciting.

Maybe it remains relatively small. Maybe other engineers find the same ideas useful. Maybe a community forms around it. Maybe companies start building serious systems with it. Maybe it eventually becomes the infrastructure company I can currently only imagine.

Whatever happens, I want to preserve a few principles:

1. Developers should be able to understand the infrastructure they depend on.
2. You should be able to build real commercial products with Invariant.
3. Self-hosting should be a real option.
4. The rules should be clear before people contribute their work.
5. And if Invariant creates real value, there should be a sustainable company capable of continuing to invest in it.

ELv2 isn't a perfect answer to the much larger debate around open source and commercial software.

It's just the tradeoff that feels right for Invariant today.

Maybe I'll look back at this post years from now and think differently.

That's okay.

Invariant itself started because I kept questioning how we were building AI systems.

I don't see why I should stop questioning the decisions around the company either.

For now, I want to put the work out there and see what people build with it.

— José Vásquez