Player: license changing

[take-cheeze]

Since all the code copyright holder agreed to move to non-GPL new license we need to prepare for it.
The issues for it will be

1. which license to move on
   -> strong candidate would be MIT license.
2. when to move on
   -> I'm thinking of moving to new license when the mruby branch is merged.
3. how do we treat binary distribution linking GPL library
   -> maybe we need to remove those libraries or stop distributing it.
4. license text change of source file
   -> we'll use some text replace program like sed

[fdelapena]

Because the libmad MP3 library is GPL, the mpg123 MP3 library and SMPEG
are LGPL (suitable for dynamic linked binary ports) and Fluendo MP3
Decoder is MIT (suitable for static ports). These require some small
work in the glue to make the stream play with SDL_mixer.
There are also free Fluendo MP3 patent-licensed special binaries for
countries with patent problems (these special binaries are GPL
incompatible by the way).

Another task is to switch to SDL2 (zlib) because SDL 1.2 is LGPL
(@Ghabry has a working branch already).

[Ghabry]

I agree on switching to MIT when mruby is finished. This gives us more time to resolve the problems mentioned by fdelapena.

I missed that SDL1 is LGPL, good to know. My SDL2 branch is basicly finished, will open a pull request soon.

And mp3 is a problem I don't have a solution for yet. Fluendo could be an option. Is that included with the linux distributions because of that non-free requirement? SMPEG is junk (and LGPL).

[fdelapena]

The non-free issue is with patent licensing special binaries provided (this allows to use prepaid mp3 royalties in countries with patent issues), but as far as I know you can still provide your own build from sources patent-unlicensed library like any other patent-unlicesed mp3 decoders(libmad, mpg123, etc.).

In fact, some distributions have fluendo MP3 decoder in their repositories. It's free but with patent issues like any other MP3 decoder.

[Ghabry]

okay then this should be fine for our needs. But other libs are still welcome in case you find any ;)

[fdelapena]

Readers has been renamed to liblcf and converted to MIT license.
However, iconv is still GPL (when used as separated as libiconv with non-libc toolchains) and will be replaced with ICU (MIT) soon.

Current Player blockers:
OpenAL-Soft is being disabled by default to prevent static linking on some ports (LGPL), SDL2_mixer will be the preferred (zlib license). Note there will need a resampler for pitch control. SDL_mixer's timidity source has a resample.h for this, or use a more powerful arbitrary resampler like libspeex/opus-tools.
SDL2 support has been landed and is the default (zlib), so remove SDL1.2 (breaks Wii port and possibly others) (LGPL).

[fdelapena]

This issue is quite outdated, the current situation is:

• Already switched to SDL2 from SDL1.2.
• Already switched to ICU from iconv.
• Already switched to mpg123 from libmad. There are no GPL deps anymore.
• App Store allows LGPL dynamic linking, as copyright holders of the package there is no problem with license issues. And yes, iOS has a way to use dynamic libraries and even since iOS 8 officially supports dylibs, so policies have been relaxed.
• 2k/3 English release, still "supported".
• According to the vendor, 2k/3 original source code is lost.

Because we don't have limitations with keeping Player as GPL and not a good reason to switch to MIT nowadays, and because the 2k/3 "code lost" issue might be interested on a non-copyleft version for a takeover (liblcf is MIT licensed already for their needs), what do you think about keeping Player GPL and closing this one as wontfix?

[Ghabry]

You make valid points but there is one thing that bugs me:
I would like to see some kind of "linking exception" in the license which allows us to interface with non-system libs. As an example I would name the steamworks library to provide steam features like achievements (other stores (GOG?) probably have similiar libs). There are probably other cases where it makes sense, but these are the first ones I thought of.
The library is non-free and not a system library, we are not allowed to link with it and call into the functions :(. But the lib doesn't interact with our code at all, so I'm not seeing a problem there, it behaves like a system lib.
tl;dr: An exception to allow linking and interacting (Player calls into Lib) with non-free libraries if they don't depend on Player. The GPL applies for the implementation of the interface obviously because it modifies Player code.

[fdelapena]

Yeah, I've totally forgot this point. Indeed an exception is really convenient for these cases.

By the way, any good related real world GPL exception from existing projects to adopt?
If possible, some variant which is already OSI/DFSG/FSF approved to help updating package maintainers without major bureaucratic issues.

Update: http://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs
Also worth to mention: maybe code depending on non-system, non-free APIs might be worth to not be included in the generated source tarball to prevent useless code bundling most distros. Users interested on these could get the code from the repo for their special needs. This also prevents distro maintainers needing to strip them.

[Ghabry]

Yeah imo this is not a problem for distribution because we will not link against these non-free APIs in the normal case. This would be just for special needs, like game developers wanting to use these APIs.

Is maybe a good idea to put the whole non-free API in seperate files to make distribution easier for the OSI conform tarballs as you suggested. And all non-GPL files should be manual opt-in via a configure argument.

The suggested exception on the GNU page is a bit specific, we should try to generalize it. Or we just get the permission by all devs that adding additional libraries on demand is allowed and then we just extend the license everytime ^^

Additional permission under GNU GPL version 3 section 7

If you modify this Program, or any covered work, by linking
or combining it with any library listed in GPL_EXCEPTION.txt
(or a modified version of these libraries), containing parts
covered by the terms of the respective license of these libraries
as listed in GPL_EXCEPTION.txt, the licensors of this Program
grant you additional permission to convey the resulting work.

List:
STEAMWORKS - STEAMWORKS SDK license

Other stuff I can't find the license yet but could be useful if somebody
submits patches to include them ;) (mentioning iOS explicitly because of Apple):
iOS Developer Library
Google Cloud Messaging for Android Library
Google Play Billing Library
Google Play Licensing Library
Google Play Games Services SDK

Other stuff is not possible to make compatible because it looks like there
are NDAs involve.
GOG Galaxy provides no SDK without contacting them
Nintendo wants you to sign an NDA

[carstene1ns]

My main concern is about loosing statically linked ports.
Usually most homebrew libraries are GPL, changing our license will violate their license.

While using dynamic linking the (open) license does not matter at all, when we not change the used library.

[Ghabry]

After a bit of research I think we have to scratch this approach for now. Valve also requires you to sign a NDA for the full steamworks API and you are not allowed to publish any code that is calling into there API. Ancurio wrote a story on Reddit about publishing To The Moon with Steam achivements...
But when the editor is ready (in 2 years? :D) we really need a solution for this because it limits the ways how game developers can sell there games :/

So to do the exception part it would get even more chaotic: Write a propreitary library that links against Steam, mention this library in the exception list, link against this library --> Keeps the Steam code secret m(

About your text: Yeah, then it should be dual licensed... one GPL and one GPL with that exception. The exception would only apply for that corner case, all linux distributions and homebrews could use the normal GPL version because they don't need the non-free part.

[carstene1ns]

About game devs selling games including player:
What matters is their content, they do not sell Player. IMO also all published games should need to have a README/LICENSE-EasyRPG-Player file describing what it is.

About steam api integration:
What about doing it the other way around? Add a linking exception to Player, that allows including in closed source (only unmodified, or with changes published of course).
Then let them write a puppeteer executable that links libeasyrpg-player. :grinning:

[Ghabry]

This sounds like an option. Allows exactly what I wanted anyway with that library exception: Changes to Player count as derivative work: Must be published under GPL and the other direction doesn't matter and is allowed propreitary.

But there is another issue: Propreitary (and NDA) for video game console SDKs. They need a way to handle Video/Audio/Input of the Player. Therefore I would like to see another exempt for classes that implement the BaseUi and the AudioInterface interface.

These exceptions should be enough to make the Player usable in 99% of all cases I can think of :)

[Ghabry]

Is the "you must ship a license file" part of the GPL?

okay so the resulting license would be something like this:

Additional permission under GNU GPL version 3 section 7

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 special exceptions, the copyright holders of this library give you the following permissions:
a)
You may 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.

b)
link this library with modules that explicitly derive from unmodified versions of the classes listed in 
GPL_EXCEPTIONS.TXT and to copy and distribute the derived classes under terms of your choice.

If you modify this library, you may extend this exception to your version of the library, but you are not 
obliged to do so. If you do not wish to do so, delete this exception statement from your version.

[Ghabry]

Here is a cool list of license exceptions: https://spdx.org/licenses/exceptions-index.html

Especially useful is the Qwt and U-Boot exception because it contains stuff I want :D

So I would change my b) to:

b)
Including headers and accessing data of the Player in a way that has no side effects
(read-only access) is not considered a derived work. No side effects means the Player
must behave the same when the data access is removed. You may copy and distribute
this code under terms of your choice.

c)
The classes BaseUi (base_ui.h) and AudioInterface (audio.h) define interfaces required
for system interoperability. Classes derived from unmodified versions of these classes
are not considered a derived work if they fulfill the requirements of b). You may copy
and distribute the derived classes under terms of your choice.

Things that are not stated as exception but are obviously not a derived work in my opinion: System initialisation code required before invoking Player::Init.

[fdelapena]

:+1:, however in case of particular API changes there (namespaces <-> classes) might need to update the license exception later.

[Ghabry]

Just to get this finished directly after 0.5 release.
As stated in the main post end of 2013 all devs agreed on relicensing to another license. Back at this time I contacted the devs that were not contributing anymore, I even found the e-mail...

In the meanwhile a few further devs joined, git blaming says:
@Zegeri (tons of interpreter fixes)
@scurest (interpreter fixes)
@ChristianBreitwieser (speexdsp and libretro port)
@Tondorian (minor battle system fixes)
@Rinnegatamante Wrote PSVita and 3DS port, doesnt need relicensing but would be nice for convenience.

You five: _Would you agree on adding a linking exception to our GPL license to allow interoperability with propreitary code (and NDA) like the Steamworks Library (Achievements & co.) to make the Player more useful for game developers?_

The developers that agreed to relicensing in general were:
MarianoGNU
glynnc
Rikku
take-cheeze
vgvgf
Zhek
fdelapena
Ghabry

I assume carstene1ns already agreed.

People that don't need asking:

Rohkea contributed fonts and his work was under public domain.
BlisterBoy codes for the Game browser only which is already MIT (at least I used this as the license for my game browser, not sure if the header is still there >.>) and is not a derived work of Player.

[scurest]

Would you agree...

Sure.

[Rinnegatamante]

Me too i agree, no problem.

[Zegeri]

I agree.

[ChristianBreitwieser]

I agree.

[carstene1ns]

Just leaving this here regarding steam: https://hg.icculus.org/icculus/steamshim/file/tip/README.txt

You have a GPL-licensed game and can't link directly against the Steamworks
SDK. The child process links against the simple, open source C code, which
talks to the open source C++ code via a pipe, which talks to Steamworks. You
can now add Steam achievements to your game without violating the GPL.

[Ghabry]

To simplify this (and carstene1ns already suggested something like this) a "core" and a "player" (find a better name) library could be created.
The "Core" gets a lax license and the "Player" lib gets a linking exception.

The requirement for "Core" is that the "Player" lib depends on it but the "Core" may not depend on "Player".

Therefore core should contain (havn't verified if it still compiles with only these files, will update when I find more deps):

Update loop logic, basic engine configuration:

• Extract from player.cpp to player_core.cpp

The whole audio backend:

• audio.cpp
• audio_*.cpp
• FmMidi: midisequencer.cpp, midisynth.cpp
• decoder_*

Input backend:

• input.cpp
• input_*.cpp
• keys.h

User interface:

• baseui.h
• *_ui

Scene handling:

• scene.cpp
• Maybe also add "scene_helloworld.cpp" as an example

Basic Graphics API:

• bitmap.cpp
• color.cpp
• drawable.h (the stuff in drawable.cpp should be moved somewhere else)
• font.cpp
• graphics.cpp
• hslrgb.cpp
• image_*.cpp
• sprite.cpp
• rect.cpp
• text.cpp
• tone.cpp
• message_overlay.cpp
• fps_overlay.cpp
• pixel_format.h

Fonts:

• bitmapfont_*.cpp
• shinonome_*.cpp

VFS layer:

• filesystem.cpp
• filesystem_overlay.cpp
• filesystem_os.cpp
• filesystem_physfs.cpp
• FileFinder not, is highly specific

Dependencies for this:

• async_handler.cpp
• output.cpp
• utils.cpp

This way fancy stuff like Steam integration or DRM-/NDA-API stuff can be added to engine core and all the stuff that wasted hundreds of dev hours is still under GPL in the Player.

Opinions?

[20kdc]

Regarding basic graphics API, I'm curious as to why sprite.cpp is "maybe Player, too specific" - fitting with the Plane, Rect and Tone classes makes a very RGSS-style API, from which sprite.cpp would be something of an omission. (And on a side note, anything that could lead to the main screen composite being sufficiently abstract to get replaced without reimplementing bitmap.cpp is probably a good thing.)
Abstracting away Core might have other non-licensing-related benefits, specifically for anyone who particularly wants to make a reimplementation of Core with HW-acceleration, low as the chance is.

[Ghabry]

Didn't check all files when I wrote the previous comment. Rechecked sprite.cpp. You are right, besides the "BushDepth" function all of Sprite is very universal so it should be included in "Core".

[Ghabry]

Imo FileFinder can be removed from the dependency list because it is highly specific for RPG Maker 2000 features but we need a way to configure the main filesystem that is to be used... I added the WIP FileSystem API instead.

Player.cpp is needed for handling an update loop and some basic ui configuration but this must be refactored out in PlayerCore.cpp
Parts of Cache.cpp could be useful.

Made a quick compile with core dependencies only. Many files have useless includes but here are the criticial issues:

Problematic files that would need changes for a good core abstraction:

• async_handler.cpp: Depends on FileFinder
• audio.cpp: Depends on Player
• audio_generic.cpp: Depends on FileFinder
• bitmap: Depends on FileFinder
• decoder_wildmidi.cpp: Depends on FileFinder
• filesystem.cpp: Depends on FileFinder
• font.cpp: Depends on Cache, FileFinder, Game_System, Player and ExFont --> Font configuration should be moved somewhere else
• fps_overlay.cpp: Depends on Player (for speed modifier)
• graphics.cpp: Minor dependency on "cache"
• input.cpp: Depends on Player.cpp
• message_overlay.cpp: Depends on Game_Message::WordWrap
• output.cpp: Depends on FileFinder, Main_Data and Player
• scene.cpp: Depends on Player::Update
• sdl2_ui.cpp: Depends on Player::touch_flag/mouse_flag/exit_flag/no_audio_flag, Player::Pause, Player::Resume
• text.cpp: Has exfont rendering, depends on Cache for the system graphic. Maybe should be replaced with a more generic renderer or use Font directly (will work when the font branch is in)

Proposed license text for EasyRPG Player to allow interop with core:

Linking EasyRPG Player statically or dynamically with other modules is making a combined
work based on EasyRPG Player. Thus, the terms and conditions of the GNU General 
Public License cover the whole combination.

As a special exception, the copyright holders of EasyRPG Player give you
permission to combine EasyRPG Player program with free software programs
or libraries that are released under the GNU LGPL and with independent modules
that communicate with EasyRPG Player solely through the EasyRPG Engine Library interface.
You may copy and distribute such a system following the terms of the GNU GPL for
EasyRPG Player and the licenses of the other code concerned, provided that you
include the source code of that other code when and as the GNU GPL requires
distribution of source code and provided that you do not modify the EasyRPG Engine Library
interface.

Note that people who make modified versions of EasyRPG Player are not obligated to grant
this special exception for their modified versions; it is their choice whether to do so. The
GNU General Public License gives permission to release a modified version without this
exception; this exception also makes it possible to release a modified version which carries
forward this exception. If you modify the EasyRPG Engine Library interface, this exception does
not apply to your modified version of EasyRPG Player, and you must remove this exception
when you distribute your modified version.

This exception is an additional permission under section 7 of the GNU General Public
License, version 3 (“GPLv3”)

[Albeleon]

In regards to both the recent license proposal and the GPL license exception that @Ghabry wrote two years ago, I'm cool with it,

[Ghabry]

There was some discussion about SteamShim. This is used by some games and said to not violate the GPL but this specific interprocess communication just to circumvent GPL is in my option a huge grey area (not sure if (64,64,64) or (192,192,192) though ;)) and wouldn't survive at a court.

For a short term solution, until all the other stuff is solved, just giving a general exception for SteamShim is maybe a good solution.

According to GPLv3 FAQ the exception is something like

If you modify this Program, or any covered work, by linking or combining it
with SteamShim (or a modified version of that library), containing parts covered
by the terms of MIT license, the licensors of this Program grant you additional
permission to convey the resulting work. Corresponding Source for a non-source
form of such a combination shall include the source code for the parts of SteamShim
library used as well as that of the covered work (excluding the Steamworks SDK).

[Tondorian]

You five: Would you agree on adding a linking exception to our GPL license to allow interoperability with propreitary code (and NDA) like the Steamworks Library (Achievements & co.) to make the Player more useful for game developers?

sorry I missed that discussion I agree with changing the license

[JeDaYoshi]

Anything regarding this nowadays? (current status, what will be done, etc.)

[vegagames]

What is the current status of the license change?

[Ghabry]

It seems that more and more users are asking for it so the priority is raising but we made no significant progress yet :/.

[JeDaYoshi]

Yeah, just as someone interested on this - I know it should not be the highest priority, but... also that it's been requested for almost 6 years as of now.

Now, what's stopping this from happening?

[Br4ssman]

We have a possible publisher interested to publish our next title.
This publisher only works with PS4, Vita, XBOX and Switch consoles, so changing the license will open EasyRPG to commercial projects and not only games for hobby.

Anyway, It's a bit dark for me how to publish on E-Shop or other consoles using EasyRPG.

[vegagames]

Having the license remain GPLv3 is a massive hindrance for people trying to make commercial games on consoles and other restrictive platforms. As much as I love the GPL, it's not fitting for this project. Please give us some kind of feedback as to what's going on. Even if the license change is no longer happening, it would be good to have some kind of closure or update on the issue.

[fmatthew5876]

I fully support changing the license to allow people to develop and sell commercial games. In the future, I want to be able to do this myself.

In order to help promote the engine and get more users, I suggest we try to resolve this sooner rather than later.

[Cloudef]

_Never mind, I'm not violating GPL as easyrpg and my shell are separate apps. If I do any modifications to easyrpg or distribute easyrpg with my application I have to host the source and give the end-user a ability to modify and replace the easyrpg in my distribution._

[fmatthew5876]

I would like to follow up on this as I've now contributed a significant portion of the code in various parts of Player over the last 2 years.

I would like to use Player for a commercial game, but unfortunately linking and inheriting won't really be enough. I'll want to do a lot of things like modify Game_Actor directly and add more stats, or change behaviors in random other parts of the code that aren't really extensible.

Getting all the player interfaces I want to change to be cleanly extensible using inheritance or factories will take years more and really doesn't make sense.

What's the current thinking on license and what do we need to do to get there?

This would be a good candidate for next major release.

[Ghabry]

Is it problematic for you that you must publish your changes to Game_Actor and other classes under GPL?

The idea we talked above was that we need a solution for incompatible SDKs that require NDA.
The proposed solution was a "core" library that provides the engine and the operating system abstraction. This one would be MIT license so you can keep it secret.

Then there is the "Player". This stays under GPL and talks to the "Core".
Player has a linking exception: You can link it against "Core" without publishing the "Core" code (=GPL does not apply) when the interface the Player uses for communication was not altered.