Your product sits on a mountain of open-source. Can you give me a bill of materials, and can you tell me there's no copyleft license in your stack that could contaminate your proprietary code — or, by extension, complicate our vendor diligence?

The full executive answer

Yes to the bill of materials, with receipts: every CI build generates a CycloneDX SBOM — the industry-standard machine-readable inventory of every package and version in the product — retained as a build artifact with cryptographic provenance attestation, so what we hand your diligence team is generated from the actual shipped build, not a manually maintained list that drifted. That SBOM includes license metadata per component, which means your team — or an M&A acquirer's, which I suspect is the experience behind the question — can run their own license analysis against ground truth rather than our summary.

On copyleft: our own code is proprietary (the package manifest is explicitly marked as unlicensed/all-rights-reserved), and the dependency stack is the mainstream commercial JavaScript ecosystem — Next.js, React, the Supabase and payment SDKs, the AI provider SDKs — which lives almost universally under permissive licenses (MIT, Apache-2.0, BSD, ISC) precisely because that ecosystem is built for commercial embedding. Two precision points a good review will appreciate: first, we're a server-side SaaS, which means even weak-copyleft components would generally not trigger distribution-based obligations — the classic GPL "contamination" mechanics attach to distributing software, which SaaS doesn't do (that's the AGPL's reason for existing, and AGPL components are what a SaaS review actually hunts for); second, the honest gap — we do not yet run an automated license-policy gate in CI that would block a future developer or transitive dependency from introducing a copyleft package. Today that's covered by the SBOM's auditability and the ecosystem's norms; a blocking license-allowlist check is a small, planned addition to the Security workflow alongside this year's SOC 2 readiness work.

So the diligence offer is concrete: current SBOM with license fields this week, refresh at any milestone you choose, and — if your team finds anything questionable in the transitive tree — we treat it as a P1 to replace, which in the npm ecosystem is typically a same-week swap. For your own vendor-diligence file, that's a cleaner position than most mature vendors, whose SBOMs are annual archaeology rather than per-build artifacts.