BrandVideoAI

What each vendor's terms say about commercial use

How a permissions page is built, and where it narrows

These pages describe the shape of a terms document rather than any one vendor's. The shape repeats across the industry, and knowing it makes a single page readable in minutes. As of 2026-09-12.

The order a permissions document is usually written inA broad grant appears early, a definition of the qualifying plans appears in the middle, and the carved-out categories appear near the end. Reading in printed order produces an impression that the last section withdraws, which is why the sections are best read backwards.The broad grantYou may use outputscommercially.Written to be quotedin marketing.Then narrowQualifying plansWhich subscriptionsthe grant covers.Often defined onanother pageentirely.Then narrowagainCarve-outsPolitical, medicaland likenesscategories, listednear the end.
Fig. 1 The generous sentence is at the top and the binding one is at the bottom, on almost every page of this kind.

The pattern is consistent: a broad grant near the top, a definition of the plans it applies to somewhere else entirely, and a list of carved-out categories near the bottom. Reading in the printed order gives a generous impression that the last section quietly withdraws.

Free tiers are where the narrowing is sharpest. A free plan that permits personal use and nothing else is common, and the word personal is almost never defined in the same document that uses it.

The carve-outs matter for anyone selling to regulated buyers. Political advertising, medical claims and likeness of real people appear in most of these documents, in wording close enough to be recognisable and different enough to matter.

1The explainers

  • Changing plan — Permissions attach to a plan. Moving between plans raises questions about material already produced that the plan table does not answer.
  • Reading terms — Commercial-use answers are spread across four kinds of page that can disagree. Reading them in the wrong order produces a confident wrong answer.
  • Clearing a deliverable — A generated deliverable gets the same questions every time. Having the answers written down before they are asked is most of the work.
  • Licence vs ownership — Vendor permission to use output commercially is one question. What rights exist in the finished work is another, and pricing pages answer only the first.
  • The production file — A short list of things to note at generation time so that a question about rights, two years later, has an answer that does not depend on memory.
  • Asking for a sentence — Most gaps in a permissions record close with one short email. What to ask for, what to avoid asking, and what to do with the reply.
  • A supplier file — What to keep about each generation supplier so that a rights question can be answered in an afternoon rather than reconstructed from memory.
  • Which account — Why the login and the legal entity that signed up can decide a rights question, and what to settle before a project starts rather than after.
  • Input logs — Why the input side of a pipeline carries most of the rights exposure, what a usable log contains, and why prompt text sometimes counts as an input.
  • Briefing a freelancer — What a brief has to say so that generated material arrives with a permission the client can rely on, and the three sentences that do most of the work.
  • Contract mismatch — Why a standard clause promising all rights in a deliverable collides with generated material, and the schedule that resolves it.
  • Regulated sectors — Why an acceptable use policy can rule out a campaign that passes every licence test, and which categories to check before commissioning anything.
  • Archiving exports — Why a finished file carries no evidence of the permission it was made under, and what a delivery log has to hold to stand in for that.
  • Changing vendor — Which parts of a rights position travel with a production when the tooling changes, and which have to be rebuilt from nothing.
  • Running weights — Self-hosting swaps a subscription for a licence file and moves the monitoring, the obligations and the responsibility onto the team running it.
  • Consent paperwork — What a usable release says when a person's likeness or voice is used in generated video, and why scope and dates matter more than signatures.
  • Labels and disclosure — Why disclosure rules about generated material come from platforms and regulators rather than suppliers, and why they change on a different clock.
  • A rights pass — A short pass over the rights position before committing to a series, in the order that finds the expensive problems first.

Nothing in this section is legal advice; it is a guide to where a given document keeps its answers.

Also on the grid: Products, Fields, Records, Pairs, Questions, Words, Data. What makes a clause quotable is set out on the reading page.

2A generator's account of it

Alongside the terms behind “Learn”, SceneMixer's guides describe the work itself this way:

The terms grant you the output to the extent the law allows, and that includes commercial use.

SceneMixer, What You Get to Keep — “Do I own the copyright in what I generate?” (read 2026-10-13)

A dish photo is cleaned into a product shot and the ad is built around it.

SceneMixer, An AI Ad for a Restaurant, a Café or a Dish — “Will the dish look like my dish?” (read 2026-10-13)