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
- Default to MIT / Apache / BSD for commercial dependencies. If a candidate library has one of these, your decision is essentially done; if it doesn't, the burden of proof is on you to confirm the actual terms.
- Keep a NOTICES file in your build directory listing every third-party library and its license. Most permissive licenses require attribution somewhere in the shipped product, and a single text file is the simplest way to satisfy that.
- Treat "no LICENSE" as "do not use". Open an issue or DM the author asking them to add one. Many maintainers will add an MIT license on request because they assumed their code was already permissive.
- Check the dependency tree, not just the top-level library. A permissive library can transitively pull in a GPL one. Tools like
npm-license-checker,cargo-license, and similar exist for exactly this reason. - For art, audio, and fonts, always check the license separately. Asset licenses on itch.io, OpenGameArt, or Freesound often have specific attribution-string requirements that are different from the code licenses they ship next to.
- If you're building a game jam or hobby project, none of this matters as much. The bar for ethical use is "credit the author and don't pretend you wrote it". The strict legal analysis kicks in when money starts changing hands.
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:
- MIT / Apache (Commercial OK) — the permissive cluster from above.
- Study Only (GPL — Copyleft) — useful for learning and modding, risky for commercial use.
- Restricted / Custom — read the LICENSE file in the repository before using.
- Unknown License — GitHub could not auto-detect a license. Treat as restricted until verified.
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
- Game engines compared — Godot, Unity, Unreal, Bevy and the smaller options.
- Open-source game-dev repo catalog — filter by license, engine, and quality.
- Back to GameDevHub home