Why we argued for Apache-2.0 in ten days — and reverted the same day

Correction

This post does not describe current status. On 2026-06-14 we announced a flip of @pleach/core to plain Apache-2.0 — permissive, OSI-approved, no conversion clock — and reverted it the same day. Every @pleach/* package, at every release since, ships under FSL-1.1-Apache-2.0: source-available, free in production, auto- converting to Apache-2.0 two years after first stable publish. See the FAQ or versioning for the current, accurate license terms.

The reasoning below is preserved as a record of the tradeoffs debate that day, not as a description of what shipped.

The short version

This post argued for moving @pleach/core to plain Apache-2.0 for the (then-upcoming) v1.0.0 cut. Ten days earlier, an initial version of this same post had argued the opposite — that the substrate needed a two-year non-compete window before converting to Apache. That earlier argument is preserved below as the foil this post was written against. Neither read shipped as final: the Apache flip argued for here was announced and reverted the same day, and FSL-1.1- Apache-2.0 is what every release actually carries.

What we argued on 2026-06-04

The prior version of this post made three claims:

1. The runtime contract — sessions, the 4-stage lattice, family-locked routing, the audit ledger keyed on (sessionId, turnId, stageId, seqWithinTurn), replay determinism — represents years of work. Apache from day one would let someone fork the brand and ship a hosted Pleach service substituting for the original distribution.
2. The FSL two-year clock is short enough to be plannable, long enough for the substrate to stabilize before conversion. The conversion is automatic, encoded in the license text, dated per release in package.json under pleach.fslConversionDate.
3. Calling the result "open source" before conversion would conflict with the OSI definition. "Fair source" was the honest framing during the window.

That reasoning is internally consistent. It's also wrong about which axis is load-bearing for this codebase, in three places.

Three things that changed

1. The substrate's defensibility was never the resale clock

The prior post asked: what stops someone from running a hosted Pleach service? The answer it reached was "the FSL non-compete clause for two years." The answer the license review reached — by walking through every defensible axis individually — is that the resale clock was the weakest lever in the set.

What protects the work isn't a license restriction. It's operational hosting, retention SLAs, the SOC 2 wrapper, signed audit retention, per-tenant evidence pack export, and the agent-runtime-specific axes the rest of the field doesn't carry (the AuditableCall row shape, subagentDepth, tenantId as a routing primitive). A fork of the substrate doesn't substitute for any of that. A license clause can't manufacture it.

Once the substrate and the hosted products are two surfaces instead of one, the substrate's job is to be trustworthy. Apache makes that simpler to verify.

2. The non-compete clause has a real cost for the buyer who picks Pleach

The buyer cluster that evaluates @pleach/* seriously isn't the one who'd fork it. It's a mid-market SaaS team running a procurement questionnaire. That reviewer reads FSL-1.1-Apache-2.0 in the SBOM output, doesn't recognize the SPDX identifier, opens the license text, sees a non-compete clause, and routes the question to legal. Legal asks for a memo. The memo takes a week.

The conversion-in-two-years clause doesn't reach that reader, because their question is about today. Plain Apache-2.0 is the SPDX identifier their scanner already knows. The procurement path shortens from "open a ticket" to "no action needed."

This isn't hypothetical. The same review surfaced that every adjacent LLM-routing comparable — Vercel, OpenRouter, Cloudflare's gateway, Portkey, LiteLLM, Helicone — ships permissive licenses. Procurement reviewers have learned to expect that shape. Deviating from it adds friction without adding revenue protection.

3. The trust commitments survive better under Apache

Four substrate commitments are load-bearing for this site: no telemetry phone-home, no remote license check, no account required to run the runtime, and no retro-paywall on already-published bytes.

The fourth one is the relevant one here. Under FSL, the no-retro-paywall promise depends on the conversion clock running on schedule — a reader has to trust that the date in pleach.fslConversionDate will actually arrive, and that the license header won't be re-cut on a future release. Under Apache, the same promise is structural: every published tag is irrevocably Apache on its bytes from the moment it ships. There's no clock to trust, because there's no clock.

Plain Apache is the simpler implementation of a commitment we were making either way.

What this actually means for you

The flip above didn't ship. What follows is the real, current shape:

• You're shipping a customer-facing product on top of @pleach/core. It ships under FSL-1.1-Apache-2.0 — source- available and free to use in production today, with a non-compete clause on competing hosted offerings only. See the FAQ for what the clause does and doesn't restrict.
• You're a regulated buyer whose questionnaire requires an OSI-approved license. FSL-1.1-Apache-2.0 isn't OSI-approved during the pre-conversion window; each release auto-converts to Apache-2.0 two years after first stable publish. See versioning for the conversion mechanics.
• You're a contributor. PRs are welcome on the upstream repo; the contribution agreement on each @pleach/* package follows the license that package actually ships under — FSL-1.1-Apache-2.0.

Where to read more

• FAQ — the current license question, answered directly: FSL-1.1-Apache-2.0, not Apache-2.0.
• Pricing — the two-surface frame: the substrate is free and fair-source (FSL-1.1-Apache-2.0); the hosted products are enterprise products.
• Versioning — the current per-package version and license table.