Open-source licenses for game developers

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

The five categories you actually see in the wild

MIT, Apache 2.0, BSD, ISC, Zlib, Unlicense, CC0
Safe for commercial closed-source games. 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
Workable with care — dynamic linking only. 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
Almost always a deal-breaker for closed-source commercial games. "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)
For assets, not code — and check the suffix. 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
Treat as not-licensed-for-your-use until you read the terms. 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

A pattern I see constantly while curating this site's catalog: the license GitHub's badge reports and the terms actually in the repository sometimes disagree — a LICENSE file swapped mid-project, or an MIT badge over GPL-licensed subfolders. That is why the catalog treats unparseable licenses as "Unknown" rather than guessing, and why the advice above keeps repeating "read the file".

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.

FAQ

Can I use MIT-licensed code in a commercial closed-source game?

Yes. MIT, Apache 2.0, and BSD all allow commercial closed-source use; the only real obligation is including the copyright notice somewhere in your shipped product, such as a credits screen or a NOTICES file.

Can I use GPL code in a closed-source game?

No. GPL is copyleft: if any part of your shipped game incorporates GPL code, the entire game must be released under a GPL-compatible license. GPL code is fine for learning, modding, and open-source projects.

What does it mean if a GitHub repository has no LICENSE file?

Legally it means all rights reserved — you cannot use or redistribute the code, even though it is publicly visible. Ask the author to add a license; many will add MIT on request.

Related