# ISV (embedded vendor) (/docs/use-cases/isv) This page is for independent software vendors who want to embed Pleach into a commercial product and ship it to their own customers under their own brand — Salesforce-style CRM add-ons, HubSpot AI features, vertical SaaS products that include AI as part of their core value proposition. If you're using Pleach internally — even at scale, even on a multi-tenant SaaS surface — the [multi-tenant SaaS agent](/docs/multi-tenant-saas-agent) page is the more direct fit. ISV-embedded specifically means **redistribution** — your customer pays you, you pay nobody for the embedded engine, and Pleach travels with your product into your customer's deployment. ## What v1 supports today [#what-v1-supports-today] ISVs can embed every `@pleach/*` SKU into their commercial product as of v1.0.0. The mechanics are: * **License.** Every shipping SKU is published under [FSL-1.1-Apache-2.0](/docs/versioning) — the Functional Source License with Apache 2.0 as the future license. FSL-1.1 permits commercial use including bundling and re-sale; the Apache 2.0 transition fires automatically two years after first stable publish. * **Source availability.** Every package's source lives in the monorepo at `packages//src/` and ships in the published tarball so customer security reviews (SCRM, SBOM, attestation) can read what they're running. * **LICENSE + NOTICE in every tarball.** Each SKU carries its own `LICENSE` + `NOTICE` file inside the published package (locked by `audit:sku-license-fsl-lock` running on every PR). * **No call-home, no telemetry.** Nothing the runtime does reaches back to a Pleach-controlled endpoint. The runtime is a library, not a service. * **Provider neutrality.** Your customers can point the embedded engine at whichever providers they've already contracted (Anthropic, OpenAI, Bedrock, Vertex, Azure, a private gateway). Your product doesn't have to mediate the inference contract. That's the v1 surface. If your embedded shape needs only those properties, you can ship today. ## What v1 does NOT include [#what-v1-does-not-include] Three things ISVs commonly ask for that v1 does not yet deliver — they're roadmap, not shipped: * **LTS branch.** v1 is rolling-release; minor versions ship roughly monthly. There is no `v1.x` long-term-support branch with backports. See [LTS roadmap](/docs/use-cases/isv/lts-roadmap) for the v2+ plan. * **24/7 dedicated support tier.** Bootstrap-stage maintainers cannot credibly commit to 24/7 SLAs. Support today is best-effort community + GitHub issues; a paid support tier is v2+ contingent on hiring a support organization. * **Signed ISV master-agreement template.** v1 ships under the FSL-1.1-Apache-2.0 LICENSE text alone. There is no pre-drafted master agreement, revenue-share addendum, or co-marketing addendum. ISVs negotiating bespoke terms — volume pricing, revenue share on FSL-licensed downstream SKUs, co-branding rights — are doing it one-off through email until those templates ship. If any of those three are non-negotiable for your deal, v1 is not the right entry point. The honest answer is "wait for v2 or talk to us about a custom arrangement." ## Quickstart — ISV embedding [#quickstart--isv-embedding] The mechanics are the same as any other Pleach project. The ISV distinction is in the LICENSE compliance you carry through to your customer, not the install command. ```bash npm install @pleach/core @pleach/react # Add whichever SKUs your embedded product needs: npm install @pleach/observe # if you instrument npm install @pleach/compliance # if your customers are regulated npm install @pleach/gateway # if you mediate inference for them ``` Inside your product, build the runtime as you would for any other deployment: ```typescript import { SessionRuntime } from "@pleach/core"; export function buildEmbeddedRuntime(req: YourRequest) { return new SessionRuntime({ provider: yourCustomerProvider(req), storage: yourCustomerStorage(req), plugins: [yourEmbeddedPlugin], tenantId: req.endCustomerTenantId, // your customer's customer }); } ``` When you publish your commercial product, three LICENSE-side obligations travel with it: * Preserve `LICENSE` + `NOTICE` from every embedded `@pleach/*` tarball. The files are already in the tarballs; don't strip them. * Surface the FSL-1.1-Apache-2.0 license in your own product's "third-party software" disclosure (most customers' procurement teams ask for one). * Honor the Apache 2.0 transition at +2 years per [redistribution rights](/docs/use-cases/isv/redistribution-rights). That is the full v1 ISV compliance surface. ## When you need an actual master agreement [#when-you-need-an-actual-master-agreement] Some commercial relationships need more than LICENSE text — for example: * You want volume pricing on `@pleach/gateway` or `@pleach/observe` because your product makes millions of inference calls per day. * You want a revenue share on FSL-licensed SKUs that downstream Pleach maintainers continue to develop. * Your customer wants Pleach-signed indemnification or a vendor contract showing a direct relationship with the upstream maintainers. * You want co-marketing — joint case studies, joint conference presence, logo placement. These conversations are bespoke today. Reach out via the contact channel in the README of any `@pleach/*` package on npm. The master-agreement template, revenue-share addendum, and co-marketing addendum are tracked as v2 deliverables; until they ship, every ISV deal is negotiated one-off. ## Roadmap — what v2+ adds [#roadmap--what-v2-adds] The v2+ scope for embedded ISVs is built around three deliverables: * **LTS branch infrastructure.** Annual `v1.x` LTS cuts with 24-month security backport windows. See the [LTS roadmap](/docs/use-cases/isv/lts-roadmap) for the full cadence and SLA plan. * **Dedicated support tier.** A paid support contract with named contacts, on-call rotation, and SLA-backed response times. Requires Pleach to hire a support organization (year 3+ scope). * **`EmbeddedRuntime`.** A variant of `SessionRuntime` with no module-level state, optimized memory footprint, and a faster cold start path. Designed for ISVs whose product instantiates many concurrent runtimes per process. Today, `SessionRuntime` is single-instance-friendly but not zero-module-state. The `EmbeddedRuntime` work is scoped but not started. If you have a use case that depends on any of the above, the honest framing is: tell us. The v2+ plan compresses if there's demonstrable demand. ## Related pages [#related-pages]