Licence stance — three decisions and one operational rule
The 2026-04-30 external-review bundles surfaced licence policy as Beach's most distinctive positioning differentiator, increasingly so as the OSS-vs-source-available landscape destabilises through 2025–2026 (HashiCorp → BSL, Elastic → ELv2 then back to AGPL, MongoDB → SSPL, Mastra/Langfuse/Novu/Infisical adding ee/ directories of varying restrictiveness). Beach is one of very few credible projects in the AI infrastructure space that has not added a monetisation surface to its OSS licence.
This document records the three load-bearing licence decisions and the operational CR-review rule that enforces them.
L-001 — Beach is and remains MIT/Apache-2.0 throughout
Status: Confirmed. Decision date: 2026-04-30. Decision maker: John Andrew, four-stakeholder convergence.
Question: Should Beach add an ee/ directory or any source-available / proprietary slice (now or in any future evolution)?
Decision: No. Beach's published packages are MIT or Apache-2.0 throughout. No ee/ directory in any Beach-published package, ever. No source-available corner, no production-restricted feature, no paid-licence-required path.
Reason: The licence stance is part of the positioning, not separate from it. Adopters who choose Beach over Mastra / Langfuse / Novu / Infisical are choosing it for the absence of an ee/. Adding one — even years from now, even for "advanced features" — converts Beach's "no vendor relationship, no subscription, no monthly invoice" positioning into a Mastra-shaped half-truth. The cost of holding the line is real (Beach is consultancy-funded; cannot fall back on subscription revenue) but the payoff — an audience of adopters and architects who have actively shopped for a project without an ee/ — is a real and growing market.
Operational consequences:
- Beach's
LICENSEfile declares MIT and Apache-2.0 throughout. The repository contains noee/directory now and never adds one. - Future Beach packages inherit the same licensing.
- A CR proposing to add an
ee/directory or a paid slice is rejected without override. There is no architect override path; the rule is structural.
L-002 — Permissive licences Beach adapter packages may wrap
Status: Confirmed. Decision date: 2026-04-30. Decision maker: John Andrew, four-stakeholder convergence.
Question: What licences may Beach adapter packages wrap, given Beach adopters need to redistribute Beach-built applications without imposing licences their customers cannot accept?
Decision:
| Licence | Verdict | Conditions |
|---|---|---|
| MIT | Adopt freely | None |
| Apache-2.0 | Adopt freely | None |
| BSD-2 / BSD-3 | Adopt freely | None |
| ISC | Adopt freely | None |
| PostgreSQL Licence | Adopt freely | None |
| MPL-2.0 | Context-dependent | OK as external tool / service (sops, OpenBao); care with embedded library |
MIT + ee/ boundary (Mastra-style) |
Adopt with explicit ee/ exclusion |
Document the boundary in adapter README; CR-review check verifies no import path includes ee/ |
| MIT + proprietary EE (Novu-style) | Adopt only the MIT core | Document the fully-proprietary boundary; never wrap the EE part |
Reason: Adopters of Beach must be able to redistribute their Beach-built applications under licences their customers can accept. Permissive licences (MIT / Apache-2.0 / BSD / ISC / PostgreSQL Licence) impose only attribution; MPL-2.0 is per-file copyleft and works for tools / external services but needs care for embedded libraries. The ee/ boundary in Mastra-style projects is enforceable only if Beach adapters are explicit about excluding it.
Operational consequences:
- Every Beach adapter package's CR review verifies the wrapped library's
LICENSEfile before approval. - Adapter README declares the wrapped library's licence prominently and any
ee/exclusion explicitly. - An adapter wrapping MPL-2.0 code embedded in a Beach package requires an architectural justification that the per-file copyleft is acceptable for the use case.
L-003 — Licences Beach adapter packages may NOT wrap
Status: Confirmed. Decision date: 2026-04-30. Decision maker: John Andrew, four-stakeholder convergence.
Question: What licences are off-limits for Beach adapter packages?
Decision: Beach never wraps:
| Licence | Examples to avoid |
|---|---|
| AGPL-3.0 | Hanko (base AGPL), Permify (AGPL), Stack Auth server (AGPL) |
| SSPL | Inngest server (SDK Apache-2.0; server SSPL — substitute Trigger.dev or Hatchet) |
| Elastic v2 (ELv2) | Phoenix (Arize) — substitute OpenLLMetry, OpenLIT, Langfuse OSS |
| BSL 1.1 | HashiCorp Vault post-1.14 (substitute OpenBao); Restate server (substitute Trigger.dev or Hatchet) |
| No LICENSE file | Any package missing a LICENSE — verify before wrapping |
| Fully-proprietary EE (Novu-style) | Wrap only the MIT core |
| Cloud-bound (permissive file licence, runtime cloud dependency) | @mastra/auth-cloud, @mastra/deployer-cloud, Composio runtime, Spectrum's iMessage / WhatsApp Business providers |
Any future ee/ directory |
Rule applies to any directory named ee/ regardless of which package it appears in |
Reason: Each of these licences imposes constraints incompatible with Beach's redistribution promise:
- AGPL — network-distribution clause requires source disclosure; Beach adopters' customers cannot accept this.
- SSPL — not OSI-approved OSS; the "service-as-a-software-substitute" clause has been judged non-OSS. Self-hosting commercially is restricted.
- ELv2 — source-available, not OSS; three production-use restrictions.
- BSL — source-available with delayed-conversion-to-OSS (typically 4 years); effectively non-OSS for the lifetime of Beach's CR cycle.
- No LICENSE — no permission granted to use, modify, or distribute.
- Fully-proprietary EE — production use forbidden without paid licence; Beach's positioning forbids dependencies that force adopters into commercial agreements.
- Cloud-bound packages — the package's
LICENSEmay be permissive but the package requires authentication to a commercial cloud at runtime. Beach's "no vendor relationship, no subscription" stance forbids this regardless of file licensing. - Any
ee/directory — the licence is directory-based, not package-based. The rule extends to any futureee/paths in any wrapped library.
Operational consequences:
- Adapter CRs proposing to wrap any of the above are rejected without override.
- The licence-and-path audit (see operational rule below) is the structural enforcement mechanism.
- If a previously-permissive library migrates to a forbidden licence (a real risk through 2025–2026: Cal.com discussed AGPL, Sentry moved to FSL), Beach pins the last-permissive version, names the dependency in the adapter's documentation, and considers an alternative substrate.
Operational rule — every adapter CR review includes a licence-and-path audit
The above three decisions are honoured in principle only if there is a structural enforcement mechanism. The rule:
Every adapter-package CR review includes a licence-and-path audit:
- Confirm every imported package's LICENSE file. Read the file directly; do not infer from the package name or repository description.
- Confirm no import path includes
ee/or any directory containing AGPL / SSPL / Elastic v2 / BSL / fully-proprietary / no-LICENSE code. Walk the import graph; the rule applies transitively, not just at the top level.- Confirm no wrapped package requires runtime authentication to a commercial cloud to function. A permissive file licence is not sufficient if the package fails-closed without a cloud subscription.
- Confirm any
ee/exclusion is documented in the adapter README. The boundary is enforceable only if it is named explicitly.
Without that explicit framing, the rule risks being honoured-in-principle, drifted-in-practice. A specific check codifies it. TA flagged this need at the 2026-04-30 convergence; all four stakeholders agreed the audit must be a written gate, not assumed discipline.
If a CR cannot satisfy all four checks, it is rejected. There is no override path; the rule is structural.
Why this matters — and where Beach's distinctive position comes from
Three patterns make Beach's licence stance noteworthy in 2026:
- No
ee/of Beach's own. Mastra has one. Langfuse has one. Novu has one (and worse). Infisical has one. Beach explicitly does not. This is a positioning differentiator that has cash value. - MIT with no monetisation surface. Beach's commercial positioning rules out hosted services, VC funding, and feature-gating. The licence stance is the legal expression of the commercial commitment. They have to remain coherent — a project that takes VC money typically has to add an
ee/to satisfy the board. - Adapter packages, not core dependencies. The pattern of "wrap permissive OSS as optional adapter, leave the core invariant-independent" is Beach's structural answer to the licence question. Adopters who want Mastra take the Mastra adapter; adopters who don't, don't. Beach's core licence stance never bends to accommodate either choice.
The licence stance is not separate from the architectural discipline. It is the legal-engineering expression of the same discipline that produces the router-and-manifest invariant, the no-domain-logic-in-Beach commitment, and the adopt-vs-build gate. Each is a refusal to let convenience erode the contract that makes Beach valuable.