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
- 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
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.
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