Blog
June 14, 2026Licensing

Why @pleach/core flipped from FSL to Apache-2.0 in ten days

On 2026-06-04 we argued for FSL-1.1-Apache-2.0. On 2026-06-14 the v1.0.0 cut shipped under plain Apache-2.0. Three reasons we changed our minds.

byPleach maintainers· @pleach/core

The short version

@pleach/core@0.1.0 ships under Apache-2.0 — permissive, OSI-approved, no conversion clock. The earlier 0.0.1 placeholders shipped under FSL-1.1-Apache-2.0; the v1.0.0 cut replaces that with plain Apache-2.0 across every @pleach/* package (2026-06-14).

Ten days before the cut, this exact post argued the opposite — that the substrate needed a two-year non-compete window before converting to Apache. The argument is preserved below as the foil. The flip isn't a walk-back of the underlying concern; it's a different read on which mechanism actually carries the load.

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 means for you

Three concrete shapes, refreshed from the prior version:

  • You're shipping a customer-facing product on top of @pleach/core. Apache covers it. No non-compete clause to read; no two-year window to plan around. The license your scanner already recognizes is the license the package ships under.
  • You're a regulated buyer whose questionnaire requires a permissive license. Every @pleach/* v1.x publish satisfies the requirement directly. There's no oldest-stable-release workaround to walk procurement through.
  • You're a contributor. PRs are welcome on the upstream repo; the contribution agreement on each @pleach/* package follows the same Apache-2.0 grant the package ships under.

Where to read more

licenseApache-2.0reversal