You Can't Always Have Nice Things

DISCLAIMER: I may be incorrect about one or more things I wrote in this article. Some of these are educated guesses, other parts of the article are based on what developers and studios have said in the past. I also got some tidbits of information from this discussion on Lemmy and the survey on strawpoll I ran last year.

Also, I'm putting footnotes after each paragraph rather than at the end of the article, because I think it's easier, quicker, and more sensical. I also tried to add links to both Steam and GOG.com where possible.

When I was reading the thread "No tux, no bucks" on the GamingOnLinux forums, I noticed there were a few people saying that they won't buy games unless they are Free/Open Source. I do not agree with these people. Whilst there is merit to Open Source games, I also recognize that there are quite a few reasons why developers cannot, or would not want to, release their games as Open Source. In addition, I feel disappointed that, of all the video games out today, almost none of them are Open Source, especially given the fact Id Software released the source code for almost all of their games prior to Quake 4 and Doom 2016.

And based on this article, it sounds like video games are an ideal candidate for having their source code released, since the game can be sold as a proprietary audio, graphics, and level pack for the base game engine.

Kinsie wrote an article about why fewer modern games have mod support. Although Kinsie's article's topic is tangential to the topic of this article, modding and Open Source are closely related concepts when it comes to video games, since having the source code or some knowledge about the internal workings of the game/engine is necessary for making mods for it.

Some people believe that "Open Source" means releasing all of the code AND all of the assets for free. However, in this article, Open Source refers to video game executable source code releases, even if the assets remain nonfree.

Also, this article mainly talks about reasons developers choose not to release their source code, rather than reasons developers cannot release their source code (such as an HDD failure or bit rot).

Table of Contents

  1. Money
  2. Predatory Business Strategies
  3. Piracy and Illegal Resales
  4. Maintenance
  5. Amount of Content
  6. Community Involvement
  7. Budgets and Deadlines
  8. Corporate Culture
  9. Mergers and Acquisitions
  10. Cheaters
  11. Console Support and Other Licensing Woes
  12. Publishers' policies
  13. Development Team Size
  14. Shame
  15. Asset Abuse
  16. Software Patents and Trade Secrets
  17. Competition/Knockoffs
  18. AI/Machine Learning
  19. Intellectual Property/Business deals
  20. Erasure
  21. Ownership
  22. International Affairs
  23. Reverse Engineering
  24. Tight coupling of code and assets
  25. Shelf Life
  26. Conflicts with Free/Open Source philosophy
  27. Conclusion
  28. When Games become Open Source

Money

Entertainment can be big business, and video games are no exception. One game can have the potential to sell hundreds of millions of copies, and in addition, it can earn even more money through in-game microtransactions and DLCs. In 1995, two years after the release of Doom in 1993, more people installed Doom than Windows 95! A quick look at Wikipedia's list of best-selling video games or Wikipedia's list of highest-grossing mobile games can show just how profitable the video game industry can be.

Making a video game can be a massive investment of time and money. Video game development involves coming up with a fun game design, and then creating the levels, enemies, etc. and expanding upon the initial ideas. The process of doing this can be extremely costly, depending on the amount of content, the desired level of quality in the final product, the amount of money available for development, and the budget allocated to each aspect of the game. And then the developers have to ensure that playing the game is an enjoyable, polished experience if they want their game to be successful.

In this economy, money is made by holding power over other people, or having something that others do not. For example, if you give someone materials and instructions for making something, without charging them for the aforementioned materials and instructions first, you hold no power over them, and therefore cannot extract money from them after the fact. If a game developer releases the source code for their video game project, it could put them in a situation where they are no longer able to make money, because people are generally selfish and highly unlikely to pay for something that they can get for free. The only advantages the original developer has over others when they release the source code are codebase knowledge and copyright on the assets, and even that doesn't stop others from studying the codebase and acquiring that knowledge for themselves.

There are many reasons game developers would want to make money by making and selling copies of video games: Sheer greed, recouping development costs, taking advantage of the enormous market, or even just trying to pay for basic needs, among other reasons. Therefore, most video game studios are businesses, and most video games are commercial and nonfree. After all, in this economy, it makes the most sense to make a huge investment only if you can expect a return on that investment.

Game developers traditionally made money by selling copies (or technically, player licenses) of their games, and then selling expansion packs, DLCs, and sequels for the game if the base game is successful enough. On the other hand, a lot of open source projects rely on donations, corporate funding, or public funding to support their endeavours.

I don't think it would be profitable to rely on goodwill and donations because only a tiny handful of people would bother donating. For example, every time Wikipedia asks for donations, they say only 2% of readers actually bother to donate, and Betterbird says that less than 1% of their users support it financially.

On the other hand, Open Source project developers typically make money through the support they offer, and providing services related to their Open Source project. How well this works depends on what the Open Source project is, how popular it is, and who uses it:

Unfortunately, these methods of monetization probably won't work for Free/Open Source video games. And if someone tried to monetize a Free/Open Source video game in this manner, I think it would be the "Paid mods on Steam" fiasco all over again. But, maybe there are other ways for Free/Open Source game developers to make money off of their games. I've never seen a Free/Open Source game project try to monetize their game like this, however.

So, for several reasons including the aforementioned reasons, most game developers see releasing their source code as a threat to their income, and since they intend to earn money, they don't want people to obtain their games in a way that doesn't earn them money, and so they don't release the source code in order to try and minimize their losses.

Predatory Business Strategies

An increasing amount of game developers these days are making money through in-game purchases, even if those business practices are predatory, manipulative, and anti-consumer. Some of these business practices, especially capitalizing on FOMO and cosmetics that increase a player's social status among other players, are fundamentally incompatible with releasing the source code, because if the game's source code was available to the players, the players would be able to change the prices and quantities of the virtual "goods" on the marketplace, or add in ways to obtain these goods for free, depriving the developers of income they would otherwise have, even if it was earned through evil business practices.

Piracy and Illegal Resales

There's always pirates out there who want to "share" the game with others free of charge and hurt the developers' income, even if that wasn't the intent behind doing so. And then, what if some asshole wants to resell the game at a different price, without getting permission from the developers or making a business deal with the developers first? The developers get hurt in both of these scenarios, especially because the unauthorized distributors may end up making more money than the original developers, and releasing the source code to a video game could make both of these scenarios more likely to happen; With the source code for a game available to any potential pirates and bootleggers, they can remove the existing DRM, or the reseller can add in another DRM solution that benefits them rather than the original developer(s).

Pirates and bootleggers generally do not care about copyright law. Also, in the digital age, it's easy to unknowingly bootleg a copy a video game, because if someone wants to sell their secondhand copy of a video game, they are legally required as per the terms of the EULA to erase all digital copies of the game from all of their computer data storage devices before doing so.

Maintenance

Open Source projects are typically maintained long after their initial release, and get new releases whenever the maintainers feel the project is in a good enough shape to get a new release. However, A lot of game developers would rather move on to newer projects instead of maintaining their older projects forever. For example, Erlend Sogge Heggen, the head of Spicy Lobster Games and Fish Folk, said that he was heavily inspired by Duck Game, and that the original developer of Duck Game wanted to move on to other games instead of maintaining Duck Game forever.

If the developer decides to release the source code for one of their old games, this may force the original developer to keep maintaining the aforementioned game, unless the original developer gives the community (or someone else) permission to maintain the old game project or take it over. Depending on how the project is handed over, the original developer may or may not have control over the IP or receive payment for any purchases of the aforementioned game. The developer will have to be careful regarding copyright and IP ownership if they decide to release the source code.

Amount of Content

Computer software is generally designed to be useful for getting things done in a quicker and more efficient way than using other software or doing it by hand. Video games, on the other hand, are designed to provide entertaining audiovisual experiences which range from casual experiences meant to be enjoyed in one's spare time, to thought-provoking story experiences, to highly-competitive e-sports games like PUBG, CS:GO, Overwatch, etc.

Most non-game software utilities use a minimal amount of audiovisual content such as icons, but for a video game, the audiovisual content is very central to the experience, so it begs the question of whether video games count as software or artwork, and this is important because Free artwork is typically licensed under one of the Creative Commons licenses, and Free software is typically licensed under the MIT license, Apache license, or the GNU GPL.

When the Doom/id Tech 1 engine source code was released, it was released under the Doom source license, and later under the GNU GPL. But, when the Duelyst source code was released, it was released as Public Domain. It's worth noting the former release contained no audiovisual content, while the latter release contained all of the game's audiovisual content.

Community Involvement

Big-name video games are often directed like movies, especially if the game is linear and story-based like a movie. Specific parts of the game, like the AI and abilities for each enemy, are also directed so that they are in line with the director's vision for the game.

Releasing the source code for a video game while it is in development democratizes the development process by allowing people outside the core team to contribute changes, be they for better or worse. For example, shortly after work started on Chapter 3 of Wolfenstein: Blade of Agony, there was a very enthusiastic fan from Russia who came in and gave the developers a ton of feedback, suggestions, and code submissions, and he's still contributing to the game today. While this resulted in a significant overall improvement, not every fan of an Open Source game wants to make changes that will improve the experience.

Game directors and producers are most likely unwilling to take premature feedback from outsiders. They also may not want to have to manage contributions from external sources in addition to the feedback they already get from other employees at the studio. This would mean setting up a contributor license agreement, documenting the code, documenting the repository and contribution process so that complete outsiders can start contributing, checking all contributions to ensure they are clear of legal issues, and ensuring that contributors have legally binding permission to use all outsourced assets they submit. It's a lot of work, and the costs may end up being so high that it is not worthwhile.

Documentation needs to be either written or revised to work with the assumption that you can’t just walk down to an engineer’s desk and ask them how something should be done.

And the directors may not want outsiders to take control of the game and its development, so they don't want the source code being released unless it means they still get to have control over their game, like how Google has control over Chrome and Chromium.

Video game studio directors have absolute control over the projects they are directing, and the people working on the game, and this shows in how many modern AAA games feature in-game purchases and "loot boxes". Free/Open Source projects, on the other hand, have what is known as a Benevolent Dictator for Life. These are people who lead and maintain the project, but also listen to the community, since a BDFL can be kept in check by the community because the community may fork the project in case the BDFL tries to exert too much control or take the project in a direction a lot of users disagree with. For example, some Debian users were unhappy with the decision to adopt systemd, so they forked Debian to create Devuan, and at the end of 2022, some members of the Gitea community forked Gitea to create Forgejo after their open letter movement failed.

And then there's the question of who should get paid when all is said and done. Should the studio keep all the profits to themselves, and only distribute the pay between their full-time employees? Or should the studio pay individual contributors for their contributions? It's also hard to assign value to individual contributions, since a simple one-line patch can be something like an edit to a comment, a translation to/from the primary language the main development team uses, a fix for a critical security issue which ends up paying off dividends in the future, or a fix for a barely-noticeable bug that has grown on the development team.

So I was thinking about making the game open source. But then I thought what if in the future I wanna use for example AdMob and be able to make money. Is it possible? Also what about some fairness with contributors? For example half money for me, half split between others, or how is this working in other projects?

There's also the issue that, without a strong contributor license agreement in place, accepting external contributions in the first place makes it possible for any contributor to rescind all of their contributions at any point for any or no reason.

Budgets and Deadlines

Most professionals in the video game industry, whether they are independent developers or people working for the big-name AAA studios, are constrained by budgets and deadlines.

A business' primary objective is to make as much money as they can for themselves, their employees, and to fund any potential future projects. To this end, the business' board of directors has to decide what's worth spending money on in order for their business to be profitable. Therefore, these executives decide on the budgets for each project their company undertakes, and so the workers are at the executives' behest.

Keeping in touch with the community, implementing the community's suggestions, and releasing the source code are all things that require time and effort, as well as money. If the executives decide it isn't worth spending money on any of the aforementioned activities, they won't.

Corporate Culture

There's a famous quote by Peter Drucker, which reads "Culture eats strategy for breakfast", and it means if the corporate culture is incompatible with the company's strategies, the strategy will fail.

The typical profiteering nature of game development studios, and the overall culture which generally rewards hard work and private ownership through capitalism encourages people to embrace the mentality of "it's mine, and you can't have it unless you pay up!".

If the people working for the company/studio are not OK with their source code being released to the public, a source code release may not end well for the company. The employees who worked on the recently open-sourced game may leave the company because they feel the company mistreated them by releasing their hard work to everyone, free of charge.

Mergers and Acquisitions

The video game industry has seen a lot of mergers and/or acquisitions lately. Massive corporate behemoths are buying up or merging with small and medium-sized independent studios in order to increase their market share and potential profits. For example:

Since bigger companies are bigger and greedier than the smaller companies they look at buying, all of them probably have a policy of keeping video game source code out of other people's hands. Although developers who have released their source code generally don't take it down after being acquired by a larger studio, it becomes highly unlikely that any of the aforementioned developer's new releases will be Open Source.

Cheaters

Cheating is still a massive problem in online multiplayer games, even if those games use some kind of anti-cheat middleware. If the game's source code gets released, cheaters will be able to find even more weaknesses and vulnerabilities in the game's code, or create their own version of the game which includes cheats as features, because cheaters are basically hackers who target video games instead of web servers or individuals' computers. Anti-cheat systems may not be able to detect cheats which have been added as features, modified game executables, and other parts of the user's system which have been modified to facilitate cheating.

Cheaters can cause huge problems for other players, and if cheating is prominent enough, it may cause massive drops in the numbers of players, and this matters because such a drop in p(l)ayer count can cost the developers millions of dollars. Cheaters won't stop cheating because of that, they'll just move on to other, more vulnerable games.

The only sure-fire way to prevent cheating is to avoid supporting any platform which has cheating software, or otherwise allows players to cheat, and to avoid releasing the source code so as to prevent cheaters from finding any exploits, vulnerabilities, or exploitable patterns in the game's code. This means no release for any open platform, and no source code release.

Console Support and Other Licensing Woes

If the developer is using a nonfree engine or nonfree piece of middleware for their game, it won't be easy to release the game's source code. The engine or middleware license may come under an agreement that forbids exposure of the API to anyone other than the developer and the engine/middleware vendor. Or the developer may want to port their game to a closed console platform, which requires purchasing a developer kit (see the budget breakdown on this page, or this article for an example), as well as ensuring you do not expose the console platform API calls.

This means games licensed under the GNU GPL cannot be ported to consoles, and games available for consoles may not get Open Source releases, due to the mutual license incompatibilities between Free Software and closed platforms like consoles, and the difficulty in separating console platform-specific code from the rest of the game code.

Sadly, it seems like game developers tend to use a lot of nonfree technologies, such as Speedtree, which have no FOSS alternatives, but even when there are FOSS alternatives, like OpenAL Soft instead of FMod or glTF 2.0 instead of FBX, game developers tend to prefer the nonfree solutions over the FOSS alternatives. This may mean that game developers who wish to release their games as FOSS are severely limited in what they can achieve if they stick to purely FOSS tools and middleware.

Many games these days typically license out third-party materials – middleware, fonts, etc. etc. – that are typically developed by companies that don’t want the keys to their kingdom handed out to XxGoKuFaRtZ_69xX.

And console platforms are especially important for game developers, since consoles are the biggest source of income for them.

While platforms like Steam are very easy to publish for, the reality is that most of the revenue from independent developers generally comes from consoles.

There may or may not be ways around the platform support issues, depending on how tightly dependent the game is on the platform API. For example, you could try to wrap the console API calls using a cross-platform layer of code, keeping the console-specific implementations secret.

For example:

Publishers' policies

WARNING: Some of this is just a bunch of rough educated guesses. I don't know much about what a publisher does for a video game developer.

A lot of video game developers, especially indies, need to sign a deal with a publisher so that they can release on consoles, advertise the game to the biggest potential audience, among other reasons.

As part of the deal between the developer and publisher, the publisher may want the developer to sign away all of their rights to the game and take ownership of the game. This means any video game source code joins the collection of assets owned by the publisher, and as such, they will want to protect their assets and prevent developers from releasing their source code. The publisher does marketing and other things for the game, so they want to at least recoup the cost of marketing the game.

Developers may try to self-publish their games, but there are only two ways that will be profitable enough: The developer is a celebrity like Pirate Software (Jason Thor Hall) or Blendo Games (Brendon Chung), or the game is so amazing/revolutionary/mind-blowing that it goes viral like Hellblade: Senua's Sacrifice (Ninja Theory).

So if a developer really wants to release the source code for their video game(s), they had better find a publisher that is willing to allow that.

In addition, the publisher may take a cut from the developer's income in addition to the income cut the storefront takes.

I 100% agree on this. However, quite often developers' hands are tied by contracts with their publishers.

I don't even think we would mind as a studio, but as far as I know everything we make belongs to our publisher.

These mutual incompatibilities between Free/Open Source software and publishers' policies prevent most Free/Open Source games from having a publisher, so developers of Free/Open Source projects need to find other ways to advertise their game, and support themselves and their Free/Open Source game projects. In addition, many Free/Open Source game projects are hobby projects that people work on in their spare time, so they are not as important as a commercial indie game project is to a proprietary/commercial indie game developer. Publishers have little to gain from marketing a game that players do not have to pay anything for.

Nightdive is a studio that takes old games, reverse-engineers or upgrades them depending on whether or not the source code is available, and rereleases those old games. They acquire the rights to the game from the developer, but they are still beholden to the publisher when it comes to source code releases and platform support, as Stephen from Nightdive said on Reddit back in 2020:

This is Stephen from Nightdive Studios, when we have source code available we try to make it public but most publishers are against it. We've released the source code to Strife and System Shock but only because we own those IPs. Finding source code for our remasters is the most difficult aspect of my job as most of the code for older games has been completely lost. I just discovered that for Japanese developers it was routine to destroy the code and assets for a finished project before moving on to a new game.

Emphasis mine. Also, Nightdive seems to have changed for the worse in this regard since 2020. Nightdive didn't release any source code along with their recent rereleases of Blood (Fresh Supply), Powerslave, or Quake, and the Quake II rerelease only had part of the source code released.

Development Team Size

As Kinsie mentioned in his article about mod support (or lack thereof), AAA game studios rarely develop everything in-house any more. As such, the development of a modern AAA game is split between several different teams from all over the world, which are involved in taking care of different parts of the game or engine. If someone wanted the game's source code to be released, they would need consent from every single person who has ever made a change to the game or engine code.

And with the way modern AAA game development is structured, it is generally not worth trying to obtain consent from everyone who has worked on the game or engine code to release it to the public after all the work is said and done. Getting everyone's consent to release the game's source code would be a very time consuming and costly task, due to the sheer amount of people involved in said game's development process. In addition, a big-name studio may have to hire lawyers to ensure their code does not infringe on any software patents.

Back when Id Software released the source code to games such as Doom and the Quake series, they were a small independent studio, albeit a very talented one, that developed almost everything in-house, so they didn't have a huge amount of legal issues to clear or consent to obtain before releasing their source code. In addition, they were fans of GNU/Linux and Free/Open Source software, since they were one of the few studios to offer official GNU/Linux ports and source code releases of their games at the time.

I think the best way for someone to make a source code release feasible is to plan the eventual source code release of a video game project from the very start, and make sure everyone the project is advertised to is informed of this planned source code release before they start working on it, although I don't think it would be possible for a AAA game studio employee to muster support from their coworkers if they decided to start a FOSS video game project, for many of the other reasons listed in this article, in addition to the lack of compensation for contributing to FOSS video game projects, the lack or inversion of copyright protection typically associated with FOSS, and (possibly) the terrible work ethics at AAA game studios.

Shame

Independent video game developers have many free of charge or FOSS tools available to them to make video games. But making video games often requires more than just having the right tools, because of their interactive nature. Video game developers often need to know how to write code.

Video game development is a complex affair, since video game designs are not exactly set in stone once the production of the video game is underway. During the course of the video game production, new ideas about how to enhance the gameplay loop may be formulated. Coming up with ideas is one thing, but implementing those ideas into the existing codebase is a far more complex task.

As mentioned previously, video game developers may be under strict deadlines and budgets as determined by the higher-ups (if they work at that kind of company). This lack of time means new features and ideas may not be able to be properly implemented without breaking everything else, so these new features are hastily hacked in as a result. And/or the developers may just lack the coding skill and experience needed to write maintainable code.

I doubt anyone would want my source code, I can imagine it not being that clean being such a noob at it.

This may lead developers to feel ashamed of what their codebase has become, and so they would rather seal it away from themselves and others. However, releasing the source code opens up the opportunity for the code to be modified by others, and for hacked-in ideas to be properly reimplemented in a more maintainable and versatile fashion.

Asset Abuse

Obviously, for developers to keep their game's assets out of the "wrong" hands, they won't want to release the source code for their games. Releasing the game's source code gives everyone with enough skill, codebase familiarity and dedication full access to the game's proprietary assets.

If the game is popular enough, such people will promptly proceed to use those proprietary assets for their own selfish purposes, like porting the 3D character models to other games (especially GMod or L4D2) or slapping NFTs¹ onto them and trying to sell them, for various selfish reasons including disregard for copyright law. Most studios seem to turn a blind eye to ported character models; it could be free advertising, or it could reduce their net profits. But most people are not OK with their assets being abused or sold without their permission, even if they are generally OK with their assets being used.

[Monstrüous] took me sweat and tears to make. I’m proud of it and I wouldn’t want someone to use my art in some way that I wouldn’t like or to sell it or something like that.

  1. I don't know exactly how NFTs work, but that's my best guess at what people do with NFTs and audiovisual assets.

Even when it comes to fully Free/Open Source games like Veloren, exploiting the assets by putting NFTs on them and trying to sell them is frowned upon:

It has unfortunately come to our attention that Veloren's assets, code, and imagery have, on occasion, been used to promote malicious scams such as 'pump-and-dump' schemes, often involving cryptocurrency or NFTs. The core development team is clear: Veloren is not, and will never be, a for-profit project, nor do we wish to be associated with regressive, socially harmful technology like cryptocurrency.

And then there's the fact that a lot of video games these days use one or more third-party copyrighted assets that are made by various authors/developers and sold on their respective engine's asset stores. For example, you'll find the same trees in NeonCode, Volcanoids, The Dwarves, and many other Unity3D games. Obviously, the author(s) of such assets want to make money from selling them, and doing so means these assets will most likely be licensed under a nonfree license, so this means anyone who wants to release the source code for their game will have to make their own assets instead of using someone else's (if such assets contain code), or ask any interested contributor to purchase the same assets from the engine's asset store.

However, people on the Godot Forums are saying that your game will be pirated or plundered for its assets, no matter if or how you try to protect them, the most important reason for resource protection is to prevent theft of third-party assets, and that resource protection is not worth the effort if you're a small indie developer.

Software Patents and Trade Secrets

Any video game could contain trade secret code and/or implementations of patented algorithms, with or without the developers' knowledge. For a big-name AAA studio, part of the process of releasing the source code for one of their video games would be to have lawyers meticulously examine the game code to ensure that the code does not implement things covered by software patents. This is because the big-name AAA studios would face a lot more scrutiny and legal troubles if they tried to release the source code for one of their games, compared to an independent studio. The time and money required for a proper Open Source release from a big-name AAA studio is probably not worthwhile at the end of the day.

On the other hand, some big-name AAA studios hold patents on certain game concepts or mechanics, such as the Nemesis system in Shadow of Mordor, or the direction arrows in Crazy Taxi. These big-name studios would not want to release the source code for games which implement these patented technologies, since that would allow competitors to study and implement such features in their own games.

However, even the big names in the video game industry have rarely stopped people from making clones of their games. There are numerous examples, one of which is Poi, a clone of Super Mario 64 built on the Unity3D engine.

Small independent developers are more likely to release their source code, but most independent developers don't have lawyers like big studios, so even if their code infringes on any software patents, they have no way to check whether their code is legally troublesome.

Competition/Knockoffs

Unless your business has a monopoly, every business faces competition. The video game industry is far from a monopoly, and there are a plethora of resources out there to help people make video games, such as the Godot Engine and the myriad of tutorials and assets for it.

By releasing the source code for any of your video games, you allow your competitors to take advantage of your technology. This means your competitors could make knockoffs of your game if your game sells well enough in an attempt to outdo you, such as when Electronic Arts created Apex Legends in an attempt to outdo Fortnite.

Releasing the source code under a Free Software license will make it legal for studios to just replace all the existing assets with their own, and put out their own knockoff game in hopes of easily making money without having to start from scratch.

Wolfenstein 3D's technical achievements also led to numerous imitators such as Ken's Labyrinth, Nitemare 3D, The Terminator: Rampage, Terminal Terror and The Fortress of Dr. Radiaki, among others.

This can even happen to Free/Open Source non-game software tools:

I am afraid if I make the code open, there would be a lot of low effort free clones on the market.

It is possible to release the source code under a more restrictive license to prevent such scenarios, but then the program would not be considered Free Software. This is what Volition did with the Freespace 2 source code release.

AI/Machine Learning

There are many ways AI is being used today, including generating code, images, videos, and text. Game developers have many AI-powered tools at their disposal, and given the rapid rise of AI-generated content, some game studios have embraced AI to boost productivity or replace jobs that would have been done by a human.

We also intend to be aggressive in applying AI and other cutting-edge technologies to both our content development and our publishing functions.

The biggest problem with AI is that most modern AI models are trained on datasets that were largely just stolen from internet search results, and that there are currently no laws regulating how AI models are trained or used to generate "new" content. So most text, images, and videos generated by an AI infringes on the copyrights of one or more people.

Some AI software used by modern video games might be proprietary, so it would be problematic to release the source code for the AI software that is used in the game. For example, some games use AI technology like NVidia DLSS to upscale low-resolution raytraced images. And some games, like The Day Before, used AI to generate in-game advertisement signs and billboards.

And that is far from the only way AI is used or abused. When source code is uploaded to a website like GitHub, it is (or will be) indexed by GitHub's search engine, and may be used as training data for GitHub Copilot. Some developers do not want AIs to be trained on their code, because they believe the AI will just plaigiarise their code; other AI models are known to plaigiarise copyrighted works, so why is Copilot any different? This is the foremost reason why the Software Freedom Conservancy wants developers to leave GitHub and either host their code on their own servers, or use another (preferably FOSS) service that doesn't have a "Copilot".

Having all of the source code and assets for a video game hosted on a site like GitHub opens it up to the possibility of being plaigiarised by an AI like Copilot. Most people do not want their hard work to be stolen, especially if it's something they poured their heart and tears into making. And since most video games are made (at least partially) to generate revenue, the people who are working on the game will probably not want their work to be plaigiarised by an AI. Not to say that this is necessarily a reason to keep a video game's source code closed, but the developers can upload the source code to another service like Codeberg or their own server if they don't want an AI like Copilot to be trained on their code.

Intellectual Property/Business deals

If a company doesn't protect their intellectual property, they may lose the rights to their intellectual property. A public source code release of a video game, if it happens at all, may weaken the IP associated with the game, since the source code for a video game is not easy to decouple from the IP, and releasing the source code effectively means handing the keys to the game executable away to the rest of the world.

Also, a lot of video games are produced under IP licensing deals in the hopes of cashing in on the IP popularity. When Id Software started developing Doom, they originally wanted to make an Aliens game before they changed their minds and decided to create an original IP. If they had entered a licensing deal, which is a prerequisite for being allowed to use the IP legally, the game may have had a much shorter lifespan, and they would have had to abide by the terms set by the licensor.

And many games may be produced under business deals which make the game effectively locked to one console or PC game storefront. For example, when Epic Games launched their storefront, they threw a lot of money at game developers, especially those who ran crowdfunding campaigns on Kickstarter, in exchange for timed or permanent exclusivity to the Epic Games storefront. Also, any game made by Nintendo will never be released on any platforms other than Nintendo consoles, unless Nintendo decides it isn't worth making any new hardware.

Id Software still owns the Doom IP, despite the fact that they made the Doom/Doom II game executable source code available under the GNU GPL v2, and people still need to buy Doom or Doom II if they want to play either game. Similarly, Freespace 2 has its source code released under a restrictive non-commercial license, but people still have to buy Freespace 2 in order to play it with FS2_Open, even if there are free games and standalone total conversions like Diaspora: Shattered Armistice which run on the same engine.

If a studio decides to remake, or produce a new series entry for a video game that they previously released the source code for, they could decide to take down the source code repository and all of its forks.

This may be why Electronic Arts won't release the source code for the classic Wing Commander games. The code is the intellectual property of Origin Systems/Electronic Arts, and as you would expect from any AAA studio, they have a policy to protect their proprietary assets. Someone on the ZDoom forums suggested doing something similar to try and get the source code for Duke Nukem 3D: World Tour released, but since it's owned by Gearbox, that won't happen either. The Duke Nukem 3D: World Tour support in Raze was reverse engineered.

Erasure

Video games, like all copyrighted materials, are controlled by the copyright owner. The copyright holder may decide to de-list or erase their video games at any time and for any reason.

One such reason could be the expiration of a timed licensing deal between the developer and another copyright holder, such as a music label. For example, one of the reasons Spec Ops: The Line was de-listed was due to a music licensing issue.

Also, in the aftermath of the Nintendo vs. Tropic Haze LLC. lawsuit, a team of developers forked the Yuzu emulator and called it suyu. The takeaway from this is that if a project is Open Source and very popular, it will be very hard if not impossible for the copyright holder to erase it entirely. If one person has a copy of the source code, they can re-upload it to any public source code repository.

Ownership

Even if the game's source code could be otherwise released, a lot of developers will still want to retain ownership of their game in the sense that they worked hard on it, and therefore, it's theirs and nobody else's, even if there is no other reason to keep the game's sources closed.

If someone invests a lot of time and effort into something, they become proud of what they achieve, and so they want to be compensated or restrict who is allowed to peruse their hard work and how it is used, so that the creator can trust that the user won't abuse the work. And there's also the fact that money motivates people to do a lot more than what they would if they weren't going to be paid.

One of the biggest reasons Copyright law exists in the first place is to enforce the conditions artists put on their works, and to ensure they are rightfully compensated for others using or perusing their works.

But when others are allowed to contribute to something, it becomes questionable who owns the completed work, and this can lead to problems like individual contributors wanting to impose extra conditions on their contributions, even if such extra conditions contradict the philosophy of Free/Open Source software or the individual project. Usually, such issues can be solved by having contributors agree to a contributor license agreement before they contribute.

International Affairs

Sometimes, international affairs can affect decisions to release the source code for a video game. For example, the developers of BioShock had to tighten IT security measures because of hackers working for the Russian and Chinese governments. It's hard to conceive why government hackers would want the BioShock source code in the first place; maybe the source code might contain other corporate secrets, such as multiplayer protocol specifications or passwords?

On the other hand, Gaijin Entertainment released the source code for the Dagor Engine, which powers War Thunder, and the reason is rumoured to be international affairs. Before Russia began waging the war in Ukraine, Gaijin Entertainment had an agreement with VKontakte to give them the source code for the Dagor Engine, to use as a basis for their Nau Engine. Because of recently-imposed sanctions on imports and exports to/from Russia, Gaijin Entertainment had to figure out another way of giving VKontakte their source code, so Gaijin decided to release the Dagor Engine source code in a public GitHub repository.

Reverse Engineering

All proprietary license agreements forbid reverse engineering the machine code that the game executables are in. You are only allowed to play the game, and unless the studio officially releases mod tools or documentation on the file formats, mods are illegal according to the terms of the EULA.

Despite this, if a large part of a game's source code is publicly available, that could make reverse engineering other games built on the same engine much easier. There are reverse-engineered source ports of most, if not every game built on Ken Silverman's Build Engine, including the closed source Build Engine games: Blood, Redneck Rampage, Witchaven, Tekwar, Legend of the Seven Paladins, and Powerslave/Exhumed.

The fact that reverse engineering is illegal also never stopped devout fans from trying to mod or reverse engineer their favourite games, as can be clearly seen in the Wing Commander fandom, with projects like the Model Upgrade Pack for Wing Commander: Prophecy and Secret Ops, which is a bit like the MediaVPs for FS2_Open.

Tight coupling of code and assets

If you've worked with the Godot Engine, you'll know how it works. You create parts of a video game in Godot by adding nodes to a scene, and then you add functionality to these nodes by either choosing a built-in node type with built-in functionality (such as a ragdoll, soft body, or rigid body) or by using GDScript to implement the functionality yourself. A lot of modern game engines work similarly or use another well-known game design pattern such as Entity-Component-System, so that the developers can implement a wide variety of gameplay mechanics, scenarios, and challenges for players to overcome, such as the quick time events at the end of the wolf cave in Tomb Raider.

For example, if you're trying to make a boss for a Souls-like game, you may want to make the boss react in a certain way once you hit it in a certain "weak spot", and to make this work, you may need code which is tightly coupled with the node hierarchy, or even the assets themselves.

Due to how closely the scene node setup may be coupled with the code, such as for a modern game like Control, it may not be possible to release the code without also releasing (at least some of) the assets, or allow others to create replacements for these assets like how Freedoom replaces all of Doom's sprites and textures. In order to allow others to properly modify the original asset or its code, the assets may need to be released along with the code. And if a public source code release contains any of the assets, it potentially defeats the purpose of buying the game in the first place, depending on how many assets are released.

Shelf Life

A lot of games are usually picked up, and then put down once players are done with their first playthrough. The news of Elden Ring's rapidly declining player count is evidence of this. There is little benefit in releasing the source code for a game that has such a short shelf life, unless it's a timeless classic that has gained a significant cult following since its release.

And usually, when it comes to big-name AAA games, the studios keep their game franchises alive by rereleasing older games in the franchise, developing sequels to the existing games, and/or developing and releasing new DLCs and expansion packs for the existing games. This is more profitable than letting people have the source code and do what they want with it because remasters and rereleases usually come several years after the original release, and are marketed like most other contemporary games.

Erlend Sogge Heggen of Spicy Lobster Games talked about Everlasting Games in one of his blog posts. In short, these are the kinds of games which have a theoretically indefinite shelf life because people enjoy playing them the first time, and that enjoyment leaves a lasting impression and inspires them to want to build upon that experience, and so they will if they have the ability to do so. Everlasting games are the kind of games that benefit the most in terms of longevity from being Free Software/Open Source, being fully customizable and extensible to the very core.

On the other hand, an Open Source source port of a video game can potentially extend its lifespan far beyond what the developers expected at the time of release. For example, The Force Engine can be a reason for someone to buy Star Wars: Dark Forces in the current day and age, especially because people can get an equal or greater amount of value than a modern proprietary game from an "Everlasting game" which keeps on growing because of its fandom.

Conflicts with Free/Open Source philosophy

The GNU OS website has an entire section dedicated to laying out the philosophical groundwork for Free/Open Source software. It says a program is Free Software if it grants users the four freedoms:

  1. The freedom to run the program as you wish, for any purpose.
  2. The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
  3. The freedom to redistribute copies so you can help your neighbor.
  4. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

And if a piece of software is proprietary, it is most likely (ab)used as an instrument of unjust power over the users.

The freedom to use the program for any purpose

It's hard for me to imagine what video games could be used for other than personal entertainment, social interaction, or education. People can learn actual medical skills in America's Army, but that's an exception to the general rule that video games serve little, if any, practical purpose.

Game engines, on the other hand, can have plenty of different use cases. I've heard Unity3D supports GNU/Linux because it is used in the automotive industry, and those people use GNU/Linux. The Godot Engine is used to make games for casinos, since some of the sponsors listed at the bottom of the Godot Engine website are casinos.

The freedom to study how the program works, and modify it to suit your own needs

Free/Open Source projects are forked all the time. For example:

Video game studios, especially the big-name studios, typically don't build technology with the intention of licensing it out to third parties; all of the big-name studios have their own game engines: EA has Frostbite, Bethesda has id Tech 5, Crytek has Cryengine, and Amazon has Lumberyard. These studios' executives probably do not want other people using or modifying their engines. In addition, the big-name studios' engines may incorporate one or more third-party proprietary technologies such as Autodesk Beast, Speedtree, or Havok, and if the source code for any of those pieces of proprietary middleware were to be leaked, it would cause a lot of legal trouble for the people that leaked the middleware code.

However, Epic Games and Unity Technologies have made their game engines, Unreal Engine¹ and Unity3D², available to anyone. Aside from that, the Godot Engine was originally developed by Juan "reduz" Linietsky and Ariel Manzur for their freelance game development work, and it is now Free and Open Source under the MIT license.

  1. An Epic Games account is needed to access the Unreal Engine source code. However, I don't know if there are any additional conditions that you must meet for Epic Games to grant you access.
  2. Unity Technologies lets people use the engine, but AFAIK they do not offer the source code to developers.

However, that was just talking about the engines. Unfortunately, individual games rarely ever release their source code, unless they were made for a game jam, or by a small indie developer enthusiastic about Free/Open Source Software.

The freedom to copy and redistribute the program

Obviously, copying and redistributing nonfree game engines or nonfree games is copyright infringement. In most cases, the developers don't want anyone else distributing their games without their permission, so that the original developer is compensated for all their hard work.

In addition, the fact that DRMalware such as Denuvo Anti-Tamper is widely used in the industry speaks volumes about what game developers and publishers think about players trying to copy, redistribute or modify the game.

Aside from that, part of this freedom is allowing others to sell copies of the program for profit. If the license does not allow resales, the license is considered to be nonfree or "Source-available", like the licenses for FS2_Open or the Defold game engine.

The freedom to distribute your modified version of the program and its source code so that others may benefit from it

If game developers don't want people to modify or redistribute their games, there's no way these game developers would willingly allow people to distribute modified versions of their games.

However, modifications for games are often distributed as a pack of modified game data files, along with any additional data files required for the mod to run. Mods are often applied to the game by having the game load the mod data pack, or by replacing the original game files with the ones from the mod.

Modders are more likely to have a mindset compatible with Free/Open Source software, since they aren't making money off of their mods and typically have no intention of doing so, and they are members of a community built around modding a particular video game.

Many modders/developers in the Doom fandom share their source code and are OK with others studying or learning from their code. But not every modder or game developer is OK with sharing their source code and allowing others to benefit from it, as can be seen in other active modding communities outside of the Doom fandom.

Conclusion

There are many reasons Open Source games are very rare outside of games made for game jams, and these are just some of them.

Gaming and software freedom can be compatible with each other, but due to the nature of gaming and the ecosystems built around it, there is an enormous market for video games, and so most video games are proprietary and commercial, and that is unlikely to change any time soon.

And if a game supports GNU/Linux and works on your system, you should be grateful the developer even bothered to support GNU/Linux at all.

When Games become Open Source

However, exceptions to rules given in this article seem to happen on occasion.

  1. Back in 2020, EA Westwood got in touch with their community, and released some of the source code for Command & Conquer: Tiberian Dawn Remastered Collection in order to help the OpenRA developers.
  2. And, on February 27, 2025, EA released the source code for Command & Conquer: Tiberian Dawn, Command & Conquer: Red Alert, Command & Conquer: Renegade, and Command & Conquer: Generals/Zero Hour after working with Luke "CCHyper" Feenan.
  3. Pumpkin Studios released the source code for Warzone 2100 (which was released for Playstation 2 as well!) in 2004, and it lives on to this day.
  4. Volition released the source code for Freespace 2, which gave life to FS2_Open, and the Hard Light Productions community.
  5. The Communist Dogifesto included the source code with the game download.
  6. The developers of games like Doom, Quake, Barony, and Aquaria were generous enough to put out the source code for their games, but you still need to buy the game (for the audiovisual content) in order to play it. There is an interesting story behind Doom's source code release, and several indie games built on the Doom engine or its numerous forks.

For a lot of other games which are listed on Wikipedia's list of Open Source games or elsewhere, but not in this section, the reasons for these games getting source code releases often involves unfortunate circumstances regarding the project or the people working on it, and they release the source code as a way of divorcing themselves from the game.

For example:

When a game gets an Open Source release like this, it may be taken over by another studio, if the Open Source release has a license that allows for it: Duelyst was taken over by Dream Sloth games, and they came out with Duelyst II; Paragon was taken over by Omeda Studios, and renamed to Predecessor.