ISV (embedded vendor)

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

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 — 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/<sku>/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

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

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.

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:

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.

That is the full v1 ISV compliance surface.

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

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