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, 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

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

Every published tarball carries its own LICENSE and NOTICE file. The structure is uniform across all 13 source-bearing SKUs:

node_modules/@pleach/<sku>/
├── 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

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/<sku>/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/<sku> rows with their declared license.

That's the complete embedder obligation set under v1.

What's 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 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

All 13 source-bearing publishable SKUs ship under FSL-1.1-Apache-2.0 today:

@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