# License compatibility for procurement (/docs/use-cases/government/license-compatibility) This page is for government procurement, contract counsel, and OSPO reviewers evaluating Pleach against an open-source license policy. The short version: **all 13 publishable `@pleach/*` SKUs ship under FSL-1.1-Apache-2.0**, which is source-available today and transitions automatically to OSI-compliant Apache-2.0 at the 2-year mark per the FSL future-license clause. ## License posture today [#license-posture-today] `FSL-1.1-Apache-2.0` is the Functional Source License v1.1 with Apache-2.0 as the named future license. Two properties matter for procurement: 1. **Source-available today.** The source is published on npmjs.org and mirrored on GitHub. Customers, contractors, and integrators may read, modify, and use the source for any non-competing purpose. 2. **Apache-2.0 transition is automatic and dated.** The FSL-1.1 clause specifies that each release transitions to the named future license (Apache-2.0) two years after that release was first published. There is no separate ceremony — the date is anchored to the publish date in npm. Per-SKU `LICENSE` files carry the full FSL-1.1-Apache-2.0 text and the specific publish date that anchors the 2-year clock for each release. ## What this means for procurement [#what-this-means-for-procurement] **Today (source-available):** * Read, modify, and run the source on government or contractor infrastructure. The FSL-1.1 grant covers all internal and operational use cases that a regulated buyer typically needs. * Audit the source against a security review board, an OSPO, or a third-party assessor. * Vendor a snapshot of `node_modules` for air-gapped install (see [Air-gapped architecture](/docs/use-cases/government/air-gapped-architecture)). **Two years after a given release publishes (Apache-2.0):** * That release is OSI-approved Apache-2.0 under the standard Apache patent and contribution grants. * No license re-negotiation or vendor sign-off is required for that release after the transition fires. * Government OSPO policies that explicitly enumerate Apache-2.0 as acceptable (most federal OSPO policies do) cover the release without exception. **FSL-1.1 carve-outs that procurement should know about:** * The "competing use" carve-out applies to running a hosted service that competes with Pleach itself. It does not restrict internal, operational, or government-program use. * The future-license clause is one-directional. Once a release transitions to Apache-2.0, the Apache grant is final for that release. ## Per-SKU license matrix [#per-sku-license-matrix] All 13 publishable SKUs ship under the same license today. The full list, with the publish date that anchors each SKU's 2-year transition clock, is intended to live in `LICENSE-MATRIX.md` at the repository root. **Honest scope note (2026-06-15):** the consolidated `LICENSE-MATRIX.md` file at the repo root is a tracked-but-unlanded punch list item. Today, the authoritative per-SKU license is the `LICENSE` file inside each `packages//` directory. The matrix view aggregates those for procurement convenience and is on the v1.x runway. The 13 publishable SKUs: | SKU | License | Source path | | ----------------------------- | ------------------ | -------------------------------------- | | `@pleach/core` | FSL-1.1-Apache-2.0 | `packages/core/LICENSE` | | `@pleach/compliance` | FSL-1.1-Apache-2.0 | `packages/compliance/LICENSE` | | `@pleach/compliance-contract` | FSL-1.1-Apache-2.0 | `packages/compliance-contract/LICENSE` | | `@pleach/gateway` | FSL-1.1-Apache-2.0 | `packages/gateway/LICENSE` | | `@pleach/eval` | FSL-1.1-Apache-2.0 | `packages/eval/LICENSE` | | `@pleach/replay` | FSL-1.1-Apache-2.0 | `packages/replay/LICENSE` | | `@pleach/mcp` | FSL-1.1-Apache-2.0 | `packages/mcp/LICENSE` | | `@pleach/coding-agent` | FSL-1.1-Apache-2.0 | `packages/coding-agent/LICENSE` | | `@pleach/tools` | FSL-1.1-Apache-2.0 | `packages/tools/LICENSE` | | `@pleach/base-tools` | FSL-1.1-Apache-2.0 | `packages/base-tools/LICENSE` | | `@pleach/react` | FSL-1.1-Apache-2.0 | `packages/react/LICENSE` | | `@pleach/observe` | FSL-1.1-Apache-2.0 | `packages/observe/LICENSE` | | `@pleach/langchain` | FSL-1.1-Apache-2.0 | `packages/langchain/LICENSE` | | `@pleach/recipes` | FSL-1.1-Apache-2.0 | `packages/recipes/LICENSE` | The `audit:sku-license-fsl-lock` gate at the repo root verifies all 14 locations (13 SKUs + the repo root) carry the canonical FSL-1.1 header. It runs on every PR and currently reports 18/18 clean (the extra 4 cover the reserved-namespace `@pleach/trust-pack` placeholder and the root + sub-license attribution files). ## SBOM and signed artifacts [#sbom-and-signed-artifacts] **Today:** build artifacts are produced by `tsup` and published with npm-default signatures. There is no SBOM emitted with the publish, and artifacts are not signed by Sigstore yet. **Roadmap (v1.x):** * SBOM emission in CycloneDX 1.5 or SPDX 2.3 format, attached to each npm publish. * Sigstore signing of the published tarballs. * SLSA Build Level 3 provenance attestation. The `governmentAgent` recipe accepts `sbomFormat` and `slsaProvenance` config fields and stamps them on the runtime as procurement-visible metadata, so a host that wires SBOM emission externally can still declare the intended format today. See [Supply-chain risk & SBOM](/docs/use-cases/government/scrm-and-sbom) for the full SCRM picture. ## Honest gaps [#honest-gaps] The following are tracked punch-list items, not shipped today: * **`LICENSE-MATRIX.md` at the repo root.** Per-SKU LICENSE files exist; the consolidated matrix view is v1.x. * **Per-SKU SBOM workflow.** No SBOM is emitted at publish today. * **Sigstore signing.** Not wired into the publish pipeline today. * **SLSA provenance attestation.** Not wired today. These are all paperwork-and-pipeline items, not architectural ones. The runtime and SKU layout already support them; the publish ceremony is what is missing. ## Related [#related] * [Government & public sector landing](/docs/use-cases/government) * [Air-gapped architecture](/docs/use-cases/government/air-gapped-architecture) * [Supply-chain risk & SBOM](/docs/use-cases/government/scrm-and-sbom) * [Versioning](/docs/versioning) * [Publishing contract](/docs/publishing-contract)