I’m not sure about that if it happens to be the case when the Python API is used.
From what I’ve learned over the years, the .blend file is indeed not liable to the GPL in all cases, but that’s not the case for the Python scripts that make up the backbone of your game (due to its connection with Blender code). In a way then, your game will still be infected by the GPL because you need to have connections to GPL code to run your logic (the only real way otherwise is to have a new permissive engine that can interpret every logic brick and Python function).
Basically speaking, the fork gets an entirely new logic engine in place (with a commercial-friendly license) which then gets dropped in without the user noticing. All of that is a lot of effort though, but without the change, it will create a noticeable drag in any userbase growth and certain ideas such as iOS support will not be possible (I will also note that even Ton has realized that the GPL is not a very good license for game engines).
Python API bindings are not static, meaning the user downloads the game, and binds it separately himself (think loading a saved .blend)
The only thing GPL talks about is distribution,
It is not invoked by a user opening a separate library
Unless they are binding that library for distribution,
If your licenced for your game does not allow this, then your code is not GPL.
If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? (#IfInterpreterIsGPL)
When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.
However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.
Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
A consequence is that if you choose to use GPL’d Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
Apparently, you are right, I think…
If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.
Ok, so it only applies if the bindings are in place upon distribution, or if you modify Blender source code.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Awesome. My games no longer crash. Had a few weird quirks porting things over, but all is well. Specifically the motion actuator changes and for some reason KX_CharacterWrapper.jump() had stopped working. Not exactly sure how I fixed it…
@pqftgs: Yes the motion actuator changed for force and torque, i explain:
When the zero velocity was allowed there was no check and we always applied a velocity if it was equal to zero. Which mean that if you have a motion actuator with an applied force, this force was always mixed to the zero velocity applied.
To fix this bug i add a little check to avoid applying a force and velocity, the force, same thing for torque and angular velocity.
See commit https://github.com/UPBGE/blender/commit/819e6ccfb11d2a694085f7a99e29da698ac778f1
About the KX_CharacterWrapper.jump() i don’t see any problems, can you send an example ?
Should i do continue answering in this thread, or open an other : “UPBGE: Bugs and features” ?
Yeah that would be ideal. I’ll open an issue if I’m able to replicate the jump problem. It was pretty weird…
Edit
I restored a backup of the game in question, jumping still works fine. I’m guessing it was some obscure bug with the character controller. Maybe it was stuck barely under the ground or something. jump() was being called without error, but onGround remained True. Probably unrelated to this fork.
Edit x2
Nevermind I’m not crazy, was just opening the wrong backup. Jump starts working again after selecting the character and saving/reloading (it’s a linked group). I’ll file an issue once I can replicate the problem in another file…
Hope he’ll succeed!