Retroarch: Non GPL compatible cores

[FlorianUekermann]

I'm wondering about RetroArch and distribution with cores that are not licensed under a GPL compatible license. Apologies if I missed existing documentation on the matter.

To get the obvious out of the way: Making and distributing a core that fulfills the libretro API is obviously a non issue, given the permissible license of libretro.h. Building the core as a shared library and running it privately is also obviously fine.

I am not sure distribution of (unmodified) RetroArch and a non-GPL compatible core as a bundle is ok though (say a zip file that contains both). Additionally, if it is permitted, what do the contributors think about that?

[hizzlekizzle]

None of the main contributors are lawyers, so we can't really advise anyone on license compliance.

That said, distributing RetroArch alongside non-GPL cores touches on some issues that are not clearly legally defined (AFAIK) with regards to the GPL, including dynamic linking (and static linking, for that matter), "non-free" plugins and "mere aggregation".

I can't speak for anyone else, but as long as RetroArch's license obligations are met (source provided by request, etc.), I'm not personally offended by it being in the same directory as a "non-free" library.

[FlorianUekermann]

distributing RetroArch alongside non-GPL cores touches on some issues that are not clearly legally defined (AFAIK) with regards to the GPL

That was my impression as well. I stumbled over the old CLISP-readline exchange between Stallman and the CLISP developer (Bruno Haible), which may indicate to some that this is not ok (RMS said some lawyer said...). But besides being not particularly convincing the roles are flipped here (GPL program loading whatever the user tells it to load). I kind of wish the NeXT thing RMS mentions had been settled in court.

I'm not personally offended by it being in the same directory as a "non-free" library

Thanks. There are alternatives of course, but RetroArch is definitely in better shape than most.

I'll leave this open for a bit, in case anyone else wants to share their take on one of the two questions (I would appreciate it). I guess we can just close this in a couple of days.

[RobLoach]

It depends on the license, and the means in which you're distributing them. A number of the cores are non-commercial, and you can see that list here:
https://docs.libretro.com/tech/licenses/

You cannot sell a box with these cores on it, as it would violate the non-commercial license.

Honouring the licenses and wishes of the authors of the cores is absolutely important to the strength of the libretro project and community. We do our best to be outline it's usage and guidelines, but as hizzlekizzle pointed out, non of us are lawyers, nor do we have the financial stability to hire a consultant.

Are you looking to distribute one of the cores? Where does your curiosity stem from?

[FlorianUekermann]

Where does your curiosity stem from?

I am writing a core and I would like to stick with the libretro API. To offer a reasonably easy setup experience to people unfamiliar with the libretro ecosystem, I have to distribute the core with a frontend (RetroArch).

I was wondering whether there are known legal problems or contributor reservations towards distributing my own GPL-incompatible core with RetroArch as a frontend.

You cannot sell a box with these cores on it

I am not interested in distributing any cores that are not my own.

[ghost]

You could write your own libretro loader like I did. That way you could absolve yourself of any possible license drama.

[FlorianUekermann]

You could write your own libretro loader like I did. That way you could absolve yourself of any possible license drama.

True, but that would defeat the purpose of choosing libretro somewhat. I have written that kind of code in the past and found it to be a huge time sink to support the different platforms and input methods.

[orbea]

I'm not a lawyer either, but I think basically if you distribute RetroArch binaries you must also offer complete sourcecode that created those binaries. This is why cores are not built into RetroArch and this is where you can set your own license of choice if you only include libretro-common which has a more lax license.

I would suggest offering different downloads (Does this extend to the download server?) or just point to upstream for the frontend. Also note that while RetroArch is the main frontend, its not the only one and users may wish to use a different frontend as well.

[ghost]

Its an interesting situation.

I thought with non GPL cores, it is the end user themselves that would violate the GPL if such a mix occurs, not the host application. Though the problem is some people interpret the GPL differently. Such as even if GPLed plugins are used for non GPL loaders (people think its a license violation even if the end users themselves do everything)

[fr500]

As a matter of fact, using your proprietary core with RA would constitute a license violation.
Bundling RA with your core is... as hunterk said files in a folder, and the dynamic linking case is still iffy.

@mudlord right because when using dlopen it's just.. files in a folder, the linkage doesn't even exist until the library is opened.

@RobLoach of course, and those cores being linked to RA does constitute a RA and a core license violation!, even more so on statically linked platforms. (which RA choses to ignore for ease of distribution's sake)

[hizzlekizzle]

As a matter of fact, using your proprietary core with RA would constitute a license violation.

This is not necessarily correct. The GPL doesn't have any effects at all unless and until you distribute binaries. It's not a license violation for someone to use GPL programs in any way at all, including making changes and refusing to share them (something that companies do every day), linking them with closed-source libraries, etc. _as long as they never distribute binaries of the modified/combined result_ (and even in the case of distribution of binaries, whether linking, either statically or dynamically, constitutes a combination is not clearly legally defined). So, no, simply _using_ a proprietary core with RA does not constitute a license violation.

and a core license violation!

Also not necessarily correct. You can still hypothetically fulfill all of the obligations of a noncommercial license while also following the stipulations of the GPL (i.e., unless the noncomm license specifically disallows sharing source changes or whatever), but you can't fulfill all of the obligations of the GPL while also denying the "right" to sell the software. Thus, combining GPL with noncomm is definitely a problem for GPL but not necessarily for noncomm. And, again, the discussion is moot unless and until combined binaries are distributed, which we do (maybe!) with the statically linked targets but it doesn't sound like OP is planning to do.

IANAL.

[twinaphex]

I believe you should consult a lawyer if licensing matters are important to you and figure things out with him/her (although I think the situation here really doesn't warrant that, but if it buys you safety of mind, fair enough, although I think the concerns are widely overblown to the point of being non-existent/moot).

I believe we can close this issue having said that.

[RobLoach]

Thanks twinaphex...

@FlorianUekermann As a side-note, there are a couple other libretro frontends out there that have more permissive licenses. I'd like to see that list grow. Having options is good.

[Ferk]

even in the case of distribution of binaries, whether linking, either statically or dynamically, constitutes a combination is not clearly legally defined

I'm not a lawyer either, but my impression was that the reason why the LGPL exists is precisely because the GPL does not allow its distribution linked with non-GPL libraries, whereas the LGPL explicitly does. So if something is meant to allow its distribution with non-GPL libraries I would expect it should be licensed as LGPL instead of GPL.

What is the difference between LGPL and GPL otherwise?

[hizzlekizzle]

That is indeed why the LGPL exists, but the mere fact of its existence does not make their (i.e., FSF/RMS) very broad interpretation any more legally legitimate. Ditto for the "linking exemption" that some projects have adopted.

Projects who choose the LGPL avoid the legal gray area altogether, and there's definitely a valid argument that RetroArch should have gone that way to begin with, but that opportunity has long since passed.