Choosing an Open Source License for Game Development
I was looking back on an old post I made on the javalobby.org forums and realized that it was a decently coherent dialog I had (with myself), so in the vein of being vain I decided I should publish it on my blog.
It basically debates the merits of 2 open source licenses the BSD (Pretty much pure freedom but no guarantee of contributions from users) and the GPL v2 with classpath exception (Very strict forcing core contributions to be forced open sourced, but allows users to “link” to the libraries without open sourcing) and how they could be applied to the development of open source game related technologies within the context of proprietary game development. You can read the old post here:
Choosing an open source license for a Java Game tools
I’m researching what open source license I should choose to use when developing common game development open source software, that I want people to be able to use within proprietary software. The catch is I want there to be some kind of incentive for the users to help contribute back to the core open source technology.
I’ve been playing around the with the Java Monkey Engine at http://www.jmonkeyengine.com .
In my research I’ve been reading up a little bit about Sun’s move to open source Java under GPLV2 with some of it being licensed under GPLV2+classpath exception.
The classpath exception allows developers to link to the compiled GPL’d software without GPL’ing their own software (a good thing if you’re developing a proprietary game):
http://www.gnu.org/software/classpath/license.html
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
The GPLv2 + classpath exception, is almost identical to the LGPL, in that LGPL allows you to link to the compiled library without being blanketed by the GPL (IE: having to contribute your proprietary code). Although the wording in the LGPL is a little vague and has some exceptions that aren’t that clear in a Java environment(see section 5 of the LGPL “TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION”). The classpath exception makes the intended use very clear.
I’m trying to decide what type of license to use when releasing source code that I want to be able to use in a proprietary closed source game.
The real conflict is that, I could open source my game libraries using a BSD license which gives you the most freedom to modify and redistribute the code anyway you like. The problem with that is you have to rely on the developer community of that library to want to contribute back to the source code, otherwise they could just grab it make awesome modifications and keep it for themselves (which is sometimes what you want to do anyways!).
I think with a project like jMonkeyEngine BSD will work because, the engine is the core functionality for game development and benefits all game developers, it’s not like it’s the specific code that implements a first person shooter, or a massive multiplayer RPG. This combined with a strong community, promotes people to contribute back to the jME open source code base.
The problem with using a BSD license for something like say a game scripting framework is that I would want people to be able to use it as they will (open source, proprietary), but I want some way that kind of “forces” users to contribute back any changes they make to the core scripting engine (but still allow them to utilize the library in their proprietary projects). In this sense I think the GPLV2 license with the classpath exception makes the most sense.
I think maybe even jMonkeyEngine could be released under this license, because it still allows proprietary developers to make extensions and add proprietary features to jME (they can still extend, and implement any class/interface in the compiled jME), but it forces them to contribute back any modifications/improvements/bug fixes they make to the core engine.
It’s all a trade off…BSD gives you all the freedom you could want proprietary and open source but provides no mechanism to ensure that the community receives all the available improvements/modifications that are made with that core technology. While the GPL license allows the freedom to develop proprietary software based on the compiled engine, but if they modify/improve the core (not simply link to it), then they are forced to contribute that back.
Another cool thing to do with proprietary games, is to release them under GPL after they’ve reached their commercial “end of life” like John Carmack has done with the Quake engines.
Another conflicting thing that came up with Sun’s open sourcing, is the fact that they still somehow maintain the right to make commercial releases from the GPL code, even though it is GPL’d because you sign the SCA you and Sun have dual-ownership of your contributions?? I guess this is something to do with the fact that they are the “original” copyright holders so they can change the license at will?
I might be getting this all wrong, but I think companies like mySQL have similiar dual-licensing schemes, where you have to use the commercial license for proprietary software, or you have to use the open source GPL license which means you must contribute your changes back to them??
Which implies that they can then take your, forced to contribute changes and sell them for a profit?? This seems like a major unethical loop-hole in the dual-licensing GPL system? Can anyone clear up how that makes any sense?
I guess the only thing I can think of is that the creator of the project is a copyright holder and can license the source code any way they want, and then someone who uses the system is a contributor and only has the rights of the license they received the source code with? What does that mean for the contributor who wants to contribute their modifications back, but doesn’t want their changes to be exploited by MySQL’s commercial license?? Is this where open source project forks come into play? I’d assume they have to have complete control over what code is GPL’d and what code is their proprietary commercial code? Seems like that creates the exact thing GPL wants to protect against.
Here’s some good open source/free software licensing sites:
Free Software Foundation - Licenses
Why you should not use LGPL
There is a post on the Java Monkey Engine forums about this topic, I just wanted to get a wider Java community opinion also.