License compatibility for procurement

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

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

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).

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

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/<sku>/ directory. The matrix view aggregates those for procurement convenience and is on the v1.x runway.

The 13 publishable SKUs:

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

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 for the full SCRM picture.

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

• Government & public sector landing
• Air-gapped architecture
• Supply-chain risk & SBOM
• Versioning
• Publishing contract