Frequently Asked Questions

Summary of the OMLA License

Non-commercial use: Free and unrestricted — research, personal projects, internal R&D, academic work.

Commercial use: Pay 30% of the greater of (i) attributable revenue or (ii) total model run cost to the model creators.

Who pays: The party operating or selling access to the OMLA-licensed model. End users do not pay separately if the service already pays OMLA royalties.

Cascading splits: A single payment to a model's omla1… wallet automatically splits upstream through the lineage to all contributing creators.

General

Why does OMLA exist?

Short version: open-model creators kept finding their work inside somebody else's product and getting exactly zero dollars for it. We watched it happen to friends. So we built a licensing framework where the money goes back up the chain automatically.

Longer version: open models are a public good, but the economics don't work for the people doing the open work. Training is expensive, maintenance is unglamorous, and commercial users who benefit rarely have a clean way to say thank you even when they want to. OMLA gives you: free access for non-commercial use, one flat rule (30% of the greater of revenue or run-cost) for commercial use, and cascading payouts so every upstream creator gets paid when a downstream derivative succeeds.

What is OMLA?

The Open Model Licensing Association is a Washington state nonprofit. It provides a royalty-based license for AI models: free for personal/research use, 30% royalty for commercial use. The association maintains the registry, wallet routing system, and compliance framework.

Is this open source?

Open access, not OSI open-source, because royalties are required for commercial use. The model weights can be freely used, modified, and redistributed for non-commercial purposes. Commercial use requires the 30% royalty payment to creators.

Wallets & Addresses

What is an OMLA wallet address (omla1…)?

An OMLA wallet address is a globally unique routing identifier encoded in Bech32m format (the same encoding used by Bitcoin SegWit v1). It starts with the prefix omla1 followed by 38–58 lowercase alphanumeric characters.

Example: omla1qq0emf5v8xgs5gwtk4gec7fy5k7spvgc8q3m2

The address encodes a 32-byte model UUID. When someone pays this address, the OMLA system: (1) looks up the model in the registry, (2) calls the split resolution algorithm, (3) routes the appropriate percentage to each creator and upstream model via their configured payment rail (Stripe, PayPal, Lightning, ACH, SEPA, or Wise).

Creators never need to share their actual payment credentials publicly — the omla1… address is the only public-facing identifier.

What payment rails are supported?

Supported payment rails: Stripe Connect, PayPal, Lightning (Bitcoin), ACH (US bank transfer), SEPA (EU bank transfer), and Wise. Additional rails may be added as the system matures.

When a payment is routed, the system selects the least-cost rail that both the payer and payee support. Transfer fees are deductible up to 10% of the royalty amount.

Can I use a non-OMLA payment method?

Yes. If you list a non-OMLA wallet (e.g., a direct crypto address, ACH details, or PayPal email) in your model entry, licensees must use that method if they are able to transact with it. OMLA does not mediate, escrow, or enforce non-OMLA payments — the creator-specified method is used directly.

Commercial Use & Royalties

What counts as commercial use?

Commercial use is any use for monetary gain or advantage, including:

  • Hosted APIs or products that charge for access
  • Internal operations that yield material business benefit
  • Selling or monetizing outputs generated by the model
  • Advertising-supported services
  • Fundraising or sponsorships
  • Using the model to enhance the value of another product or service (e.g., a tour company using AI for narration)

Not commercial use: academic research, personal projects, internal R&D, development of future OMLA-licensed models.

How is the 30% royalty calculated?

The royalty is the greater of:

  1. 30% of attributable revenue — revenue directly attributable to the model (sales, subscriptions, API calls, output sales)
  2. 30% of total model run cost — the accounting cost to operate the model (pro-rated compute, storage, bandwidth, hardware depreciation, direct IT support)

You compute both figures and pay whichever is larger. If hardware is fully depreciated, there is no support cost, and there is no attributable revenue, the base can be $0.

For pipeline systems (multiple models), split royalties by declared contribution percentages. Free/non-OMLA components reduce the royalty base proportionally.

How do I pay?

Send payment to the model's omla1… wallet address using any supported payment rail. The OMLA system automatically splits the payment to all creators and upstream models. Payments are due quarterly; the minimum per-wallet threshold is $0.10 USD.

Do I owe royalties for outputs?

If you monetize outputs substantially generated by the model (sell images, sell text, etc.), that constitutes Commercial Use of the model and triggers the 30% royalty. The license does not apply to or transfer to the outputs themselves — only to the use of the model to generate them.

What happens if someone uses a model without paying?

Anyone may file a complaint with OMLA. Upon receiving a valid complaint:

  1. OMLA notifies the user within 24 hours
  2. The user has 24 hours to respond
  3. Continued non-payment may result in the entity being added to the quarterly blacklist
  4. Blacklisted entities are published publicly each quarter

OMLA is not a law enforcement body — the license creates contractual obligations, and enforcement is ultimately through legal channels and reputational consequences.

Cascading Splits

How does the cascading split work?

When Model C is derived from Model B, which is derived from Model A, a single payment to Model C's wallet cascades through the entire lineage DAG:

  1. Payment arrives at Model C's wallet
  2. Model C declares contribution weights (e.g., 40% flows to Model B)
  3. That 40% reaches Model B's pool; Model B declares its own lineage weights (e.g., 50% flows to Model A)
  4. So Model A receives 40% × 50% = 20% of the original payment

The algorithm (a recursive CTE in PostgreSQL) traverses the entire lineage graph and produces a flat terminal split table — one row per creator wallet with their final percentage.

How do I verify a model is OMLA-licensed?

Check the OMLA registry at omla-ai.org/registry. Search by model name or look up by SHA-256 weight hash. Registered models have:

  • A unique omla1… wallet address
  • An Ed25519 public key proving creator identity
  • A SHA-256 hash anchoring the specific model weights
  • A compliance state (REGISTERED, REPORTING, COMPLIANT, DELINQUENT, or BLACKLISTED)

You can also add OMLA-ID: omla1… to your model card or README and email verify@omla-ai.org for verification.

Compliance

What is the compliance state machine?

Every model in the OMLA registry has a compliance state that tracks its payment history:

  • REGISTERED — Model is registered; no commercial use reported yet
  • REPORTING — Commercial use has been declared and reports are being submitted
  • COMPLIANT — Reports verified and payments confirmed
  • DELINQUENT — Missed quarterly payment deadline (30 days past quarter end)
  • BLACKLISTED — 90 days in DELINQUENT with no resolution; published on quarterly blacklist

State transitions are automatic based on report submissions and payment verifications. UNDER_REVIEW is an additional state for entities under active investigation.

Publishing Models

Do I have to open source my fine-tune?

No. You can keep your fine-tune private. The OMLA License only requires royalty payments for commercial use — it does not mandate open-sourcing of derivative weights or code.

How are derivatives handled?

Declare upstream models and contribution weights when you register. Self-attribution is limited by the contribution weights you declare. Relationship types include: fine-tune, merge, distillation, quantization, and derivative.

Payments & Security

What currencies can I use?

Supported payment rails include fiat (Stripe, ACH, SEPA, PayPal, Wise) and crypto (Lightning/Bitcoin). Royalty amounts are denominated in USD for reporting purposes. Minimum per-wallet payout is $0.10 USD or equivalent.

How do you handle security?

Security measures include: Ed25519 signature verification on model registration and report submission; Bech32m-encoded wallet addresses (tamper-evident); row-level security policies on the Supabase database; append-only audit log of all mutations; bcrypt-hashed API keys for commercial users (never stored plaintext).

Examples

Subscription server revenue share (Bob — $1/user/month)

Scenario: Bob serves only OMLA-licensed models and charges $1/user/month.

Result: $1 × 30% = $0.30 per user owed to model creators.

Internal model server — cost basis (Corporation X)

Scenario: Hardware $200k over 2 years (=$100k/yr) + $100k/yr direct support; no attributable revenue.

Royalty basis: Annual run cost = $200k.

Result: $200k × 30% = $60,000 per year owed.

Image generation — per-token sales

Scenario: $0.10/token × 1,000 tokens = $100 model revenue.

Result: 30% × $100 = $30 owed.

Fine-tune on MIT base — contribution share by compute

Scenario: Base training = 2,000 GPU-h; creator's fine-tune = 500 GPU-h.

Share: 500 ÷ (2,000 + 500) = 20% of royalties from this model.

Example: If royalties total $10,000 → creator receives $2,000.

Influencer bot — revenue uncertain → compute-cost basis

Scenario: Bot's monthly compute cost = $5,000; sales attribution unclear.

Result: 30% × $5,000 = $1,500/month owed.

Hosted service covers royalties for users

Scenario: Jenny pays a site $20/month; the site pays OMLA royalties.

Result: Jenny owes $0; the site pays based on its revenue/compute.

Cloud GPU rental — royalty on rental cost

Scenario: $1,000/month GPU rental to run an OMLA-licensed model for a commercial app.

Result: 30% × $1,000 = $300/month owed.

LoRA add-on — creator % and platform payment

Scenario: Base model training = 900 GPU-h; LoRA training = 100 GPU-h.

Creator share: 100 ÷ (900+100) = 10% of royalties.

Example: If compute spend = $50,000 → royalty = $15,000; LoRA creator gets $1,500.

User buys credits; commercial use of outputs — who pays?

Scenario: Alex buys $50 in credits on SiteY and uses images in paid ads.

Result: SiteY owes 30% of $50 = $15; Alex owes no separate royalty if SiteY pays.

Multi-model subscription platform — apportionment

Scenario: $100/month subscription; OMLA model contributes ~50% of value.

Royalty basis: Attribute $50 to OMLA model.

Result: 30% × $50 = $15 per user/month. Keep a short apportionment memo.

Invalid wallet complaint flow — process

Flow: Anyone may file → OMLA notifies within 24h → if non-payable/invalid and unremedied, share set to 0% until fixed (others continue) → appeals reviewed within 7 days (extendable by notice). Reinstatement is prospective.

Derivative with free component — apply only to covered portion

Scenario: 70% free, 30% OMLA. Revenue $1,000 → OMLA base $300 → royalty $90. Free components reduce the royalty base.

Payment routing with high transfer fees — deduction limit

Rule: Deduct reasonable routing/conversion fees up to 10% of the royalty. If one rail costs ~15%, choose an alternate method or document the route.

Internal tool — no clear revenue → cost/value basis (saved labor)

Scenario: Saved labor = 100 hrs × $50 = $5,000 value; no attributable revenue.

Result: 30% × $5,000 = $1,500 royalty. If truly no cost/value basis (fully depreciated hardware, no support, no value), base may be $0.