Asset licensing goes wrong in a specific and expensive way: everything looks fine until the game
ships, and then a takedown arrives. Almost every case comes from one of four misunderstandings.
This covers all four, in the order they tend to bite.
“Royalty-free” does not mean free
Royalty-free describes the payment structure, not the price. It means you pay once and
owe nothing per copy sold. It says nothing about whether the asset was free, or whether you may use
it commercially at all.
The permission you actually need is a commercial use licence. An asset can be:
- Free and commercially licensed — you may ship it, cost nothing
- Paid and royalty-free — you pay once, ship freely
- Free but non-commercial — you may learn from it, not sell with it
- Paid but revenue-capped — permitted until your game earns over a stated threshold
Those last two are where projects get into trouble, because the asset was acquired legitimately
and the restriction was in a paragraph nobody re-read.
The four licences you will actually meet
| Licence | Commercial use | Attribution | The catch |
|---|---|---|---|
| CC0 / Public Domain | Yes | Not required | None, legally. But verify the uploader had the right to release it. |
| CC-BY | Yes | Required | Credit must be visible in the shipped product, not only on a website. |
| CC-BY-NC | No | Required | NC means non-commercial. A free game with ads still counts as commercial. |
| CC-BY-SA | Yes | Required | ShareAlike. Derivatives must carry the same licence — usually incompatible with a commercial game. |
Marketplace licences (Unity, Fab, itch.io) are their own thing and generally permit commercial use
with no revenue cap and no attribution. They restrict a different axis: redistribution.
You may ship the asset inside your game; you may not put it in a pack and sell it on, and usually you
may not hand the raw files to a contractor outside your team.
Attribution: where people get it wrong
CC-BY is the most common licence on free asset sites and the most commonly breached, because the
requirement is not what people assume. Credit must be in the work itself. A line on
your studio website does not satisfy it.
What works: a credits screen inside the game, a CREDITS.txt shipped in the build, or
an in-game settings page. What is expected in each entry: the creator’s name, the asset title, the
licence, and ideally a link to the source.
The practical habit is to keep a spreadsheet from the first day of the project — asset, source,
licence, date, URL. Reconstructing this at ship time, across two years and four hundred files, is
where projects lose weeks.
The one that catches almost everyone: music and streamers
This is worth its own section because it is the most expensive surprise in the list, and it feels
like a bug rather than a licence issue.
You buy a music track. The licence clearly permits commercial use in your game. You ship. A month
later, streamers playing your game start receiving copyright claims on their videos, and some of them
stop playing it.
Nothing went wrong with your licence. Two separate rights are involved:
- Your licence covers using the track inside your game. That is intact.
- YouTube’s and Twitch’s Content ID systems match the audio inside the streamer’s
recording. If the rights holder registered that track with Content ID, the system flags it
— and it neither knows nor cares that the streamer is playing your game.
Three ways to avoid it. Look for music explicitly marked stream-safe or
DMCA-free. Ask the composer directly whether the track is registered with Content ID
— a one-line email that saves a launch. Or ship a “streamer mode” audio option that swaps the
soundtrack, which is cheap to build and turns the problem into a feature.
AI-generated assets
Increasingly relevant and still unsettled. Two practical points, independent of where the law
lands.
First, several marketplaces now require you to disclose AI-generated content when
submitting a pack, and undisclosed AI content is grounds for removal. Second, in a number of
jurisdictions purely AI-generated output may not be copyrightable at all — which means you may not be
able to stop someone reusing it, and you may not be able to licence it exclusively to anyone.
If you are buying: check the pack’s disclosure. If you are selling: disclose, and keep records of
your process.
Before you ship: a five-minute check
- Every asset traced. Each one has a source, a licence and a date in your
spreadsheet. Anything you cannot trace should be replaced, not risked. - No NC or SA licences in a commercial build. Search your list for both.
- Attribution shipped in the build, not only on your site.
- Revenue caps checked. If any licence has a threshold, note it and diarise it —
crossing it quietly is still a breach. - Music checked for Content ID, or a streamer-mode option in place.
- Licence files kept. Save the PDF or receipt for every paid asset. A marketplace
can change its terms; your copy of what you agreed to is your evidence.
How these go wrong in practice
Four situations that come up repeatedly, and what each one actually costs.
The contractor problem
You buy a marketplace asset, then bring in a freelance artist to modify it. Most marketplace
licences are granted to a single entity and permit use by people working for that entity on
its projects — but several draw the line at handing the raw source files to an outside party.
The practical read: check whether your licence covers contractors before you send files. Where it
does not, the usual remedy is for the contractor to hold their own licence, which is cheap and settles
it. Marketplace terms differ enough here that assuming is genuinely risky.
The team-seat problem
Unity and Fab licences are per-seat in most cases. One purchase covers one developer using the
asset. A team of five needs five, or a licence tier that says otherwise.
This is widely ignored and periodically enforced. It also matters at exit: acquisition due diligence
routinely audits asset licences, and unlicensed seats become a line item that delays or reprices a
deal.
The revenue-cap problem
Some licences — particularly for engine plugins and middleware — permit use until the product passes
a revenue threshold, after which a different tier applies. The threshold is usually generous enough to
feel theoretical when you are signing.
The failure mode is not malice, it is memory. Nobody re-reads a licence three years later on the
week the game does well. If any asset you use has a cap, record the number in your audit sheet and set
a calendar reminder well below it.
The redistribution problem
This one is unambiguous across essentially every marketplace: you may ship an asset inside your
game, and you may not distribute it in a form that lets someone else extract and reuse it.
Where this catches people out is not deliberate piracy. It is shipping a modding SDK, publishing a
project template, open-sourcing a game with its art still in the repository, or handing a complete
project folder to a publisher. All four redistribute the raw asset. All four need either permission or
a stripped build.
Reading a licence in five minutes
You do not need to read every clause. Search the document for these six terms and read the
paragraph around each:
- “commercial” — is commercial use permitted at all, and is a free-with-ads product
treated as commercial? - “attribution” or “credit” — required, and if so where must it appear?
- “redistribute” — what forms of onward distribution are prohibited?
- “revenue” or “threshold” — is there a cap?
- “seat”, “user” or “per developer” — how many people does one purchase cover?
- “terminate” — what happens to shipped games if the licence ends? A good licence
says your existing releases remain licensed.
That last one is more important than it looks. If a licence can be terminated in a way that affects
games already shipped, you have a dependency you cannot control.
Keeping the evidence
Save, for every paid asset: the receipt, the licence text as it read on the day you bought it, and
the date. A PDF print of the licence page is enough.
Marketplaces update their terms. If a dispute ever arises, the question will be what you agreed to
at the time of purchase, and the only reliable copy of that is the one you kept. This takes seconds per
asset and is the single cheapest piece of legal protection available to a small studio.
Music, sound and the rights nobody splits
Audio carries more separable rights than art does, and licences are often vague about which ones you
received. Three worth checking explicitly.
Synchronisation. The right to pair the audio with moving images — which is what a
game does. Most game-audio licences grant this, but a stock-music licence written for podcasts may
not.
Mechanical. The right to reproduce the recording in copies of your product. If you
are shipping a soundtrack alongside the game, or selling it separately, this is a distinct grant.
Performance. Relevant if the audio is played publicly — a trailer at a convention,
a stream, or an esports broadcast. Rarely granted by default and rarely needed, but worth knowing it
exists before someone asks.
For a single-player game shipping on Steam, synchronisation plus mechanical is what you need. If you
plan a soundtrack release, say so to the composer before you buy — retroactive licence extensions cost
considerably more than including it up front.
Voice acting adds another layer: performers frequently licence by usage and duration rather than
outright, so a line recorded for a demo may not be licensed for the shipped game or for a sequel.
Get the scope in writing, including whether AI processing of the recording is permitted.
What we do here
Every asset in our library carries a commercial licence with no revenue cap and no attribution
requirement, and audio is marked with its stream-safe status on the product page — because that is
the field that causes the most trouble after launch. The full terms are in our
licence agreement.
If you have a licence question that is not covered here, the
Marketplace Support board is the right place; answers
there are public so the next person with the same question finds them.