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 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,

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

[Ghabry]

I'm getting older and this issue too. My preference by now is to just move to a liberal license such as MIT and call it done.

Imo this linking exception stuff just doesn't work. Besides this NDA stuff which can be somehow worked around there are many use cases which just doesn't work.

Lets say somebody wants to add some completely new feature to the Player (matthew always uses a battle system as an example, but there are more), then this is required per GPL to be also licensed under GPL. Even when this new scene is a complete novel invention and it only calls into Player data structures to e.g. get the Actor HP it is already a derived work. You could also start here to add stuff like "GPL exempt functions" like the Linux Kernel does but imo this does not really scale for such a small project (and is silly).

There is also a gray area here: Because event code is excluded from all of this one could just invent new event commands and do clever event scripting to bypass most GPL-problems. Here you have to raise the question then if this is a GPL-violation.

The GPL-conforming forks on github for games sold on Steam etc. are so low-quality commit wise. I cannot remember that we were ever able to backport anything from them.

There is also no real business model (anymore?) related to somebody taking our code and selling it: RPG Maker is a niche and they moved to Javascript. RPG Maker 2003 is abandoned.

Also the GPL does not protect against any type of "abuse" that happens since years: Taking open source code, filling it with Ads and putting it in the Android Store. Just look at "JoyPlay": They just took an Android-fork of mkxp, added some ruby-compat functions for Win32 and the app is full of ads and has a Patreon. This is totally against the purpose of these licenses imo but perfectly legal.

Asking for the current opinion @fdelapena and @carstene1ns on this.

---

Btw for the editor I will not accept a license change ever. There GPLv3 is no big deal imo. I see no legitimate use case for closed-source editor releases and if you do not distribute your custom editor then there is no requirement to share the source anyway. (maybe one should even move to AGPL because many hostile cloud businesses bypass the GPL now via "X as a service")

[fmatthew5876]

I'm 100% in support for this. There is really no viable way to cleanly separate game specific customizations.

[fdelapena]

Nothing to add, I fully agree and liblcf is MIT already, so looks good to me :+1:, also would allow to move some Player code (e.g. map code) to liblcf without issues.

---

Editor is a different thing, and in case of a potential plug-in mechanism with some visual interface and providing features for both Player and Editor, I don't see issues with a proper design.

---

Not just RPG Maker 2003 ended support since a while. Kadokawa (or now Gotcha Gotcha Games who owns the Tkool stuff in Japan) announced the last month they are ending support for RPG Maker 2000 and all RGSS-based series, including VALUE! editions on 2021-03-31. They won't reply for support requests, though they will continue to provide RTP downloads and selling them (shrug, I guess via third party vendors), but no further changes on them.

So it's expected third party vendors on other countries and languages (e.g. rpgmakerweb by Degica) to continue selling legacy products as is, but if something breaks, they won't do anything to fix it. There are also vendors with support limitations for long time customers for old purchases to provide support due to law limitations. How they could even verify a customer has rights to distribute RTP assets? ;).

[Ghabry]

Two days ago I wrote about just using MIT because I'm sick of all this exception nonsense which is impossible to solve for non-lawyers.

Yesterday I read about the "Mozilla Public License 2.0". This one is also interesting and also solves the problems imo:

It is a copy-left license but it is a file-based copy-left. This means when you modify a file under MPL2.0 your code must be licensed under MPL2.0.

When you add new files they are not subject to the MPL2.0, so you can add new scenes, new drawables, new uis (for propreitary SDK stuff) under any license you want.

And some code where MPL makes no sense can be still relaxed to MIT (thinking of the startup code e.g.)

[fmatthew5876]

One use case I can think of is I want to change the set of stats from just ATK, DEF, SPI, AGI to add more. This and many other changes to Game_Actor.

Doing changes like that requires modifying code all over the place. While I could add a new child class to Game_Battler, the reality is that Game_Actor is used everywhere.

Also, is it worth the complexity of having difference licenses for different files? What are we trying to protect against here?

[Ghabry]

Well this was just a discussion point. You could create a Game_ActorMatthew that inherits from Game_Actor and put your stuff in there.

Anyway. The only threat model for me (The MPL2 would not really help alot more here) is that some people maybe have the smart idea to create proprietary patches RPG_RT style that are only for the windows version. Then advertise this nonsense on RMN and people start creating games using this crap. Though everytime this happens we can just tell them that this sucks and then hopefully nobody uses them.

tl;dr I'm still fine with MIT

[Ghabry]

Sorry for pinging you again. It has been a few years and my last question was about adding a linking exception. After thinking about this for years we do not think that this will work for a game engine where custom modifications are needed. Especially when the author wants to keep them propreitary for whatever reason (custom changes are not really useful for the upstream project). I just hope that some companies distributing a game bundled with the Player will still contribute back bug fixes or enhancements.

So the new question is (just answer with "I (dis)agree"): Do you agree with relicensing of the code to a non-copyleft-license such as the MIT license?

Pending: @Zegeri @Tondorian

OK: @ChristianBreitwieser @scurest @tyrone-sudeium @rohkea @rueter37 @sorlok

[scurest]

I agree. (Sup.)

[ghost]

I agree.

[tyrone-sudeium]

I agree.

My preference would be the MIT license across the entire Player; MPL sounds nice but it also sounds like it adds a bunch of legal complexity and I'm not sure anybody here's really passionate about legal complexity.

Edit: to be clear, this is just a preference. Any contributions I made to this project I'm more than happy for the project leads to do whatever they want with, whenever they want, including relicensing it.

[rohkea]

I agree. (Also, my agreement is not needed, since all my contributions are already CC0.)