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

---

• 20kdc
• Albeleon
• BlisterB
• carstene1ns
• ChristianBreitweiser
• Desdaemon
• drxgb
• ell1e
• eneway (Narcodis)
• fdelapena
• florianessl
• fmatthew (mateofio)
• Ghabry
• glynnc
• jetrotal
• johannschopplich
• JorgeMaker8000
• kakurasan
• MackValentine
• MakoInfused
• MarianoGNU
• PrimeKick
• Rikku
• Rinnegatamante
• rohkea
• Rueta
• scurest
• sorlok
• take-cheeze
• Toolman2k
• Tondorian
• tyrone-sudeium
• vgvgf
• Zegeri
• Zhek

---

If you cannot find your name in the list above:

• This happens when your change was trivial, this applies to stuff like fixing of typos (or other single character changes), only deleting code and reordering of existing code (without inventing new code).
• You are also not asked when the contribution was WQY font related (this part stays GPL due to the font license).
• You are also not asked when your change affects only homebrew platforms and other exotic platforms (often dependencies used here are under GPL so this would change nothing)
• You contributed only to the Android User Interface: This is already under MIT
• You contributed only (Android) translations: They are already under CC0

When you think that you made a significant contribution and cannot find your name in the list above: We are sorry. Please contact us.

[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. 😀

[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]

👍, 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
ell1e
sorlok
Rueta

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,

[florianessl]

Having stumbled upon this decade old issue after recently starting to contribute myself to this project, I'd like to clarify following:
I consider all my EasyRPG & liblcf related commits (both here and in any of my forks) up until now to be CC0 and considering my future contributions, relicensing under any of the spiffy licenses suggested here is also fine with me. 👍

[ghost]

Please do not use the MIT license, as this will benefit proprietary software developers, but they will not be of much help to us.

From here, we can gain a better understanding of proprietary software:
https://www.gnu.org/proprietary/proprietary.html (Proprietary Software Is Often Malware)

[Mimigris]

The change of license that is being discussed is, for instance, to allow games using the engine to be sold on platforms where changes need to be made to the engine while having those changes not be public (e.g. game consoles), and in this case a license like MIT where the possibility to make changes private is required, which is one of the points of the discussion related to the licensing change. Do you have something else than MIT that meets those criterias that you would like to suggest?

[ghost]

The change of license that is being discussed is, for instance, to allow games using the engine to be sold on platforms where changes need to be made to the engine while having those changes not be public (e.g. game consoles), and in this case a license like MIT where the possibility to make changes private is required, which is one of the points of the discussion related to the licensing change. Do you have something else than MIT that meets those criterias that you would like to suggest?

In this case, they should choose another engine instead of EasyRPG Player.

[florianessl]

I myself don't have any issue with publishing any changes I'm making to the source code of EasyRPG and was planning to do so anyway. Even in case my own game project would be released commercially some day, I'd of course make all new additions available publicly, GPL or otherwise. I want others to profit from the planned new features/tools and make their own awesome games with them...
But regarding third-party libraries for consoles/Steam that require some "copyright" license, this might be problematic. If EasyRPG stayed on GPL for whatever reason, it would hopefully still be possible to negotiate some other license agreement with the devs?

[Rinnegatamante]

I think the problem with staying with GPL in light of possible license negotiation case-by-case is given by the fact every cotnributor should be part of said agreement decision and, given how lengthy and complex even just switching from GPL to MIT is being, I think it would be unrealistically handleable.

[ghost]

The decline from GPL to MIT. You have forgotten why GPLv3 was originally used, it seems like you couldn't resist the temptation.

[rohkea]

If EasyRPG stayed on GPL for whatever reason, it would hopefully still be possible to negotiate some other license agreement with the devs?

That is unlikely. EasyRPG doesn't have anything like contributor license agreement (and it's a good thing), so you would need to negotiate with every developer separately. It's basically not viable.

You have forgotten why GPLv3 was originally used

You can “forget” something only if you know it. Do you know why it was originally used?

I'm not even sure who started the project (I think it was fdelapena? but I'm not sure), and I certainly don't know that person‘s original motivations. Do you?

[ghost]

I am just strongly advising against the change. I apologize if it makes you feel uncomfortable.

After EasyRPG Player changes its license, I should be able to relicense the latest changes/updates under the GPL license in my fork.

[Ghabry]

Sure, you can freely decide to stay on a different license. As your code changes are, when we add the callbacks, isolated in other files it will be easy to declare "The multiplayer folder/feature is GPL only".

[Rinnegatamante]

Sure, you can freely decide to stay on a different license. As your code changes are, when we add the callbacks, isolated in other files it will be easy to declare "The multiplayer folder/feature is GPL only".

That's not possible. By the moment you include GPL code in your executable, the whole executable becomes GPL (since GPL is more restrictive). Either the submitted code must be relincensed to MIT or, if even technically possible, it could be dynamically loaded and published under LGPL rather than GPL.

Some reference: https://softwareengineering.stackexchange.com/questions/204410/how-are-gpl-compatible-licenses-like-mit-usable-in-gpl-programs-without-being-su

[rohkea]

That's not possible. By the moment you include GPL code in your executable, the whole executable becomes GPL (since GPL is more restrictive).

I believe the plan was to have a flag like --nonfree (or --commercial, --undisclosed-code) when compiling, see #2500

So, some files will exist in 2 variants, perhaps separated into different folders:

• MIT variant will only contain a stub: an empty function that does nothing, or something like that,
• GPL variant will contain some additional features.

Then the user will choose what variant they want:

• if they compile with --nonfree flag, they have MIT version (only code under MIT, end result is MIT, but less features),
• if they compile with the default flags, they have GPL version (includes both MIT and GPL code, end result is GPL, has more features).

[ghost]

That's not possible. By the moment you include GPL code in your executable, the whole executable becomes GPL (since GPL is more restrictive). Either the submitted code must be relincensed to MIT or, if even technically possible, it could be dynamically loaded and published under LGPL rather than GPL.

Some reference: https://softwareengineering.stackexchange.com/questions/204410/how-are-gpl-compatible-licenses-like-mit-usable-in-gpl-programs-without-being-su

I might not have been clear. What I meant was from MIT to GPL.

GPL + MIT: https://softwareengineering.stackexchange.com/questions/105912/can-you-change-code-distributed-under-the-mit-license-and-re-distribute-it-unde

https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html (2.2 Adding GPL’d modifications to permissive-licensed files)

---

Mimigris: The change of license that is being discussed is, for instance, to allow games using the engine to be sold on platforms where changes need to be made to the engine while having those changes not be public (e.g. game consoles), and in this case a license like MIT where the possibility to make changes private is required, which is one of the points of the discussion related to the licensing change. Do you have something else than MIT that meets those criterias that you would like to suggest?

Perhaps LGPL can solve this issue.

[Ghabry]

Hey. I'm pinging here all new contributors who haven't stated whether they agree to any license changing to a non-copyleft-license (such as MIT).

Please state in a comment whether you agree to relicense from GPLv3 to MIT license (or similar).

@Desdaemon
@drxgb
@enewey
@JorgeMaker8000 (the initial string impl is by you)
@MackValentine
@MakoInfused
@Primekick
@ToolMan2k
@tyrone-sudeium
@20kdc (exe reader)
@kakurasan
@johannschopplich (changes to emscripten shell)
@BlisterB

For difference of GPL vs. MIT see the loooong discussion here. The main difference is that code under MIT can have proprietary changes (so you are not required to publish them contrary to GPL). So the main difference is when distributing the Player e.g. as part of a game and you have made custom changes to the game e.g. a new battle system.

Actively hurting is GPL when publishing of games on platforms that are incompatible with GPL (such as console platforms) or linking against SteamWorks e.g. for Achievement support. So you cannot currently do this with our license.

There is actually a game planned to be ported to Nintendo Switch and they want to use EasyRPG Player. So would be good to have that roadblock out of the way ;).

What happens if I do not agree?: When it is an essential component the code will be removed. When it is something that is optional the code will be hidden behind a compiler flag (so they can opt-in whether the Player is subject under MIT or GPL).

---

btw from now on I will delete any heated discussion about why MIT will hurt the project.

[Desdaemon]

@Ghabry Agreed

[ToolMan2k]

Sure, why not.

[enewey]

Agreed!

[tyrone-sudeium]

I agree to relicensing any of my contributions from GPLv3 to a permissive license (MIT or similar).

[JorgeMaker8000]

Yes, I agree.

[MakoInfused]

@Ghabry I agree to the terms.

[johannschopplich]

@Ghabry I'm all in for the switch to MIT license!

[drxgb]

No problem, I agree. Let's goooo !! 🚀

[kakurasan]

I agree to relicense.

[Primekick]

Not a problem for me, I agree to the relicense.

[MackValentine]

Okay for me

[BlisterB]

Ok for me

[20kdc]

I agree that any and all of my EasyRPG contributions and work I have written for any fork of an EasyRPG project may be used under the MIT license.

[Ghabry]

Okay thanks everyone for agreeing. All the work required for it will be postboned for after 0.8.1

Don't want to delay the release even further 😉