# Redistribution rights (/docs/use-cases/isv/redistribution-rights) This page is the technical answer to "can my customer's procurement team approve a product that embeds Pleach?" Short form: yes, under [FSL-1.1-Apache-2.0](/docs/versioning), commercial bundling and re-sale are permitted by license terms. The longer form covers which SKUs ship under which license, what changes at the 2-year transition, and the gaps between LICENSE-level permissions and an actual ISV master agreement. ## The license [#the-license] Every shipping `@pleach/*` SKU is published under **FSL-1.1-Apache-2.0** — the Functional Source License version 1.1 with Apache License 2.0 as the future license. Two properties matter for ISV embedding: * **Commercial use is permitted today.** FSL-1.1 specifically allows commercial use, including bundling Pleach into a commercial product and re-selling that product to your own customers. The restriction in FSL-1.1 is on **competing products** — you cannot take Pleach, fork it, and sell it as a competing agent runtime. Embedding it inside a CRM, a vertical SaaS, an analytics tool, a developer product, or any other non-competing offering is in-scope. * **Apache 2.0 transition is automatic at +2 years.** Two years after first stable publish of any given version, that version's license transitions to Apache License 2.0 automatically. No re-licensing ceremony, no separate agreement — the future-license clause inside FSL-1.1 carries the transition. This is why the SPDX identifier is `FSL-1.1-Apache-2.0` rather than just `FSL-1.1`. For most ISV embedding scenarios, the FSL-1.1 commercial-use permission is sufficient on day one. The 2-year clock matters mostly for procurement teams that prefer to see a recognized OSI-approved license on a roadmap. ## Per-SKU LICENSE files in the tarball [#per-sku-license-files-in-the-tarball] Every published tarball carries its own LICENSE and NOTICE file. The structure is uniform across all 13 source-bearing SKUs: ``` node_modules/@pleach// ├── LICENSE # FSL-1.1-Apache-2.0 full text ├── NOTICE # Copyright notice ├── package.json # license: "FSL-1.1-Apache-2.0" ├── README.md └── dist/ ├── index.cjs ├── index.js └── index.d.ts ``` The license-file presence is regression-locked. Every PR runs `audit:sku-license-fsl-lock` — it walks the publishable SKUs, verifies the `package.json:license` field, checks for canonical LICENSE byte-identity, confirms NOTICE files are present, and fails if any SKU drifts off the FSL-1.1-Apache-2.0 baseline. ISVs can rely on the license posture being stable across releases without re-auditing. ## Your obligations when embedding [#your-obligations-when-embedding] The FSL-1.1-Apache-2.0 license imposes three lightweight obligations on embedders. None are bespoke to Pleach — they're standard for permissive-ish licenses: * **Preserve the LICENSE file.** Don't strip `node_modules/@pleach//LICENSE` when you package your product. Standard `npm publish` / `pnpm pack` / webpack bundler behavior preserves it; you'd have to actively delete it to drop it. * **Preserve the NOTICE file.** Same as above. The NOTICE file carries the upstream copyright notice and any required attribution text. * **Surface FSL-1.1-Apache-2.0 in your third-party software disclosure.** Most enterprise customers' procurement teams ask for a "third-party software list" with each entry's license. Include `@pleach/` rows with their declared license. That's the complete embedder obligation set under v1. ## What's NOT yet shipped [#whats-not-yet-shipped] The README + LICENSE-level mechanics above let ISVs embed today. What's not yet shipped: * **`LICENSE-MATRIX.md` aggregator.** A single document enumerating every `@pleach/*` SKU with its license, intended audience, and redistribution notes. Today the per-SKU `package.json:license` fields are the source of truth; the matrix doc is roadmap. * **`LEGAL/ISV-MASTER-AGREEMENT-TEMPLATE.md`.** A pre-drafted master agreement that ISVs can use as a starting point for bespoke negotiations. Today every ISV deal that needs more than LICENSE text is negotiated one-off. * **`LEGAL/ISV-REVENUE-SHARE-ADDENDUM.md`.** Pre-drafted revenue-share terms for FSL-licensed SKUs that downstream Pleach maintainers continue to develop. Roadmap. * **`LEGAL/ISV-CO-MARKETING-ADDENDUM.md`.** Pre-drafted co-marketing terms (joint case studies, conference co-sponsorship, logo placement). Roadmap. * **`scripts/audit/license-clarity.ts`.** A CI gate that cross-checks every SKU's declared license against an authoritative matrix and fails on drift. Today the `audit:sku-license-fsl-lock` gate covers the FSL-1.1 uniformity check; the broader per-SKU clarity audit is roadmap. If you're an ISV who needs any of these before signing, the honest answer is the same as in the parent page: tell us. The templates are punchlist items with non-trivial legal-review costs; they ship faster with concrete deals attached. ## The 2-year Apache 2.0 transition [#the-2-year-apache-20-transition] The future-license clause in FSL-1.1 reads (paraphrasing): two years after the publication date of a given software version, that version is also made available to the public under the designated future license. The designated future license for every `@pleach/*` SKU is Apache 2.0. Practical consequences for ISV embedding: * **No re-licensing ceremony is required.** The transition is automatic. The same FSL-1.1-Apache-2.0 LICENSE file in the tarball is also a grant of Apache 2.0 at +2 years for that version. * **The Apache 2.0 grant is per-version, not global.** When `@pleach/core@1.0.0` hits its 2-year anniversary, the `1.0.0` version transitions to Apache 2.0. The currently shipping `1.x.y` releases remain on FSL-1.1 until their own 2-year anniversaries roll around. * **There is no separate Apache 2.0 license cut planned.** Earlier scoping considered cutting `@pleach/core@1.0.0` directly under Apache 2.0 to give ISVs that prefer Apache-only an unambiguous entry point. That plan was reverted (see `docs/d-pa-9-license-revert-2026-06-14.md` in the repo); the future-license clause is the canonical transition path. ## Per-SKU snapshot [#per-sku-snapshot] All 13 source-bearing publishable SKUs ship under FSL-1.1-Apache-2.0 today: | SKU | License | Redistribution notes | | ----------------------------- | ------------------ | -------------------------------------------------------------------------------------------------- | | `@pleach/core` | FSL-1.1-Apache-2.0 | The agent runtime substrate. Required by every embedded deployment. | | `@pleach/compliance` | FSL-1.1-Apache-2.0 | HIPAA / GDPR / SOC 2 / PCI-DSS scrubbers. Embed if your customers are regulated. | | `@pleach/compliance-contract` | FSL-1.1-Apache-2.0 | Zero-dep contract sub-SKU. Auto-pulled by `@pleach/core` + `@pleach/compliance`. | | `@pleach/gateway` | FSL-1.1-Apache-2.0 | Multi-tenant gateway, BYOK, cost events. Embed if you mediate provider routing for your customers. | | `@pleach/replay` | FSL-1.1-Apache-2.0 | Replay-deterministic regression and fork. Embed for evals shipping with your product. | | `@pleach/eval` | FSL-1.1-Apache-2.0 | Eval lab, benchmark loaders, divergence reporting. | | `@pleach/mcp` | FSL-1.1-Apache-2.0 | MCP-compatible transport. SDK-free pluggable handlers. | | `@pleach/coding-agent` | FSL-1.1-Apache-2.0 | File/diff/exec tools + sandbox facade. | | `@pleach/tools` | FSL-1.1-Apache-2.0 | Tool-authoring helpers. | | `@pleach/base-tools` | FSL-1.1-Apache-2.0 | Curated base tool set. | | `@pleach/react` | FSL-1.1-Apache-2.0 | React bindings + `` + hooks. | | `@pleach/observe` | FSL-1.1-Apache-2.0 | OTel + structured-row observability. | | `@pleach/langchain` | FSL-1.1-Apache-2.0 | LangChain adapters (Checkpointer, Provider, Store). | | `@pleach/recipes` | FSL-1.1-Apache-2.0 | Use-case-targeted composition recipes. | `@pleach/trust-pack` is a reserved namespace today — a `0.0.1` placeholder is published but there is no source-bearing release yet. Future trust-pack releases ship under FSL-1.1-Apache-2.0. ## Related pages [#related-pages]