Frequently Asked Questions

OMLA is a license, not a platform. The product is the OMLA Public License — a legal document that gives commercial users a choice between releasing a derivative model or paying its creators. The registry and the resolver exist to make that license practical to comply with, but the license itself is what OMLA publishes and maintains.

Yes. OMLA Public License 2.1 is operative as of 2026-08-11. Models may now be validly licensed under it. See license.html.

The registry is a signed JSON file — one manifest per published model: who made it, what license it carries, and where to pay. The resolver is a small (roughly 600 lines, half of them comments and validation), deterministic, local-only function that turns a manifest and a revenue figure into an exact per-wallet payment. Neither runs on an OMLA server at request time — you read the registry and run the resolver yourself, on your own machine.

No. "Model" in the license means any generative AI model — language, image, audio, video, or anything else generative. The license, the manifest schema, and the resolver don't distinguish by modality; an image generator, a voice model, and an LLM are licensed and paid the exact same way.

Published academic research (at any size), personal projects, and — for entities under the $200K revenue floor — internal training, evaluation, and development of future models not yet offered commercially, so long as no revenue results. Free — nothing to pay, nothing to file (License §3). The one non-revenue case that still counts as commercial: internal use by an entity over the floor.

Two triggers: (a) use by an entity with more than $200,000 in trailing twelve-month revenue, measured at the entity level, or (b) any use — by an entity of any size — that directly monetizes the model's outputs or a derivative, for example selling API access to it. The revenue floor doesn't apply to trigger (b) (License §4).

Once per calendar quarter, no later than 60 days after quarter end, do one of two things: (a) publicly release your derivative's model weights, training code, and data recipe under the same license (copyleft), or (b) run the resolver and pay 30% of Applicable Revenue, split per the resolver's output, directly to each creator's payment pointer (royalty). You choose independently each quarter — choosing one in one quarter doesn't lock you into it later (License §5).

The greater of (a) gross revenue reasonably attributable to the model's or derivative's use, or (b) the cost of equivalent API inference for the same workload at prevailing market rates. That floor exists so "we made $0 in revenue" isn't an answer if you actually used the model (License §2, "Applicable Revenue").

The creator of a derivative declares the split in their signed manifest, and that declared split is what resolvers pay — recursively, through however many generations separate a derivative from the original creators (License §6). OMLA publishes suggested defaults: a fine-tune keeps 5%, a quantization 2%, a distillation or merge 10%, with the rest flowing upstream. They are recommendations, not caps — but every split is public, so a derivative that keeps far more than the suggestion does it in full view of its payers and its upstream creators. See a worked example.

A parent that never adopted OMLA can still be declared — it is recorded in the lineage as external:<source> for honest provenance, but receives no share: the license is opt-in and claims nothing from models that never joined.

Direct, wallet to wallet, over whichever payment pointer(s) the creator published in their Registry Manifest — a Lightning address, a Bitcoin, Ethereum, or Solana address, a Stripe payment link, a PayPal.Me link, or an invoicing URL. You compute the split yourself with the open resolver, then send it. OMLA is not a party to the transaction and receives no report that it happened.

No — never. OMLA is not a money transmitter, payment processor, or escrow agent, and is not a party to any payment between a licensee and a creator (License §7). That's true by design, not just by policy: there's no OMLA-operated payment infrastructure to touch it with in the first place. It publishes the split; you send the money yourself.

That's a "stack," not a lineage — none of the models is built from the others, they're just used together for one output. The 30% royalty is apportioned across every model in the stack by generation count and a declared weight (a base model or fine-tune defaults to full weight, a LoRA defaults to 10%) — it does not get charged again for each model, so total royalty on one output never exceeds 30% no matter how many licensed models contributed (License §2, "Applicable Revenue"). See the full worked example: a subscription split four ways — foundation model, fine-tuner, and two separate LoRA creators — down to the cent.

No. The obligation comes from the license, and the license is opt-in — a creator adopts it by publishing a signed manifest that says so. A model released under Apache-2.0, MIT, a Llama Community License, or anything else is governed by that license, not this one. OMLA makes no claim over models that never adopted it and will not start doing so. If you want to pay a creator who hasn't published a manifest, point them at the publish page — it takes a few minutes and gives you a clean licensing position.

Five steps: list the OMLA-licensed models your product ran and how many generations each combination served; collect their signed manifests and verify the signatures; work out 30% of the greater of attributable revenue or run cost; run the resolver to split it per wallet; pay each wallet directly within 60 days and keep the settlement sheet in your own files. The settlement calculator does steps 2–4 in your browser. Nothing is sent to OMLA at any point.

Check the signature. The creator's key signs a domain-separated message that includes manifest_hash — the SHA-256 of the canonical payees, pointers and split — so the signature covers where the money goes, not just the model's name. Change a payment address and verification fails. Paste any manifest into the verifier; it runs entirely in your browser, offline, against the published signing format.

Right now, you find a rail you both support, or convert manually before sending. OMLA is actively looking for a payment-rail partner — a plug-and-play service that converts between rails (Lightning, on-chain crypto, Stripe, PayPal, and so on) automatically, so a payer on one rail can settle with a creator who only published a pointer on another. OMLA itself will never operate that infrastructure — the no-custody rule doesn't bend — but a third party doing rail conversion between payer and payee is exactly the kind of tool this needs. If you build payment infrastructure, get in touch.

Work down publish.html: generate a signing key, generate a wallet address, tick the four safety certifications, fill in your model's details and lineage, and press sign. It produces a complete signed omla-manifest.json — you never write JSON by hand, and nothing leaves your device. Then publish that file next to your weights (model card, release page, repo), which is what actually puts your terms in front of a commercial user. Submitting it to the signed registry index is a separate, optional step and is still done by hand while the automated publish endpoint is gated.

Yes, and there are more than two now. Running today, entirely client-side: key generation (Ed25519, encrypted with a passphrase you choose), wallet-address generation (Bech32m omla1…), payment-pointer validation, the full manifest builder and signer, the signature verifier, and the settlement calculator. None of them makes a network call. What isn't live is automated submission into the registry index; that step is still manual.

About twenty fields: identity (name, description, source, weight hash), the license version, a signature binding the manifest to the creator's key, declared lineage or generation weight, the retained/upstream royalty split in basis points, four safety certifications, and one or more payee wallets with public payment pointers. Full schema at registry.html.

Four attestations every manifest must include: the model isn't designed for hacking, fraud, or other harmful use; it isn't designed for use by minors; it isn't designed to produce sexual content involving minors; and the creator took reasonable, good-faith steps to design and test against those outcomes before publishing. They're fields in the signed manifest itself, not a one-time form — see publish.html to certify and Terms §6.2 for the full text. OMLA does not audit models before listing them, for the same reason it doesn't audit IP ownership (Terms §6.1) — but unlike IP validity, this one category has a hard consequence if it's violated. See the next question.

Zero tolerance, no exceptions. A model that generates, or was insufficiently designed or tested against generating, child sexual abuse material is immediately delisted from the registry, its payment pointer is revoked so the resolver can no longer route royalties to it, and OMLA reports the manifest and everything it holds about the submission to the National Center for Missing & Exploited Children's CyberTipline and/or law enforcement — as required by 18 U.S.C. § 2258A where it applies, and voluntarily in any event (Terms §6.3). OMLA acts on a credible report before independent confirmation, given the severity of the harm. Report a suspected violation to contact@example.org.