Should I make my game open source on github?

Would it be a good idea to have my game open source and what license should I choose? Me, myself and I would differently benefit from having experienced people to help the development but would to be a positive or a negative move. I earn very little and is forced to work on a acer Travelmate 5610 laptop with 1.6 Ghz, 2.5 Gb ram and 256 mb graphics card - no higher than openGL 1.0 will load and I’m working with blender 2.69.
What would the pro’s and con’s be?

Technically your game is already under the GPL as soon as you publicly distribute it, since that’s the license infecting the engine. So there’s not much to think about there. What license you want your art assets under is a whole other story though.

I’d recommend something from the Creative Commons collection, though which specifically depends on your wants and needs.

1 Like

Speaking for myself on what others have said to my personal proposal to upload my game projects github, people like to see what exactly they are downloading and not a virus at times :slightly_smiling_face:
It’s also a nice version system in case your latest update version is bugged and newcomers would like a playable version - meaning they can just download a previous version if you’d uploaded your files correctly, sometimes with other repositories, sometimes not.


This is not true. You can make all the logic using logic bricks and then all the game will be under your own license (the game engine not).

The executable and any python scripts will. The practical reality is GPL, and it isn’t an issue either.

There are ways to add ‘protection’ so no one who downloads an UPBGE game can reskin your game and sell it as his own product (which the GPL allows), but the flipside is that it makes game publishing a little more difficult than the one-button build provided by all of the main alternatives.

Making the game FOSS or at least under the Creative Commons is one way to avoid dealing with the GPL legal jargon (which is the source of a lot of confusion over how it should be interpreted). Do note though that you could get flak if you end up accepting community contributions and then try to make it a commercial product (as people might tell you to remove their content and code).

1 Like

The executable is the game engine, not the game. And the scripts when they import bge or bpy libraries (or any other gpl library) only. Otherwise not.

Then the practical reality is that only several scripts will be GPL. The game will be under your own license.

And there are a lot ways to avoid even that (i.e. to make a client/server game with the logic in the server side).

1 Like

Don’t mix on purpose all the things, Ace.

1 Like

Are you distributing your scripts separately from the engine and the scripts that extend/inherit from it and it’s apis? I doubt it.

It is not necessary as long as you are not including .pyc, .pyo and pycache. This way the “dynamic” linking will be done by the user. It is called aggregate by GPL. I mean i distribute the scripts with “import bge”, etc under my own license but not compiled. It is the user when he executes the game then it will link against the library and that script will be GPL. The others scripts will follow under my license.

In the context of open source games the intent is to create a strong separation between technology stack and content. This way you can consider that open source development is mostly intended to enhance the technology stack and not the full game itself.

This means that technology-wise you are giving away the game for free, but your strong focus would be on the content from now on.

1 Like

From what I understand far as the FSF if concerned static vs dynamic linking doesn’t make a difference.

But if we are to consider your python scripts as purely data(especially as you said, in uncompiled/non-object code form) then you may have a point and at least the US copyright law might well be with you on this. But it would have to be tested in the court of law to be sure.

See for an example this linked answer here:

But again as I said previously I’d not be too overly concerned, the GPL might in practice limit you in the ways you can effectively sell your game but it doesn’t stop you from doing so and you still can license your art assets any way you want and you have every right to protect those assets. So you can and should still be able to protect those assets any way you want.

1 Like

Thanks guys, I started a new repository and added MIT license. I still have a lot to learn and obstacles to over come, the biggest is that my pc can’t handle openGL shader lang, so I’ll have to update my pc first. for now I’ll investigate all my options


I try not to, but it is clear to me that the UPBGE team has a different (and looser) interpretation of the GPL license than the BF does. That is not to mention that BGE/UPBGE is unique among indie engines in that you have people asking for guidance on how to put the executable together. This is compounded by the fact that unlike Linux and other solutions, the Blender GPL license does not come with exceptions.

The UPBGE Team have not a different interpretation of the GPL license than the BF. Please, stop to put your trash on our side. We know that you want to say bad words against us always.

The Blender FAQ says:

It is totally clear from the FAQ that if a script is inside of a .blend and it doesn’t use Blender Python API calls (or other GPL libraries) it can be licensed as you want.


No more negativity Ace :joy:
Reading these comments makes me Want to…

I’ll leave that to you to decide what I mean @Ace_Dragon :wink:


What are you trying to achieve by making your game open source?

Whats the intended goal behind your project being open source?

If you need help why not you just open up a private collaboration? Or Open team development???

The choice is yours and yours alone to make :wink::+1: I Can only wish you the best of luck as you commence with your project in UPBGE!

All the best bud.

Fred/K. S