Open-source licenses for game developers

License confusion is the single most common reason indie developers get burned by open-source code. The short version: always read the actual LICENSE file in the repository before shipping anything, and treat the categories below as rough shorthand, not legal advice. This guide is a quick reference for the licenses you will run into on GitHub when you go looking for a starting point, a plugin, or an asset pack to use in a commercial game.

The five categories you actually see in the wild

MIT, Apache 2.0, BSD, ISC, Zlib, Unlicense, CC0
The "permissive" cluster. You can use the code in a commercial closed-source game with essentially no obligation beyond including a copyright notice somewhere (often in a credits screen or a NOTICES file shipped with the build). Apache 2.0 additionally includes a patent grant, which is mildly useful but rarely the deciding factor for a game. CC0 and Unlicense are effectively "do anything", with no attribution required, though it is still polite to credit the author.
LGPL 2.1 / LGPL 3.0
Permissive if you dynamically link to the library and ship the unmodified library binary alongside your game. Static linking, modifying the library, or bundling everything into a single executable triggers the same "you must release your changes" obligations as full GPL. For Unity, Godot, and most engines this means LGPL libraries are workable but require care — typically you ship the library as a separate DLL/SO/dylib and document that users can replace it.
GPL 2.0, GPL 3.0, AGPL
"Copyleft" — if any part of your shipped game incorporates GPL code, the entire game must be released under a GPL-compatible license, including all your own code and assets. For a closed-source commercial game this is almost always a deal-breaker. AGPL goes a step further and applies to network-accessible code too, which is relevant if you ship a multiplayer game with a server component. GPL code is fantastic for studying and learning from, and perfectly fine for game-jam, open-source, or modding projects.
Creative Commons (CC-BY, CC-BY-SA, CC-BY-NC, CC-BY-ND)
Common on art, audio, and music assets, not really meant for source code. CC-BY is permissive with attribution. CC-BY-SA is "share-alike" and behaves like a copyleft license for the asset, meaning your derivative work has to use the same license. CC-BY-NC forbids commercial use entirely and is unsuitable for any commercial game. CC-BY-ND forbids modification, which makes it useless for almost any practical asset workflow.
Custom or proprietary
Anything else — "source-available", "free for personal use", "free until you earn $X", "Business Source License", "Server Side Public License", or no license file at all. Treat as not-licensed-for-your-use until you have read the actual terms. A repository with no LICENSE file is, under default copyright law, all-rights-reserved even if it is publicly visible on GitHub; the right to view source on a public site is not the same as the right to use or redistribute it.

The rules of thumb that save the most time

A practical rule of thumb. For a commercial game, default to MIT/Apache/BSD-licensed dependencies. For game jams and personal projects, anything goes. For everything in between, read the LICENSE file once and add a note to your project's README so future-you remembers what you agreed to.

Using this with the repo catalog

The GameDevHub repo catalog tags every repository with a license category drawn directly from GitHub's license metadata. The License filter on the catalog has four buckets:

For a commercial project, the fastest workflow is to set the License filter to "MIT / Apache" and ignore everything else. For a learning or modding project, the GPL bucket is often where the most interesting code lives.

This guide is a summary, not legal advice. For anything with real money on the line, consult an actual lawyer who handles software licensing. The summaries above are intentionally simplified for the common indie-game case and do not cover every edge of every license.

Related