OK, in another discussion on the forums, I’ve been hashing out the purely hypothetical capability of writing a reasonably generic scripting interface & releasing it under a license that would allow non-GPL addons.
The reasons for this are as follows:
Blender is a GPL application and the interface to it is also only licensed under the GPL
Addons targeting this GPL-licensed API must be, according to the FSF, also released under the GPL
Whilst there are ways and means to handle this (though requiring quite a bit of upfront & ongoing effort), the key point here is that although the addons are simply text data loaded & handled by the (non-GPL) Python interpreter embedded in Blender, the fact said text represents code targeting a GPL-licensed interface requires they too be released under the GPL.
Which brings me to the BGE where the Blender Foundation claims:
Games created in Blender (.blend files) are program output and therefore not covered by the GPL. You
can consider them your property, and license or sell them freely.
However, in almost every one of the BGE games I’ve seen, there is code that uses the BGE API. By the same rationale as used for addons, this would mean all code in a BGE game would have to be released under the GPL regardless of them being distributed with or without the standalone player. This is contrary to the above statement, because the code is embedded in said .blend filesThe Blender FAQ also states that:
Python scripts – if they use the Blender API calls – have to be compliant to the GNU GPL as well. We
are currently reviewing this with Free Software Foundation though.
I think the status of BGE games that use code targeting the game engine API (and all but the most simple ones do) needs to be added to this. I think it would be good to hear what the FSF has said to the Blender Foundation in this regard.
I think I recall someone saying that the Blender Foundation wrote a GPL exception for one or two things when they formally open sourced the software (which is something allowable by the GPL).
I’m not sure what they were though, perhaps someone close to Ton knows?
If they can do that for the BGE, they can do it for the Python API in the main application. However, as per other thread discussions on the matter have highlighted, the Blender Foundation does not have the copyrights for (or permission to relicense) all the code in Blender or the BGE.
As such, we’re back to the situation where either the Blender Foundation is allowed to write a simple GPL exception to the API (without complicated “generic API” workarounds) or the fact that there is GPL code in the BGE they don’t have copyrights too means the API is viral* to game code that uses it. The impression by Blender developers (& the FSF for that matter) is that the former is not possible which means that game code using BGE API’s must be GPL if distributed.
–
[SUB]* Again not a perjorative, simply the most applicable word I can think of for the situation.[/SUB]
@BTolputt, yep, your correct - the GPL will apply to all scripts in a game (the part about the scripts being embedded isn’t relevant, external scripts still execute in the same process).
Thanks Campbell. That’s what I thought. Appreciate the prompt answer
It might be worth someone changing the FAQ to mention this. Whilst it does mention Python scripts separately to the BGE blend files, the impression is left that games are free from the GPL when the majority of them would not be. There are a few long-term BGE users here that also believe otherwise & quote from the FAQ when supporting that position.
@BTolputt, No worries, I always found the GPL info in the FAQ rather confusing too (parts of it at least).
Before changing text here we’ll need get someone from the FSF to double check though (was planned IIRC but these things tend to get buried by higher priority stuff).
Technically, BGE games have long used Blender code when made into an .exe so having just the API exempted wouldn’t have been enough.
But we do have projects like the BPPlayer which allows you to ‘technically’ release the source by just having it encapsulated in a non-GPL box so you couldn’t actually get to opening the .blend. You’re still sharing the source, but you would need to be a hacking wizard to rip away the packaging.
Absolutely. Wasn’t speaking about that. I was speaking about the many & varied claims that the GPL doesn’t affect games so long as you distribute the .blend file only. As per Campbell’s clarification, and recent discussions in regards to the (im)possibility of proprietary addons for Blender, this is not the case for the embedded Python code provided any of it interacts with the BGE API (which, of course, 99% of all games created will).
This is not legal. the GPL stipulates that:
The “source code” for a work means the preferred form of the work for making modifications to it.
In order to comply with the GPL, you must provide the code in question in the form the developer preferred to make changes to it. If that was inside an editable .blend file - that would be reasonable, but otherwise I would expect the preferred form to be a set of files for each “text block” in the exported file. The GPL does not allow you to obscure the code when complying with the copyleft provisions.
I can write a closed license code with gpl editor, compile it with gpl compiler and run it in gpl linux using gpl linux API(system calls) creating a closed source application.
In blender, i can write scripts compiled it with bge to an executable and run it using the api calls.
I don’t think there’s any encryption of any type going on here, the source is completely intact, but it’s wrapped in a hard to open package (which I don’t think directly interfaces with the GPL code at all).
If the GPL does go out of the way to try to ban this sort of thing, then it pretty much would be impossible to have a good FOSS solution when it comes to game engines. A GPL game engine cannot produce secure commercial products and a permissive game engine will see developers branch it off into their own commercial product rather than contribute code to the original (which already happened to the GameKit project).
What might be needed then is a massive effort by the BF’s part to start re-licensing parts of Blender to a license more commercial friendly and get other FOSS projects to do the same, because the sooner that we can cast the FSF into a position of total irrelevancy, the better.
It’s a gray area of GPL. FSF talks about plugins, e.g. dynamically or statically linked code. To my understanding Python scripts are neither.
A good example is idTech 1 and idTech 4 game engines. idtech 1 (Quake) has engine’s code and game logic code. The former is an application, a program. The latter is an interpreted script compiled running on VM. iD Software made a clear distinction between the two, where engine is under GPL, and game logic script is not. That allowed game devs like myself making closed source game logic code that is used with GPL engine. Note that engine can run without it, there is no linking happening as defined in GPL license.
idtech 4 (Doom 3) has game engine, game logic framework and game logic scripts. The former two are .exe/dll and are under GPL. The former are interpreted scripts and are deemed to be game’s assets, and are proprietary. Meaning if written from scratch, they remain non-GPL, and yet can be used with GPL engine. It’s not possible to call them closed source as they are in plain ascii format.
Btw, FSF has no authority on what BF sets forth with Py add-ons. If BF says “add-ons can be non-GPL, closed source”, no one can overthrow that decision. Same true otherwise.
It doesn’t need to be encryption to be illegal. The GPL states that “source code” must be provided. It defines source code as “the preferred form of the (GPL licensed) work for making modifications to it”. As such, whether you are distributing it encrypted, obscured, embedded in a binary, or in automatically processed haiku - if it’s not the preferred form for making modifications to the work, you aren’t complying with the license. The only two preferred forms for Python code used in a distributed BGE file would be either the editable Blender file(s) or human readable text files (one for each text block & named appropriately).
Think of it this way, the GPL is about forcing someone that distributes the code into sharing the code so it can be read & modified for the user’s own purposes. If one cannot easily read & modified, you are not only going against the spirit of the license but, given it was drawn up by lawyers, 99% likely you are also going against the WORD of the license.
If the code is GPL (which writing to the BGE API will make any/all Python code in the game), you must share it in an easily understood, editable, and alterable form. That’s pretty much the start & end of it. It’s also why GPL engines are avoided like the plague by developers trying to make a living from their games.
It DOES go out of it’s way to ban this sort of thing. Stallman &, for the most part, the FSF in general are ideologically against software that is proprietary in any way. They believe if you get software, you should be able to view the code and alter it to your needs. That software can be anything from a compiler through to a game, but as long as there is code in it - they want people to be able to easily, & without technical hurdles, see what it does and alter it to suit their desires.
Essentially what you are asking for is an engine that cannot branched off into it’s own commercial product… but that you can branch off for your own commercial game (i.e. product). The GPL doesn’t allow that so long as there is code involved. You have copyright over the images, models, etc and that’s all well and good… but as soon as you write code that interacts with the BGE API - that code is also GPL and must be shared in a way in which it can be altered and used in the original product.
It’s a matter of deciding which freedom you want more - the freedom to hide your own code from the world (the GameKit BSD/MIT option) or the freedom to get read, use, and alter the code of anyone that contributes to the engine (the GPL BGE way). You cannot enforce both.
Yeah… that’s not going to happen. It’s not like the Blender Foundation is struggling against the GPL tooth and nail, wanting to break free. They like the GPL. They accept it’s faults (as we see them) and believe it’s a good trade-off for the freedom they get knowing that branches/forks of the code will still be something they can read, use, and merge back into trunk as they desire. Same goes for a majority of large GPL projects I’ve seen. There really isn’t a huge sentiment for “casting the FSF into a position of total irrelevancy”, even amongst those of us that don’t like the GPL for everything. Don’t hold your breath waiting for it to happen. No one is forced to use the GPL and, as such, the people that do tend to want the limitations it imposes.
According to the FSF, they are. Python scripts that use the GPL interface are considered derivatives of said interface. As the rights & responsibilities of the GPL are bases off copyright, it is not whether one considers something a plugin, library, or book of poetry - it’s whether it is considered a derivative work. Derivative works must obtain the right to use the original work and, in the case of Blender, that is through abiding by the GPL.
I would agree that it is a legally grey area, but only because the FSF position hasn’t been properly tested in court. There are solid arguments (made by Google against Oracle and being appealed at the moment I believe) that indicate API’s in & of themselves are not copyrightable and that “fair use” allows one to use them without obtaining copyrights. Thing is, I doubt there is anyone using Blender (or even in the Blender Foundation itself) that considers the fact the FSF hasn’t had this tested in court means it’s worth the legal hassle when they’re challenged on it.
That’s great for id software. Thing is, they own the copyright to ALL their code and can provide exceptions and clarifications that others cannot step in & veto. The Blender Foundation does not. It is using contributed GPL licensed code (& libraries, I believe) throughout the codebase AND it does not own the copyright to all of them. As such, they do not have the legal right to provide exceptions to the license such as provided by id software.
Um, not so. The Blender Foundation does not own the copyright to all the code and, as such, those that DO own the copyright to contributed portions and libraries CAN step in and legally overthrow that decision. Unless/until the Blender Foundation is willing to go through the code line by line, contribution by contribution, obtaining the copyright for or replacing everything they did not write themselves or obtain a copyright waiver for - what you state is not legally tenable.
Now we could argue this back & forth… or we could listen to Campbell Barton of the Blender Foundation
I guess in that sense, no worries, a few years from now and the Unreal 4 Engine will be the only game engine the world will ever need.
Though it seems like the interpretations regarding what the GPL says vary wildly on the forum (from people who claim to understand it), does Ton even know what’s all in it these days or is the GPL just too confusing for those who even practice law?
It’s not like the Blender Foundation is struggling against the GPL tooth and nail,
If people want Blender to become that piece of software that works well in pipelines, then it might be that Ton will have to stand up to the FSF and announce that he will start moving Blender away from the GPL effective immediately, because how do you know that the .fbx format won’t become GPL incompatible tomorrow, or decisions by MS and Apple force Blender to be exclusive to Linux. It might be either that or creating an entire ecosystem’s worth of 3D and other production technology in one app., it would require a good deal of effort either way.
@BTolputt: The thing is that if BF wrote API and modules that run Py add-ons, they can make an exception. Who will bring a lawsuit against them?
I don’t think ideasman42 is correct - assets are loaded by the same process and used by the same process, and are processed by the same process in RAM - yet, they aren’t becoming GPL because of that.
@Ace Dragon: Blender doesn’t need to become non-GPL, there is MAX and Maya that are already non-GPL.
Doubtful. Also, overreaction much? Just because the BGE isn’t going to let you live your commercial dreams doesn’t mean that every game engine the world over is suddenly not worthwhile. You do realise that there are huge indie hits using Ogre3D & the like right? It’s not a matter of BGE or nothing.
Firstly, trusting what people say in forums when it comes to legal advice is a recipe for bad mojo. The important thing to consider here is that the Blender Foundation and the FSF agree that addons & other code using API’s licensed under the GPL are made GPL by being derivative of the interface in question. You could ignore the people that wrote the license and the people releasing the API’s you’re coding against in preference to forum opinion if you like, but I wouldn’t call that a “wise move”.
As for those practising law understanding the GPL, yeah it’s possible. Possible for those that don’t practise law as well. The key is not to project your own wishes and desires onto it. Even the FSF is guilty of that occasionally.
We’re bordering on the ridiculous again…
Ton doesn’t need to “stand up to the FSF”. He chose the GPL, it wasn’t forced on him. You also need to consider the fact that of all the people complaining about the GPL applying to addons & game code… Ton isn’t one of them. In case it passed by some folks here at BA, Ton likes everything to be open. From what I can tell, the way things in regards to licensing are perfectly align with the man’s wishes.
File formats cannot become GPL incompatible. File formats cannot be patented and reverse engineered file formats & communication protocols have a long legal history of support. FBX will forever be a pain due to the need to reverse engineer the format - the GPL won’t be an issue.
If MS & Apple were to somehow prohibit GPL applications from running on their platform - they would shoot themselves in the kneecaps in such a way they’d never recover from it. I’m willing to bet you $200 right here and now that neither Microsoft nor Apple will ever prohibit GPL applications on their desktop OS.
Well I know Ton likes the idea of Blender remaining free and open software, but I read the impression from your posts that the GPL was written not to promote the idea of free and open software, but to promote a radical ideology, an ideology that according to some may actually be blocking Blender from being as free and open as it can be (because to a commercial developer, Blender might actually be seen as closed and restrictive).
Doubtful. Also, overreaction much? Just because the BGE isn’t going to let you live your commercial dreams doesn’t mean that every game engine the world over is suddenly not worthwhile.
I never said I had commercial dreams as a game developer, my art is where the money is for me.
Anyone that has contributed code under the GPL that Blender uses in the distributed work can do so. The Blender Foundation needs their permission to distribute their code and, as such, they can state that the final work not have “exceptions” applied.
If your position is that it is unlikely someone will do that, I’d agree. Thing is, it only requires one to cause legal grief, cost the Blender Foundation money it cannot spare to defend against, and no-one is going to want t be their companies commercial add-on success on the possibility that there are no strong-minded ideologues in the contribution base to Blender’s code.
Assets aren’t code. Therefore they are not a derivative of the code that is GPL’ed (though something with the monkey-head arguably might be ;)). A block of code (compiled or otherwise) that uses & integrates into the functionality off a copyrighted API clearly is a derivative of it. This is not just Campbell’s opinion - it is the long-held opinion of the FSF and they wrote the license.
In general, “concepts” aren’t considered copyrightable but you have the right idea. A game can still have graphics & sound assets copyrighted and, provided your game relies on these to be sellable, there is no “threat” to releasing the code which is GPL by nature of it’s interaction with the BGE API.
On the other hand, you must release it in such a way that the end-user can modify and compile that code back into a usable work. In other words, they can replace the graphics and sound assets, use the code as is, and release the game themselves based on that. If you can rely on unique level design, animations, good graphics, etc you’re not going to be too adversely affected… but if your drawcard is “gameplay” (which is generally something coming out of the code more than the look/feel), it will be open to sharing and duplication by others.
