Legal issues

Introduction

This article is dedicated to clearing up blurry license aspects. We'll contact the Software Freedom Law Center to help us to clear up license-related questions.

Header

Hello dear Software Freedom Law Center employers,

my name is Martin Vohland and I'm involved in project management for an open source project called FIFE (http://www.fifengine.de). We're working on a framework for the creation of cross platform 2d games. While the engine core is written in C++ since the project was founded over two years ago, we started to utilize SWIG (http://www.swig.org) several months ago to create Python bindings for our project. After we started to utilize SWIG we created several engine extensions in Python. The C++ engine core gets built as dynamic library; you can access the engine core functionality from Python with the help of wrappers code that gets generated by SWIG.

Current licensing

When the project was founded the initial team members who worked on the project agreed that the GPL 2.0 license (http://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or newer would be the best option for FIFE. Therefore all the engine C++ code written by the team is licensed under GPL 2.0 or newer.

We were unsure how we could license the code of the engine extensions that are written in Python. To avoid any issues we decided to go for the same license and picked the GPL 2.0 (or newer) for our Python code as well.

Important note: Over the two years of development about 20 different people did contribute code to the project. In the beginning the majority of the developers were advocates of the GPL 2.0 or newer. The majority of the currently involved developers considers the LGPL a better licensing option for the project. While the C++ code of the project was written by both GPL and LGPL advocates, the Python support was just added recently and the developers who contributed the Python code favour the LGPL.

Utilized tools / libraries

Scons

• License: MIT license
• Website: http://www.scons.org

SWIG

• License: BSD license
• Website: http://www.swig.org

SDL

• License: LGPL
• Website: http://www.libsdl.org

Boost

• License: Boost software license
• Website: http://www.boost.org

SDL_ttf

• License: LGPL
• Website: http://www.libsdl.org/projects/SDL_ttf

SDL_image

• License: LGPL
• Website: http://www.libsdl.org/projects/SDL_image

LibVorbis

• License: BSD license
• Website: http://www.xiph.org/vorbis

LibOgg

• License: BSD license
• Website: http://www.xiph.org/ogg

OpenAL

• License: LGPL
• Website: http://www.openal.org

Guichan

• License: Custom license
• Website: http://guichan.sourceforge.net/wiki/index.php

Python

• License: Python software foundation license
• Website: http://www.python.org

Zlib

• License: Zlib license
• Website: http://www.zlib.net

Minizip

• License: Zlib license
• Website: http://www.winimage.com/zLibDll/minizip.html

OpenGL

• License: unknown
• Website: http://www.opengl.org

Desired licensing

If we could freely choose a license for the project the currently involved developers would favour licensing the engine core (C++) as well as the engine extensions (Python) under the LGPL. We would like to increase the target audience for our project but the GPL is considered to be too restrictive e.g. for independent developers as they would need to release their complete source code and not only the changes they applied to the FIFE C++ / Python code directly.

Questions

1. Considering that the C++ engine core was written by developers who still tend to favour the GPL over the LGPL: would it be possible to keep the GPL for the engine core (C++) but release the engine extensions code (Python) under the LGPL? We are not sure if the engine extensions Python code is a derivative work as it's partially created by SWIG. SWIG parses the engine core C++ code and creates the Python code with the help of so called interface (*.i) files that tell SWIG what engine core functionality should get exposed to Python.
2. Does the Python engine extensions code need to get always licensed the same way as the C++ engine core code as the extensions need to be considered as a derivative work of the engine core?
3. Are there any license conflicts between our own current license policy and the 3rd party software (tools and libraries) we utilize for FIFE? Would such issues arise if we would switch to LGPL for the C++ engine core or the Python engine extensions or both?
4. In case we can't switch to the LGPL just for the Python engine extensions code: is there any usual procedure for a license change? We guess we would need to contact all programmers who contributed code (C++ & Python) and ask them for permission? Is there a common template for this task? If programmers only contributed minor changes and these minor changes have been replaced later: will we still need their permission? How could we prove that their code is not used in the project anymore?
5. If programmers who contributed to the project don't want to agree to the license change: could we identify their contributions to our code and replace it with new code by developers who are fine with the license change? Could we switch the license to LGPL after all code that was written by developers who insist on the current GPL licensing has been removed from the project?

Footer

Thank you for your time and offering this service for free to open source projects :-)

Greetings, Martin Vohland