I wish to develop a computer game and the engine I have chosen is ioquake3. This engine is licensed under GPLv2. Needless to say the game's source code will itself will, in turn, be licensed under GPLv2. The game data/assets on the other hand will be proprietary. I intend to release this game as a free-to-play app across various app stores with in-app-purchases for additional game data/assets. What I would like to know is if the code for the in-app-billing logic must also be included in the published GPL'd source?

  • All code must be GPL'd.
    – ArtOfCode
    Commented Feb 12, 2016 at 21:45
  • @ArtOfCode that depends on the exact license of the tool, and it's relation to the game. I.e., the game is data interpreted by the engine. And if OP creates the game, they can license it (or its pieces) as they wish.
    – vonbrand
    Commented Feb 12, 2016 at 23:12
  • 1
    @vonbrand yes, technically. But GPLv2 is so viral and so strict that it's often far easier just to assume total coverage.
    – ArtOfCode
    Commented Feb 12, 2016 at 23:16
  • 1
    @ArtOfCode if important, have it clarified upstream (or have your very own lawyer check it)
    – vonbrand
    Commented Feb 12, 2016 at 23:17
  • @ArtOfCode you wrote "GPLv2 is so viral" .... this is unwarranted FUD. The GPL is a fine license with some reciprocal rights and requirements built-in but qualifying it of viral is using grossly inappropriate language IMHO. Commented Aug 19, 2016 at 11:23

2 Answers 2


What I would like to know is if the code for the in-app-billing logic must also be included in the published GPL'd source?

It depends how this billing code interacts with the rest of my GPL-licensed app. I provided a comprehensive overview of dependencies here

In general if my billing code is not linking with the GPL-licensed code and interacts at arm's length such as in a separate process it may not be subject to the GPL. The devils is in the details. Best will be to get an advice from a FLOSS-savvy lawyer. Heather Meeker has an excellent book on the topics

  • I really don't see any case where this billing code would operate "at arm's length" with the rest of the software. See this reference gnu.org/licenses/old-licenses/… for more details on what is aggregation ("at arm's length") and what is combination.
    – Zimm i48
    Commented Aug 19, 2016 at 19:02
  • Not knowing the architecture of the code in the large and in the small, I cannot answer that. But they are likely several ways for both pieces of code to work independently "at arm's length". Commented Aug 19, 2016 at 23:04

General advice

Section 2.b of the GPL 2.0 states:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

and later sections 2 also reads:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

What this is saying is that by making a game that incorporates an engine under GPL 2.0, then the full game must be distributed under the same license. That is the full thing, including the billing logic, and also including the assets.

As a general consequence, you should avoid game engine under GPL if you want to develop proprietary games.

I can see that this does not seem to be the opinion of the authors of the engine since the README states:

This does NOT mean that you cannot market this game commercially. The GPL does not prohibit commercial exploitation and all assets (e.g. textures, sounds, maps) created by yourself are your property and can be sold like every other game you find in stores.

But also not technically inaccurate, this paragraph is misleading. It would probably be a good idea to ask them why they don't license their engine under LGPL 2.1, 3.0 or MPL 2.0 if it is their intention to let people make proprietary games with their engine.

To keep some assets proprietary

You can keep some assets proprietary if you make sure that they appear as "independent" from the game itself. It would not be the case of an image that is needed to navigate the game menu. But it could be the case of a game level depending on the way this is encoded.

To make an analogy a GPL music player may be distributed with some example tracks. These tracks are clearly an independent work from the music player even though a music player is useless without any track to play. Thus they can be distributed under another license.

If the game levels can be contained in files that make them similarly independent of the game software itself, then these would not need to be distributed under GPL.

To keep part of the code proprietary

The only way to keep part of the code proprietary is to create two independent programs which can talk to each other via files or pipes or similar "arm's length" communication.

For instance, in the case of your billing logic, it could be an independent application which would be there to download or unlock new levels.

However you say that you distribute your game through an app store. I don't know if app stores allow in general the distribution of two programs in the same package.

  • Derivative works is a complex topic. You cannot make a blanket statement without having specific details of how things interact. Commented Aug 19, 2016 at 23:01
  • @PhilippeOmbredanne: you are technically right. But we keep giving people the answer "it's complicated" and waiting for details, and making them believe it may be easy to "escape from the reach of the GPL". I think we should have the opposite approach: give the answer concerning the derivative work when it feels like it is what is going on, unless given additional details. It is not the intent of the authors of the GPL that people always try to find ways to avoid complying.
    – Zimm i48
    Commented Aug 19, 2016 at 23:47
  • 1
    I beg to differ there. IMHO posters coming here are not looking for the easy answer. Licensing is unfortunately complex and I really think that more nuanced answers are warranted. My experience is that most people are not trying to "escape from the GPL" but in many case need some genuine help to understand what they can do and cannot when using copyleft-licensed code with non-copyleft (be it FLOSS or proprietary). I think the value of this SO is in providing details. Commented Aug 20, 2016 at 6:49
  • @PhilippeOmbredanne: I've edited my post to address your concerns.
    – Zimm i48
    Commented Aug 20, 2016 at 9:38
  • 1
    I cannot see why assets (such as data, images) would nee to be GPL'ed here. The best examples are Linux distros such as Ubuntu and RedHat: their "branding" assets are NOT #FLOSS but proprietary and you cannot therefore wholesale redistribute a distro from Ubuntu and RedHat without stripping these "assets" first, which what Mint or Centos have been doing historically. Commented Aug 20, 2016 at 10:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.