The licence stance: why no Enterprise Edition is a feature

A growing pattern in the open-source AI-infrastructure space, especially through 2025 and 2026, is MIT-plus-Enterprise-Edition: a permissive licence on most of the toolkit, with one or two directories carved out under a commercial-use-restricted licence, or behind a hosted-service requirement, or behind a paid subscription. The exemplar in 2026 is the production-multi-user auth slice of a popular TypeScript agent framework, but the pattern is everywhere: an Elastic License v2 on the operationally-load-bearing parts of an observability stack, a Business Source License on the multi-tenant features of a database, a "Cloud Edition" that requires authentication against a single vendor's hosted control plane.

Each of these choices is individually defensible. They are also, individually, the moment the project's commercial logic enters the toolkit and starts to shape what gets built next.

This is a short essay on why Beach is not going to do this, and why that absence is itself part of the position rather than an accident of priorities.

What the durability promise actually requires

Beach's central claim is that an application built on Beach survives protocol churn, vendor churn, and library churn because the application's shape — opaque interior, replaceable edges, interchangeable participants — does not depend on any of them. The promise to an adopter is, verbatim from the thesis:

Build your application with Beach. Its public face is every open protocol that matters today. Its outbound reach is every downstream protocol that matters today. When the standards change — and they will — Beach provides the adapter or plugin, and your application absorbs the change at the edge. Your domain logic, your participants, your routing, your data never move. You are permanently at the edge of the standard.

The honest second sentence of that promise is that it holds only as long as Beach itself does not become a thing the adopter has a commercial relationship with. The moment Beach has a paid slice — call it Enterprise Edition, call it Cloud, call it Premium, call it whatever — the architectural promise becomes a half-truth identical in shape to every framework Beach is positioned against. "No vendor relationship, no subscription, no monthly invoice" is structurally true only when there is no monetisation surface in the package set. The first commercial-use-restricted directory is the moment the surface exists.

This is not a slippery-slope argument about Beach getting greedy. It is an argument about what kind of project an Enterprise Edition makes a project become.

What an Enterprise Edition does to a project

Three things, all of them quiet:

It creates an internal incentive to leave gaps in the OSS package. Once a paid slice exists, the question "should this feature be in the OSS or in the Enterprise Edition?" has a commercial answer as well as a technical one. Even with the best intentions, the answer for any operationally-significant capability — production multi-user auth, audit, fine-grained policy, durable execution under load — drifts toward the paid side, because that is where the money is. The OSS package becomes adequate for the demo and inadequate for production, by design. Adopters who want a fully production-ready toolkit have to pay; adopters who refuse to pay have an OSS package that does not quite work for their actual use case.

It creates an external incentive to position competitors against the gap. Other projects respond to "OSS-but-pay-for-production" by building OSS-and-actually-free alternatives that occupy the gap. The original project's OSS surface starts to look thinner with each year as competitors fill the production-grade space the original chose to leave open. The original responds by either narrowing the OSS further (worsening the perception) or moving features back from the Enterprise Edition (eroding the commercial logic). Neither path is good for the adopter who chose the original on the strength of its OSS commitment.

It corrupts the architectural conversation about what belongs in the toolkit. Before Enterprise Edition, "should X be in the toolkit?" is decided on architectural grounds: does it belong in the interior, at the edge, or at the participant boundary? After Enterprise Edition, the same question carries a commercial overhead: does X belong in OSS, in the Enterprise slice, or in a new Cloud product? The architectural answer is often clearer than the commercial answer; teams that try to optimise for both end up making the architectural decision worse to support a commercial position that was not there in the first design conversation.

These are not failure modes of greedy companies. They are the predictable second-order effects of having a paid slice at all, regardless of how the slice is initially scoped. The cleanest evidence is that the same drift happens to projects with sincere maintainers and ungenerous ones.

Why Beach can hold this line

Two structural reasons, neither of them about ideology.

Beach's commercial model does not need a paid slice. Revenue for the contributing team comes from doing Beach-shaped work — consultancy engagements, implementations, products built on the shape — not from taxing other people's adoption. That is not a virtue; it is a different commercial model. The organisations closest to Beach's development earn by building with it, not by taxing others who do. When the toolkit gets used more, the organisations that build with it get more inbound work; that is the entire incentive loop. There is no scenario in which "ship better OSS" reduces the contributing team's income; there is no scenario in which "carve out a paid slice" increases it.

Beach's architectural commitments are inconsistent with a paid slice. The contribution policy and the invariant-review-criterion are not negotiable, by design — every CR is reviewed against them and refused if they would erode. The same posture applies to licensing: a CR proposing an Enterprise Edition surface would fail the wrap-don't-reinvent gate (G-001) on every test, because such a surface would necessarily duplicate something the OSS ecosystem already maintains under permissive licences (production-grade auth: Better Auth, Cerbos; observability: OTel collectors; durable execution: Trigger.dev, Hatchet, Temporal). The architectural answer is "wrap the OSS"; the commercial answer would be "build it ourselves and charge"; the wrap-don't-reinvent gate forecloses the commercial answer at the architectural layer.

These two together mean Beach is not relying on willpower. The model removes the incentive; the gate removes the path.

What this looks like in code

Concretely:

Every Beach package is published under MIT or Apache-2.0. Every one. The licensing decisions are codified at L-001, L-002, L-003 in the decision log. There is no Cloud Edition, no Enterprise Edition, no Premium tier, no commercial-use restriction, no separate paid SDK.
Beach wraps OSS under permissive licences (MIT, Apache-2.0, BSD, ISC, MPL-2.0; LGPL only when runtime-linked). It does not wrap AGPL, SSPL, Elastic License v2, BSL, or any package whose runtime requires authentication against a single vendor's hosted control plane. This is not a stylistic preference; wrapping a restrictive licence carries the restriction into every Beach consumer's deployment, and that contradicts the toolkit's licence stance.
When a layer Beach needs is only available in the OSS landscape behind an Enterprise Edition or Cloud-bound licence, Beach builds the OSS alternative directly. CAIB-138 (authorisation) is the canonical example: it is the OSS alternative to one popular framework's commercial-use-restricted auth slice. The investment is justified on architectural grounds (auth is universal infrastructure that belongs at the participant boundary) and on positioning grounds (Beach's "no Enterprise Edition" claim is a slogan until it has a concrete production-grade auth path that makes the slogan true).

What this is not

This is not a moral argument against the projects that have chosen the Enterprise Edition pattern. There are reasons to choose it; the most common is that the contributing team needs to be paid and there is no obvious other path. The pattern works for many adopters most of the time. The intellectual posture is not "these projects are bad." It is "the architectural promise Beach makes is incompatible with this pattern, and we are choosing not to make a promise we cannot keep."

It is also not a permanent commitment to a single licence text. MIT and Apache-2.0 are the current choice; if the Linux Foundation or another permissive-OSS-aligned home becomes the right governance umbrella for Beach later, the licence may move within the permissive set. What does not move is the commitment to no proprietary corner, no commercial-use restriction, no hosted-service requirement, no paid tier in the package set. That is the part the durability promise depends on.

Why now

Two reasons.

The pattern is becoming dominant. In 2026, the major OSS TypeScript agent frameworks either ship Enterprise Edition slices already, or they will when they commercialise. The "OSS-but-pay-for-production" model is being normalised, and adopters have started to assume it as the default. Stating the alternative explicitly — Beach has no Enterprise Edition and structurally cannot have one — has more value with each new project that adopts the pattern, because the audience that has been burnt by it grows.

The clarity is time-sensitive. Once an adopter has been told "the toolkit you are choosing has no paid corner; it has no commercial pressure on what gets built; the contributing team is paid by doing the work, not by taxing your work", the decision shape changes. They evaluate the toolkit against the right comparison. Without the explicit statement, they fold Beach into the same mental category as every other MIT-plus-Enterprise-Edition project and the architectural promise gets partly lost in translation.

The honest read

Beach's licence stance is not a marketing line. It is a structural property the rest of the architecture depends on. Adopters who have evaluated MIT-plus-Enterprise-Edition projects and felt the friction will recognise the alternative on sight; adopters who have not will not, and that is fine. The position is for the audience that already noticed.

If you have read this far and the argument has landed, the licence stance is the part of Beach's positioning you can take to your team without translation. "Their toolkit has no paid corner. Their commercial model does not require one. Their architectural commitments forbid one." That is the whole pitch.

Decision log entries: L-001, L-002, L-003, G-001, R-012.
Commercial positioning — the broader context for the licence stance, including the explicit "do not" list.
Pros and cons — the strategic-pros entry on no-Enterprise-Edition as a positioning asset, and the strategic-cons entry on the scale asymmetry the wrap-don't-reinvent gate is designed to absorb.