Jump to content

  • Log In with Google      Sign In   
  • Create Account


Like
0Likes
Dislike

You Don't Need to Hide Your Source Code

By Julian Marchant | Published Dec 20 2013 05:07 PM in Business and Law
Peer Reviewed by (jjd, CRFaithMusic, jbadams)

source code open source free software DRM

The Case Against Proprietary Software Games


For decades now, it's been fashionable for game developers, along with other software developers, to withhold their games' source code, keep it secret. But why? As far as I can tell, people do this not because of any inherent benefits they see to withholding the source code, but because everyone else (well, almost everyone else) does it. In truth, there is no reason for people to be doing this.

Don't misunderstand me: I don't just mean to say that there's no reason for people to be doing this with non-commercial games. Keeping source code a secret is unnecessary for commercial games, too. Commercial games are perfectly viable without keeping their source code secret. In fact, I am going to argue that not only is there no harm in the public having access to the source code; there is not even any harm in putting the source code under a Free/Libre and Open Source Software (FLOSS) license.

The Point of Source Code Secrecy in the First Place


"What?!" I hear you say. "How can there be no harm to my business in making my game FLOSS?" To understand the answer to this question, you must first understand what the point was in keeping source code secret in the first place.

Understand: keeping source code secret does not by itself do anything to stop unauthorized copying. A binary distribution of a game can be distributed just as easily as source code. Therefore, there must be some other reason this trend of keeping source code secret started.

The practice of withholding source code came about in 1969. IBM was the first party to charge for its software and withhold the source code to it. One has to wonder why IBM refused to provide source code, though; after all, copyright law already gave IBM a legal monopoly over the distribution of that program. So what was the purpose of keeping the source code secret?

The answer is simple: the point of withholding the source code was not to make money from distributing copies of the program, but to have an additional monopoly on support services. Because only IBM had access to the source code to its software, any time users of the software needed a new feature added or a bug fixed, they had to go to IBM, and IBM could charge more for the services because of this.

So in fact, the original reason for keeping source code secret, gaining a monopoly on support services, is not even applicable to video games. Video games aren't even tools, and video game developers don't sell support services. People who play the games just buy them once and play them, or pay a regular fee for continued access to a server.

The New Point of Source Code Secrecy: DRM


More recently, a new reason to keep source code secret has arisen: DRM, which proponents say stands for "Digital Rights Management", though I prefer the more clear and accurate term, "digital restriction mechanisms". Basically, a digital restriction mechanism is a mechanism which intentionally restricts what a user can do. Put another way, it's the function of refusing to function.

Keeping source code secret is essential to making digital restriction mechanisms work. If the user has the means to remove the feature that restricts them (the source code), the restriction can't work reliably.

But even if small video game developers were able to put effective digital restriction mechanisms into their games, and even if the public was not strongly against restriction mechanisms, it has been shown time and time again that digital restriction mechanisms just doesn't work. There is a reason DRM use has died in music: it has been clearly demonstrated that it doesn't stop unauthorized copying. All it does is inconvenience legitimate customers and encourage them to obtain unauthorized copies that will actually work instead of buying authorized copies that won't work.

In short, source code secrecy is needed for digital restriction mechanisms to work, but such mechanisms are not any good in the first place.

Game vs. Game Engine


So it's clear that keeping the source code to a commercial game is completely unnecessary, but perhaps you think that, while it would be fine to distribute the source code to your games, it would be suicide to release that source code under a FLOSS license such as the GNU General Public License. After all, if you did that people would be able to just share copies of the game freely; how would you make money in that situation?

In fact, it might still be possible to make money in that situation. Crowdfunding can theoretically earn you money upfront to pay for the full cost of developing the game plus a good paycheck for the developer(s). It's also been shown that people will pay for quality entertainment such as games voluntarily; the Humble Bundle is a good example of this in action, and there are even some FLOSS games such as Sleep Is Death which use this model.

But these ideas have not had thorough testing, so let's assume that while these methods may work for some developers, they won't work for every developer. To understand why the most widely-used method of making money from game development, selling copies, would be unaffected by releasing the source code under a FLOSS license, you must understand and be fully aware of the distinction between the game and the game engine.

You may tend to think of the game as being one piece, but in fact it's made of two parts: the game engine, and the game data. The game data further consists of two major parts: the art assets, and the scenario.

The art assets are, obviously, things like sprites, 3-D models, sounds, and music. What exactly the scenario is depends on the game. In many simple games, the scenario will be a collection of levels. In some scrolling shooters, the scenario might be a list of what attack patterns to use at what times. In RPGs, the scenario will be a combination of the world, the quests, and the story.

The other half, the game engine, is the source code: the software that allows users to play the game.

With this distinction kept in mind, it is fairly obvious how one might make money from a game that uses a FLOSS game engine: simply leave the game data or even just the scenario proprietary.

Benefits of FLOSS Game Engines


You might be asking now, "OK, but what's the point in releasing my game engine as FLOSS, anyway?" There are currently four main benefits:

Additional Exposure

Hopefully this is temporary, but currently, there are thousands and thousands of proprietary software games out there. There are far fewer FLOSS games. Being a part of this smaller pot as well as the larger pot of all games gives your game more exposure.

Benefiting from Other Developers

When several game developers release their engines under FLOSS licenses, this means that code reuse is possible on a much larger scale than when everyone keeps their own game engines to themselves. This makes it possible for faster and easier game development by all FLOSS game developers.

Easy Cross-Platform Compatibility (if you use the right libraries)

One major weakness of proprietary software games is they will only run on platforms you specifically support.

With FLOSS games, you don't need to worry about it; just provide binaries for some popular platforms and users of all the other platforms will do just fine compiling the source code themselves.

Volunteers May Help (though they probably won't)

It is popularly claimed that releasing a program as FLOSS will cause a lot of people to come over and fix bugs. In fact, this is false most of the time, but one thing that is certainly true is that it is possible for volunteers to contribute to a FLOSS game, and some may do so if the game is sufficiently popular.

Counter-Arguments


I can think of three major counter-arguments against the use of FLOSS game engines:

"If I release the game engine as FLOSS, someone is just going to easily make their own game data and outcompete me."

In fact, for most games, making a whole new scenario is hard work, and most people just can't be bothered to do it. Take Freedoom, for instance; Freedoom is a project that has been in development for much more than five years as of 2013, and yet it is still in alpha. This can be attributed to a combination of lack of interest (everyone wants to play Doom or Doom II, not Freedoom) and the amount of work that needs to be put in for it to be done.

This contention is true enough for some games; Minecraft, for example, doesn't have any creative scenario to speak of (the scenario is entirely randomly generated), and in fact there are already suitable replacements for the art assets of Minecraft in a FLOSS clone, Minetest. But most games are not like Minecraft; most games have a significant enough scenario that any free replacement for it is not likely to cause a loss of profit.

"I won't be able to benefit from other people's engines, but other people will be able to benefit from mine without giving anything back to me."

This would be true if you released your game engines under permissive licenses, such as the Expat License (often ambiguously called the "MIT License"). But fortunately, this is not the only option. The thought of proprietary software benefiting from his work freely, giving them an unfair advantage, was the very reason Richard Stallman pioneered the concept of copyleft, which ensures that anyone who uses the FLOSS code in question does not do this. The most popular copyleft license, and the best choice in most cases, is the GNU General Public License.

"I don't want to share my source code because I think it's art (or some other similar reason)."

To be frank, I think this is as delusional as claiming that a DVD player is art because it's playing a wonderfully artistic movie.

Most game engines simply are not art. They are simply an interface to allow players to play the game. It's the actual game, the scenario, which is art.

If there is no scenario to speak of in the game, that doesn't make the game engine art, either. It rather makes the game more analogous to a simple toy than a DVD player playing a movie. Much like simple toys, such simple games don't tend to qualify as art.

Don't get me wrong; I appreciate code as much as the next guy. I'm a programmer, after all. But there's a difference between appreciating code and mistaking it for art.

"My source code is sloppy and/or inflexible; there's no way people would find a use for it."

The assumption that people won't be able to re-use your code might be unjust. Statistically speaking, no matter how good your code is, most of it isn't going to be re-used. But every program has a potential for re-use, including sloppy ones. If there is enough love for a game, that sloppy code will eventually become less sloppy.

Even if no one is interested in re-using your code for something else, that doesn't make the release of the source code meaningless. It is something the free/libre software community will appreciate, which gives you more exposure, and it makes it possible for the game to run on any system without you specifically supporting that system, assuming the game's dependencies run on those systems.

Conclusion


As you can see, not only is keeping the source code to your games unnecessary, you may be missing out on useful benefits because of it.

Of course, you can continue to make your game engines proprietary. It's your choice. But I hope you will make the wise choice: choose FLOSS, and don't look back.

Article Update Log


5 Dec 2013: Initial release
6 Feb 2014: Added an objection



About the Author(s)


Julian is an amateur game developer and FLOSS advocate. He has developed a handful of games, various small utilities, and a general-purpose 2-D game engine, all released under FLOSS licenses.

License


Public Domain




Comments

There are a lot of other reasons games developers might not want to release source code:

 

* It's a dreadful mess - yes, really

* It includes lots of incompatibly-licenced components, in source form, its own source tree, possibly with undocumented modifications

* Nobody would *EVER* be able to compile it anyway. The build system is far too arcane and relies on countless other in-house build-time components from the studio, which would also have to be released, modified etc, to give any third party any chance to build the game from source. We don't have time to do all this extra work.

* Therefore, nobody would actually be able to benefit from it

* Cleaning up the code-base for release, preparing documentation and getting appropriate clearance from legal team etc, takes up time that we don't have when trying to make a game!

 

Basically, the source code of a real, commercial game is huge, messy and held together with string and duct-tape. Much of it isn't documented. A lot of it is from third parties. The build system is arcane.

 

Anyone who actually wanted to licence the source code to title X, would have to gain IP authorisation from all the dependency libraries (do-able, if it was another game dev house), buy licences for all the commercial tools required to build it, and get considerable support from the original dev team.

 

This is not going to happen for a A+ title. It might happen for a small mobile game or something, but it's fairly unlikely.

As soon as you said code wasn't art I kind of tuned you out.. The best programmers in the world will all tell you that programming is part science and part art. Writing clean, beautiful code that functions at peak efficiency with minimum amounts of code is absolutely 100% an art form. This isn't structural engineering, there isn't some book we can use to look up the "strength of concrete" as it were. Every software solution has to be crafted from a toolbox of a million tools, no different than a painting has to be made from a million colors. Sure there are theories and best practices and methodologies that help give some structure, but art has all of those as well. Go look up art theory sometime, it's an incredibly complex and scientific subject, yet it doesn't mean that art stopped being art.

 

The best programmers in the world are absolutely Van Gogh's with a text editor.

As others have mentioned, there are many reasons for why you wouldn't want to release your source code:

 

1. People aren't going to learn much if anything from looking at your code. If they're looking at it then they're a) wanting to make a cheat for your game, b) are just curious about the number of lines it takes to make a game, or c) are looking for something they can sue you over.

 

2. To elaborate on 1.c. above, if you happen to use any patented code in your game, regardless of whether you came up with it on your own or not, you're giving other developers an open invitation to send you a cease and desist - hell, you're giving them an invitation to drag you into court for making "THEIR" code available to the public without permission... Good luck fighting that case.

 

3. Let's say you develop a game for Windows, but haven't gotten around to porting it to a mobile device (which your fans are demanding). You release the source code and the community makes their own port. Not only do you lose all of those potential sales, but you'd piss everyone off if you tried to shut it down.

I should send this to my boss, he'd get a good laugh.  Good luck getting anyone to invest money into your game if your source code is open source.  The premise of this article is flawed, and that is demonstrated by this statement:

 

"Understand: keeping source code secret does not by itself do anything to stop unauthorized copying.". 

 

Businesses do not keep their source code a secret to prevent unauthorized copying.  There are other measures built into software and sometimes even hardware to prevent this sort of thing. 

 

The purpose of keeping source code a secret is all about equity.  Source code is an asset.  Businesses spend anywhere from tens of thousnads to hundreds of millions of dollars building source code.  The applications themselves are valuable, yes, but the real value is in the source code itself.  By exposing the source code of their applications, a business would essentially be inviting competitors take what they spent their hard earned cash on, and put you out of business.  Additionally, sometimes in business the only thing you have on other competitors is a head start, and by giving out your source code, you forfeit that advantage as well.

 

I understand where you are coming from, and it is noble, but naive.  Businesses take OSS every single day, brand it as their own, and give absoutely nothing back to the community, and snicker "those open source idiots, they saved us millions, and we dont have to give them a dime".  I'm not saying OSS is bad.  I love OSS and contribute to it myself.  But the way us idealistic software developers think of OSS is not how the majority of the world, especially the MBAs, think of it. 

 

TLDR - OSS is great, but sometimes its best to keep things to yourself, especially if you are trying to make money and/or have competition. 

Two words: intellectual property.

 

I don't understand the purpose of this article.  Why *should* the source code be expected to be included with commercial software??

As you can tell by all the replies so far, this article clearly isn't written by somebody in the video games industry.  It's misleading, ignorant, and just plain wrong.  Having it on the front page of gamedev.net for over 2 weeks now is doing this site a disservice.

 

At some point an editor needs to step in.

 

PS. I've been on a commercial game that had to undergo a code audit due to an patent infringement lawsuit.   In the case of the lawsuit, the company merely suspected we'd infringed, and that was enough for the courts to require us to give up the code.  It turned out fine for us, but other developers didn't fare as well. To freely open yourself up to one of these things every time you release a game is insanity.  

Suppose you worked hard on a very unique game feature that makes your game feel different (for example, the gravity in Mario Galaxy), would you really want to share that with Zynga ? And saying that programming is not art is totally wrong especially in object oriented design.

I would only like to point out what happend to Wolfire with Lugaru on the Apple App Store.

 

In short they were selling their game for 9.99, and somone submited the same game for 0.99. 

You can read the whole blog post from Wolfire here.

I'm glad my article has generated so much discussion. I just want to answer some objections.

I think there's a common misunderstanding: I never said that FLOSS games would be better business for large companies. I only said that it can work, and I was speaking mostly of indie games.

I'm seeing some objections which simply don't apply to indie games, most notably licensing engines. Yes, licensing engines makes a lot of money for big companies, but indie games rarely become that popular to begin with, and even if they do, their authors have nothing to gain by licensing use of the games' simple engines to other developers.

I am also seeing ignorance of copyleft. For example:
 

Businesses take OSS every single day, brand it as their own, and give absoutely nothing back to the community, and snicker "those open source idiots, they saved us millions, and we dont have to give them a dime".

 

Businesses can only do this with permissively licensed software. That's why Richard Stallman invented copyleft licenses. If a business chooses to use your copylefted software as a part of a program they are developing for distribution to others (like a game engine), it has to give back any additions it makes to the community.

Someone mentioned patent lawsuits being a potential problem, but this isn't a legitimate reason to hide source code. Software idea patents are such a huge problem that someone is bound to be able to sue you for patent infringement without ever needing to see your source code. You aren't made safe from patents by hiding a few algorithms and equations. The only way to be truly safe from software idea patents is to never develop or use any software, or live in a country that forbids such patents.

Some people are seriously over-estimating the amount of creative competition that would result from everyone being able to make a variant of your game. I gave the explicit example of Freedoom, but let me put it a different way: have those of you making the claim that this kind of stuff is going to prevent a sequel from being possible, ever tried sorting through all the user-created crap, just looking for something that's kind of fun? There's practically zero confidence in a bunch of anonymous enthusiasts making a fun game that you would like to play even in the rare case that a large number of people make games to begin with. If the original game's scenario is fun, there is going to be confidence that official scenarios are going to be fun.

On the other hand, some people are seriously under-estimating the effort volunteers will put into making a game they enjoy run on their preferred system. Project: Starfighter is a simple 2-D space shooter game that I really liked. At one time, I really wanted to play it on the OpenPandora Pandora. Project: Starfighter had pretty much every display element's position hardcoded with an assumption that the game window was 800x600 pixels, and the Pandora's resolution is only 800x480. I dived right into the mess, converted all the values so that it would run nicely at 800x480, and shared my port with other Pandora users.

Some have suggested that FLOSS online games are more susceptible to cheating. I can't think of any FLOSS online game that has a cheating problem. The only one I have played a lot is Minetest, which I know is basically completely immune to cheating, while ironically I hear that it's possible to cheat on at least some Minecraft servers because of client-side mods. If you host a server for any multiplayer game, you have the power to stop people from cheating. Even in cases where cheating is technically possible, it's trivial to simply make a rule forbidding cheating, and kick or ban anyone who is caught breaking the rule. For example, AssaultCube has no technical cheat prevention mechanisms at all, and yet I have never once had a problem with people cheating. Also keep in mind that most people are playing games because they want to have fun, and cheating isn't fun.

Some have pointed to server competition in MMORPGs. The factor being ignored here is that it costs money to run a server. Nobody is going to step in and host a server voluntarily unless the official server is unsatisfactory enough for the cost to be worth it, and the game is popular. Commercial competition, on the other hand, wouldn't work unless it grabs players' attention somehow; fulfilling a particular niche an official server doesn't, adding a great new feature, etc. If something like that does happen, and the server software is under the GNU AGPL, any improvements have to be released, meaning official servers can then incorporate some or all of these improvements.

 

Some have pointed out the difficulty of licensing code. But that's existing proprietary code; designing source code to be FLOSS from the beginning is much easier.

 

Again, I'm glad there has been so much discussion here; it's much more than I expected. Sorry I missed it when it was happening, too; I didn't know this article was published already.

Well, I find it disrespectful to say that a programmer thinking that his work is art is delusional.

 

Programming is an art, like drawing or composing musing, and thus a program source code is a work of art as much as the game assets to me.

 

I think that the DVD player too is art, but it does not have anything to do to the movie it plays.

Most games aren't open source because code reveals algorithms and techniques, which can be very valuable and easily exploited (to make convincing trojan horse "add-ons," for example).

Do you not make games so that they can be played and enjoyed? Games will always be pirated, copied and distributed; there is nothing you can do about that.

On the case of multiplayer hacks: if you do not write proper multiplayer code, the hacks will pop up anyway. Might take a few months longer but it will still happen. Client-side anti-cheats are worthless as well, rather do sanity checks on the server.


Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS