If you’ve ever made a game or even experimented with one, you’ve probably leaned on open-source software without realising it.
Developers often use tools such as Audacity for sound design, Blender for 3D modeling and animation, Krita for digital painting, and open-source libraries like Coquette, a lightweight JavaScript engine for prototyping 2D ideas, or Ett, an entity–component–system framework that helps structure gameplay.
All of these tools and libraries are open source and free to download and use, but not “free” in the sense of being without rules. As the GNU Project, a long-running initiative by the Free Software Foundation that promotes free software and user freedoms, famously explained: “To understand the concept, you should think of ‘free’ as in free speech, not as in free beer.”
At the heart of open source is a license. A license tells you what you can and cannot do with the code. We could go into a long explanation of the legal nature of a license, but the rule of thumb is simple: if you use open-source code in your game, you’re bound by its terms. Most of these licenses share some common ground, like the obligation to give credit to the original authors, but they divide clearly into two broad groups:
The GPL (General Public License) is the most common example of the copyleft group. If you copy, modify, or integrate the code of a program licensed under GPL in your game, you’re expected to open up your entire game under the same license. That’s a big commitment: it means you’ll have to make your own game’s source code publicly available and distribute it for free if you release it. Variations like the LGPL (Lesser GPL) are more forgiving, letting you link to certain libraries without opening your whole game, as long as any changes you make to the library itself remain open. Then there’s the AGPL (Affero GPL), which closes the gap for online services, requiring developers to share their code even if they only make their software available over the internet.
A famous example is DOOM released under GPL 2.0 back in 1997 for non-profit use. When releasing the code, John Carmack encouraged the community with ideas like: “Port it to your favourite system. Add some rendering features: transparency, look up/down, slopes, etc. Add some game features” Some developers took that “port it to your favourite system” idea very literally, which led to the meme “Can it run DOOM?”, where people try to run DOOM on everything from toothbrushes to Kindle E-readers
On the permissive side are licenses like MIT, Apache, and BSD. These are more flexible: they ask you to give credit, keep the license notice, and that’s usually about it. The code can be integrated into a proprietary game without forcing you to reveal your own source code. That’s why most commercial game studios are happy to work with permissive licenses: they allow creative freedom while keeping the path to monetisation wide open.
As a practical example, even big titles like Minecraft publish a clear Third-Party Notices section. In it, they include a line such as “This software incorporates material from third parties.” followed by a detailed list of the external libraries, their authors and contributors, and the licenses under which those libraries are provided. This transparency shows compliance with attribution requirements and makes it clear which parts of the game rely on open-source components.
But wait, Blender is under GPL, so why is it so widely used? The difference lies in how you use the software. When you open Blender to sculpt a character or Audacity to tweak sound effects, you’re not embedding their code into your game, you’re just using them as tools. The 3D models, textures, or sound files you produce are your own, and they don’t magically inherit the GPL. It’s only when you directly integrate a GPL-licensed code into your game’s codebase that the license obligations spill over into your game.
It’s tempting to think “Who’s going to know if I don’t follow the license?” But ignoring open-source terms is a serious legal risk. Violating a license isn’t a harmless shortcut, it’s an intellectual property breach, just like cloning someone else’s game without permission. Failure to comply can have harsh consequences: investors may walk away, platforms might refuse to host your game, and your game could become unsellable. Respecting licenses isn’t bureaucracy, it’s a matter of fair play
Open source gives game developers access to powerful tools, lowers entry barriers, and supports innovation. But it also brings responsibilities. Always read the license, understand what it means, and respect the rules. By doing so, you protect your work and keep doors open for publishing, fundraising, and growth.