⬢ licensefoundry

For data infrastructure platforms

Build LicenseFoundry into
your platform.

Data labeling tools, storage platforms, data warehouses, dataset marketplaces: embed verifiable AI licence credentials directly into your customers' export, upload, and publish flows. Twenty lines of SDK. One sandbox key. Your customers' data lands at AI labs already credentialed.

Start integrating View example on GitHub

The asymmetric pitch.

Your customers care that their datasets travel with verifiable rights — because the labs they sell to increasingly care. You don't need to build a credential infrastructure to give it to them.

Today, "what rights do I have to train on this?" gets answered by a Slack thread between legal teams. Tomorrow, your customers' AI-lab buyers will expect a cryptographic answer at ingest time. The platforms that ship that answer by default win the procurement conversation that's coming.

LicenseFoundry is the trust layer. We sign the rights claim. You embed the signature step into your existing upload / export / publish flow. No new auth surface for your users. No infrastructure to operate. No crypto code to maintain.

Three integration patterns.

Pick the shape that maps to your platform. All three use the same SDK and the same call pattern — the differences are where the trigger fires and what metadata your platform already knows.

Pattern A

Storage platforms

S3, R2, MinIO, Wasabi, any object store. Fire on ObjectCreated. Hand the SHA-256 + metadata to onObjectUploaded(). Store the returned credential as a sidecar key.

~60 lines including imports. Working example: storage-bucket-hook.

Pattern B

Data labeling tools

Labelbox, V7, Encord, SuperAnnotate, Scale. Hook the "export labeled dataset" event. Credential carries the labeler's rights claim, the dataset's licence, and the customer's terms. AI labs verify offline before training.

Adapt Pattern A's handler — the export event has the same shape as an upload event (file + hash + metadata).

Pattern C

Data warehouses

Snowflake, Databricks, BigQuery. Issue a credential per table or per view. Granular rights per row group / partition. Downstream consumers verify table-level credential before running training queries.

Python SDK; DataFrame.to_credential() helper coming in the pandas-dataframe example (Q3 2026).

Twenty lines.

The integration shape that ships today. From the published @licensefoundry/sdk v0.1.2 on npm. See the full handler → 

import { LicenseFoundryClient } from "@licensefoundry/sdk";

const lf = new LicenseFoundryClient({
  baseUrl: "https://sandbox.licensefoundry.com",
  apiKey: process.env.LICENSEFOUNDRY_API_KEY!,
  acceptedIssuers: ["did:web:sandbox.licensefoundry.com"],
});

// Call this from your upload / export / publish trigger.
export async function onObjectUploaded(event: UploadEvent) {
  const asset = await lf.issuer.registerAsset({
    sha256: event.sha256,
    mediaType: event.mediaType,
    sizeBytes: event.sizeBytes,
    filename: event.key,
    /* sentinel fields — LicenseFoundry owns IPFS + anchoring */
  });
  return lf.issuer.issueCredential({
    assetId: asset.assetId,
    rights: { train: { granted: true }, commercial: { granted: false } },
    scope: { audience: "unrestricted", attribution: { required: true } },
  });
}

The returned credential is a signed JWT-VC. Store it as a sidecar at <key>.licensefoundry.json. Downstream AI labs fetch + verify offline in milliseconds against the cached JWKS at did:web:sandbox.licensefoundry.com.

Start integrating today.

Sandbox is live. Sign up takes 30 seconds. The example runs against real infrastructure in under 5 minutes from a clean clone.

  1. Sign in at app.licensefoundry.com via Google or GitHub. Free sandbox account, no credit card.
  2. Create a sandbox API key in the dashboard's API Keys section. The key starts with pcsbox_. Shown once — save it.
  3. Clone the example from sdks/ts/examples/storage-bucket-hook and run npm install && npm run demo with your key exported as LICENSEFOUNDRY_API_KEY.
  4. Verify the credential round-trip. The demo issues a credential, then verifies it offline using the same SDK. You see the actual signed JWT-VC and the valid: true result.

How the trust model works.

This is the most-asked question once an engineering team looks at the SDK seriously. Here's the honest answer, up front.

What LicenseFoundry signs

The integrity and timing of the credential itself. The signature proves a specific bundle of claims was issued under our key at a specific moment, and that nothing has been tampered with since. Downstream verifiers get that cryptographically.

We also operate the issuer identity (did:web:<domain>), the revocation infrastructure (Bitstring Status List v1.0), the JWKS publication, and the L2 anchor receipts. That layer is ours.

What the partner asserts

The truth of the rights themselves — that you actually have authority to grant the rights you ask us to sign. The truth of the hash — that the SHA-256 you pass actually corresponds to the bytes your customer uploaded.

This is the standard W3C Verifiable Credentials model. The signature attests to who said it and when, not to the truth of the underlying claim. Every VC ecosystem on earth works this way.

Practical consequence for your platform: the rights you assert via the SDK become a contractual representation in our MSA. Our standard partner agreement includes an "Attestations" clause covering both the content-hash and the rights-authority representations, plus mutual indemnification for misrepresentation. You are not signing up to assert things you can't substantiate — you're signing up to assert things you can.

And practical consequence for your customers: the example SDK ships with conservative deny-by-default rights — only viewing is granted unless your platform explicitly opts each upload into broader rights. This forces a deliberate decision per object (or per uploader-tier, or per dataset class) instead of blanket over-assertion. We strongly recommend keeping that posture; the example's README covers the override patterns.

For the deeper architectural picture — including the roadmap toward owner-declared rights manifests and issuance-time compliance scoring — see docs/compliance-scoring-framework.md and the broader vocabulary in docs/vocabulary.md.

What we're shaping with first partners.

Commercial mechanics are open because we'd rather design them with the first 2-3 partners than pre-impose terms. Things we'd talk through:

Rev share

Wholesale credential pricing for high-volume integrators. Your customers issue credentials at scale; you pay a discounted unit rate; we split the upside.

White-label

Customer-facing credentials issued under your domain (did:web:<your-platform>.com) instead of ours. Available behind the private_namespace capability — coming late 2026.

Co-marketing

Joint case studies. Customer references. Logo placement. The first 2-3 partners get joint launch announcements when they ship the integration to production.

Integration support

Direct engineering channel to our team during integration. Custom adapters for your event shape. SLA on technical response time during the pilot phase.

Talk to us.

We're targeting the first 3 production partner integrations in 2026. Earliest partners get input on commercials, roadmap priority, and the public launch narrative.

Email partners@licensefoundry.com View the example first

Outside the data infrastructure space? Reach us at info@licensefoundry.com instead.