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.

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

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 ;)

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

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.

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