Most advice about asset licensing is either a shrug or a wall of legalese. This is the middle version: the licenses you will actually meet, what each one asks for, and the two or three that are genuinely a problem for a game you intend to sell.
This is not legal advice, and it cannot be. It is a working summary written by somebody who builds a tool for keeping track of this, and the license text always wins over any summary of it, including this one. Where a license matters to your business, read it, and ask somebody qualified.
#The short version
| License | Credit needed | Can you sell the game | Does it affect your own work |
|---|---|---|---|
| CC0 1.0 / public domain | No | Yes | No |
| CC BY 4.0 | Yes | Yes | No |
| CC BY-SA 4.0 | Yes | Yes | Possibly, see below |
| CC BY-NC | Yes | No | No |
| CC BY-ND | Yes | Yes | No modifying |
| MIT, BSD, Apache-2.0 | Yes, keep the notice | Yes | No |
| SIL Open Font License | Usually not in-game | Yes | Cannot sell the font by itself |
| Store or marketplace EULA | Usually no | Usually yes | Usually no redistribution |
Everything below is the detail behind that table.
#The ones that ask for nothing
CC0 1.0 is the author giving up everything they can give up. Use it, change it, sell it, and never mention them. A great deal of what is freely available for games is CC0, and for those files a credits line is a courtesy rather than a condition. It is still worth recording where it came from, because a year later you will not be able to tell a CC0 file from a CC BY one by looking.
Public domain through age or dedication behaves the same way. Be careful with photographs of public domain works, where the photograph can carry its own rights even when the subject does not.
#The one that asks for a line of text
CC BY 4.0 asks for attribution, and that is all. Name the creator, and where it is practical, say what the work is called, link to the original, and note if you changed it. It permits commercial use and permits modification. It is the most common license attached to good free game assets, and the requirement is small enough that there is no excuse for getting it wrong.
Where does the credit go? Anywhere a reasonable person would look: a credits screen, a credits file shipped with the game, or the store page. The license asks for attribution "in a manner reasonable to the medium," which for a game means the credits screen most people never open, and that is accepted practice.
#The one worth thinking about
CC BY-SA 4.0 adds share-alike: an adaptation of the work has to be offered under the same license. For a blog post that is simple. For a game it is the genuinely contested case, and anybody who tells you it is obvious is overselling their certainty.
The uncontroversial part: if you edit a CC BY-SA texture, the edited texture is an adaptation, and that texture carries the license onward. The contested part is whether a game that merely includes the texture is itself an adaptation, or is what the license calls a collection, which does not carry the obligation. Reasonable people disagree, and it has not been thoroughly settled in court for this kind of use.
The practical advice is boring and correct: for a commercial closed-source game, prefer CC0 or CC BY, and use CC BY-SA only where you are comfortable with the ambiguity or have taken advice. It is not a trap, it is a decision, and the mistake is making it by accident.
#The two that stop a commercial game
CC BY-NC forbids commercial use. Not "forbids it unless you are small," not "asks nicely." If you are selling the game, taking ad revenue, or using it to promote a business, this is not a license you can build on. It is fine for a jam game or a portfolio piece, and people do get caught out when the jam game turns into something they want to sell.
CC BY-ND forbids derivative works. For most game assets that is fatal in a quieter way, because using an asset in a game very often means changing it: rescaling a texture, retopologizing a model, trimming a sound, recoloring a sprite. If you genuinely use it exactly as delivered, ND permits it, and the moment you touch it, it does not.
#Software licenses on assets
MIT, BSD and Apache-2.0 turn up on assets, usually because the whole repository has one license and the art came along with the code. They allow essentially everything, on the condition that you keep the copyright notice and the license text with the distribution. That last part is the one people skip. Keeping a copy of the license in your credits or a third-party notices file satisfies it.
GPL on art is rarer and needs care, because its whole design is to attach conditions to what you distribute alongside it.
#Fonts
Fonts have their own conventions, and the SIL Open Font License is the common one. It permits embedding a font in a document or a game, and permits modification, but forbids selling the font on its own, and if the license reserves a font name, a modified version has to be renamed. For a game this is almost always unproblematic: you are embedding, not selling fonts.
#Store and marketplace licenses
Assets bought from a store are not under Creative Commons at all. The terms differ per store and sometimes per seller, but the shape is usually the same:
- Per seat. The license is granted to one developer, and a studio needs a copy per person.
- No redistribution in a usable form. Shipping the asset inside a compiled game is exactly what it is for. Putting the source file in a public repository is exactly what it is not.
- Often no reselling as an asset, even modified.
The last point catches people who put their game's full project on GitHub as a portfolio piece.
The game shipping the asset is fine; the repository containing the .fbx usually is not.
Note also that "royalty-free" is not a license. It describes the payment model, not what you are allowed to do, and a royalty-free asset can still carry heavy restrictions.
#What to actually do about it
The failure mode is never that somebody read CC BY and misunderstood it. It is that a year later nobody can say which of the above applied to which file.
So record it at the moment of download, when you still know. Which license, and where it came from. That is the whole discipline, and it is a filing problem rather than a legal one.
Tessera exists to make that happen without relying on you to be careful: a pack is asked for its license and its source before it joins the library, usually answers both itself from what was in the download, and writes the credits file for a project from what it recorded.
Install Tessera, or read how licenses are recorded.