Licensing

Every Amnetic listing is sold under a license — the terms that say what a buyer may do with the data. By default a listing sells under its standard terms (the frozen platform defaults) at the listing's price_cents. Sellers can also publish additional priced licensing tiers — an offer ladder — so a buyer can pay more for broader rights (commercial use, model training, redistribution within their org) or less for a narrower grant.

Availability. The priced-offer surface is gated behind LICENSE_TERMS_ENABLED and is pending counsel review — not yet GA. Where the flag is off, the licensing MCP tools and the .../license-offers REST routes are simply absent (404-by-absence) and every listing sells under its standard terms.

The Data Standard License (DLS)

The platform's current default composition is a provisional quote-integrity input, not a settled interpretation of model training or any other operative right under ToS §5.3. That interpretation remains pending counsel review. DLS-1 is the draft instrument version used by the dark composed-offer work; it is not yet a GA claim that the standard tier is governed by a ratified DLS. Until quote and settlement transition together after counsel approval, standard quote evidence remains pinned to the pre-ratification tos/5.3-draft instrument. A composed offer records its instrument version when it is composed, so a later grant's meaning is fixed at purchase time and cannot be rewritten under a buyer's feet.

The rights themselves are expressed as a terms composition over a small, frozen vocabulary (schema lts/1): a set of named dimensions, each taking one option from a closed list. There are no free-form terms — this is what lets the market compare, price, and reason about grants, and what keeps the agent-facing surface an enum, not an injection vector.

The terms dimensions

An offer's terms is a { dimension: option } map. You supply only the dimensions you want to change; every omitted dimension takes its platform default, and the stored composition is always fully materialized (every dimension explicit).

Dimension	Options (narrow → broad)	Default	Meaning
`use`	`non_commercial` \| `commercial`	`commercial`	Whether the data may be used commercially.
`redistribution_scope`	`individual` \| `entity` \| `entity_affiliates`	`entity`	How widely, within the buyer's own organization, the data may be shared. External redistribution is never an option.
`derived_display`	`none` \| `public`	`none`	Whether derived features/analytics may be displayed publicly.
`training`	`none` \| `internal`	`none`	Whether the data may be used to train models (internal to the buyer).
`training_serve`	`none` \| `allowed`	`none`	Whether a model trained on the data may be offered as a service. Requires `training: internal`.
`training_weights`	`none` \| `allowed`	`none`	Whether trained model weights may be distributed. Requires `training: internal`.
`term`	`perpetual` \| `12` \| `24` \| `36`	`perpetual`	Use term in months (a closed set — no arbitrary integers).
`attribution`	`required` \| `not_required`	`not_required`	Whether the buyer must attribute the source.
`exclusivity`	`none` \| `exclusive`	`none`	Reserved. Exclusive grants are not sold in v1 — composing `exclusive` is refused.

training_serve and training_weights are peers, not a ladder — each is a separate election on top of training: internal, and composing either without training: internal is a hard error. A composition that exactly equals the platform defaults is refused as an offer (the standard terms are already offered virtually — see below), so every priced tier is a genuine departure from default.

Offer keys

Each tier carries a seller-chosen offer_key — a short, stable slug matching ^[a-z0-9][a-z0-9_-]{0,31}$ (e.g. internal_training, wide_commercial). It is the human-facing name of the tier and is stable across re-pricing. standard and default are reserved — they name the listing's virtual default tier, which is never a materialized offer row — so you cannot use them as an offer_key.

There is a configurable per-listing cap on the number of live composed offers (MAX_LICENSE_OFFERS_PER_LISTING, default 8, valid range 1–64), and within a listing every live offer must have a distinct offer_key and a distinct terms composition — the live offer set is a function, not a bag.

Stored prices for both the standard listing tier and composed tiers must be nonnegative 32-bit integers. Composed tiers always pin an embedded DLS version; the pre-ratification Terms of Service discriminator is reserved for the virtual standard tier and cannot appear on a composed offer. Deployments also audit that no existing listing exceeds 64 active composed offers before enabling these backstops; if one does, migration stops and reports the listing and count for explicit operator reconciliation rather than retiring offers automatically.

Accept the licensing terms first (server-stamped)

Composing offers publishes legal instruments that bind you, so before your first compose your account must accept the current licensing Terms of Service. This acceptance is server-stamped: the server records the version in force at the moment you accept — a client can never supply or assert a version. This is what makes the acceptance real consent evidence rather than a value any tool could mint.

You record acceptance in the same call that composes your first offer set, by passing accept_licensing_terms: true (on set_license_offers, the inline create-block, or the portal). It is idempotent — a no-op once your account has accepted. If you compose without having accepted, the call is refused:

{ "error": "licensing terms acceptance required",
  "code": "licensing_terms_acceptance_required",
  "required_version": "tos/5.3-draft",
  "instrument_url": "https://amnetic.ai/terms" }

Retire-all (composing an empty offer set) needs no acceptance.

Composing offers

There are three ways to compose a listing's offer ladder, all routed through the one server-side compose chokepoint (same validation, same server-stamped gate):

MCP — set_license_offers replaces the full live offer set (replace-set semantics); get_license_offers reads it back. See the MCP tools reference.
Inline at create time — the create_listing MCP tool and the REST POST /api/v1/seller/documents / /files / /datasets create paths accept an optional license_offers block, so a listing is born with its ladder in one call. See Selling data and the API reference.
Portal — the seller portal's listing editor (where enabled).

Composing is replace-set, not a patch: you send the full desired live set. Unchanged entries keep their ids and versions, a repriced or recomposed entry gets a new versioned row, dropped entries are retired, and an empty list retires all.

A composed offer reads back with its offer_id, offer_key, terms, terms_schema_version (lts/1), dls_version (DLS-1), price_cents, currency, status, and a settlement token — plus any non-fatal coherence warnings (for example, a strictly broader tier priced at or below a narrower one). Warnings never block a compose; they surface pricing that a buyer would find incoherent.

Discovering public offers

Every public listing includes license.standard.token, even while priced offers are disabled. That is the binding dv1: quote token the buyer can echo as expect_token for a standard purchase; it changes if the standard price or governing instrument changes.

When LICENSE_TERMS_ENABLED is on, public listing reads also include the fully materialized provisional standard composition (terms) and price_cents, the lts/1 schema version, and the live composed offers with their ids, keys, terms, prices, currencies, and tokens. offers is [] when none are live. When the flag is off those additive fields are absent and only the standard token remains. This is a dark, pre-ratification surface pending counsel review, not a representation that the displayed default composition settles training rights or that priced offers or DLS-1 are generally available.

The same enabled projection is attached to each enter_market recommended_listings[] entry after the forgetful agent returns its bounded listing-id verdict. This gives the outer buyer agent the offer_id and token to echo into a later explicit purchase without allowing the inner agent to author license data. This is provisional pre-purchase quote metadata, not the operative license text, a grant, a debit, or acceptance. A separate dark phase adds the exact pre-purchase text path described below; do not purchase from the enum metadata alone without reading that operative text. Buyers may also pass a non-empty, closed-enum required_rights object with minimums for any of the eight requestable dimensions (all dimensions above except exclusivity). For each recommendation, the platform compares those minimums against the already-visible ladder and attaches rights_fit.band (fit, partial, no_fit, or unknown). Only fit carries best_offer: composed fields are copied from the selected visible ladder entry, while standard normalizes its terms/price/token with listing currency and a null id. Cheapest fit is deterministic by price, then standard before composed, then composed offer id. This is mechanical fit computation, not legal advice, permission, warranty, operative text, acceptance, or a grant.

Without a non-empty requirement, recommended_total_cents remains the sum of standard listing prices and preserves its historical omitted-all-zero wire. With requirements active, it instead sums current best_offer prices; non-fit rows contribute zero and an all-zero total is emitted explicitly. The number is advisory only—no funds or rights are reserved. This surface is available only in non-production flag-on environments and remains absent in production pending counsel ratification.

For an open public listing, read the exact operative text before buying with GET /api/v1/listings/{listingId}/license-text/{offerKey}. Use standard for the virtual tier or an active composed key advertised in license.offers. The response repeats the resolved terms, schema and instrument versions, hashes, price, currency, and settlement token beside the hash-verified stored text; composed offers also include their immutable offer_id. Responses are never cacheable (Cache-Control: no-store) because a seller may retire and re-compose the same key—bind your decision to token. The route is absent while licensing is off, and hidden listings or unavailable keys return opaque 404s.

This is availability evidence, not a legal conclusion. Counsel still needs to confirm that assembled machine-readable terms and purchase-as-acceptance are sufficient, and whether eligible buyers of restricted listings require a separate authenticated pre-purchase text path before GA.

In-wall offer discovery

The forgetful buyer agent sees the full quotable ladder when it examines a listing. get_listing adds a non-empty top-level license_offers array without changing its listing_id input. The virtual standard tier is always first and uses offer_id: null; active composed tiers follow in stable order. The array contains at most 65 entries (one standard plus the shared ceiling of 64 composed):

{
  "license_offers": [
    {
      "offer_id": null,
      "offer_key": "standard",
      "terms": { "use": "commercial", "redistribution_scope": "entity", "derived_display": "none", "training": "none", "training_serve": "none", "training_weights": "none", "term": "perpetual", "exclusivity": "none", "attribution": "not_required" },
      "price_cents": 4500,
      "currency": "usd",
      "token": "dv1:…"
    }
  ]
}

This buyer-safe projection deliberately omits schema/DLS versions, row status, and evidence documents. Terms are the closed lts/1 vocabulary above, not seller prose. Hidden, inactive, self-owned, or ACL-ineligible listings remain opaque. The inner agent still returns only listing ids; the outer recommendation ladder is a separate platform-side read of current public/authorized offer metadata, so seller content and inner-agent prose never gain a new egress channel.

Buying a composed tier

A buyer selects a tier at purchase time. The purchase tool accepts offer-aware items instead of bare listing ids:

{ "items": [ { "listing_id": "…", "offer_id": "…", "expect_token": "…" } ] }

REST POST /api/v1/purchases accepts the same selectors as top-level fields beside listing_id. Both REST and MCP also support funding_mode card modes for a single listing; card mode returns a hosted Stripe checkout URL and grants the license only after webhook settlement.

offer_id selects a composed tier; omit it to buy the listing's standard terms.
expect_token optionally asserts the exact quote you saw — if the offer changed since, the item is refused (price_changed) rather than charged at a new price.
renew_of_grant_id renews an existing grant on the same terms.

Each completed purchase returns its offer_id, offer_key, terms_hash, and a grant_id (the evidence record of the license you now hold), and an outcome of purchased or already_licensed (buying a tier you already hold is reported, not double-charged). Offer-level refusals return a structured error_code (offer_unavailable, price_changed, or renewal_invalid) with the listing id and detail; offer_unavailable includes the current live offers so the buyer can re-select.

For a rights-fit recommendation, echo both rights_fit.best_offer.offer_id (omit/null for the standard tier) and rights_fit.best_offer.token as expect_token. Settlement re-resolves the selector and token; the quote is stale-assertion metadata, and only the minted grant is license evidence. On the asynchronous card rail, post-payment drift can produce funded_only: the money remains spendable, nonwithdrawable wallet credit and no license grant is minted.

MCP tools reference — set_license_offers, get_license_offers, and the purchase items surface.
Selling data — composing tiers as a seller, including the inline-on-create shortcut.
API reference — the REST .../license-offers sub-resource and the inline create block.