Licensing

[meleu]

From @leiradel on February 25, 2018 14:24

Although one might infer that the RASuite code is licensed under the GPL, since it's both compiled into and dynamically linked to other GPL'ed projects, it's best to be clear about it.

As the RALibretro developer, I'd like to make sure under what terms I can use RA code.

Copied from original issue: RetroAchievements/RASuite#45

[meleu]

@RetroAchievements @ScottFromDerby Just to remember RALibretro is a front-end to develop (and earn) achievements using the libretro cores for emulation. Development is happening here: https://github.com/leiradel/RASuite

According to "How to use GNU licenses for your own software" document, this is what would be needed to make all code on this repo GPL compliant:

• Give each file the proper copyright notices.
• Add a COPYING file with a copy of the GNU GPL.
• Put a license notice in each file.

If you think we can add a license notice in each source file of this repo I can take care of it and submit a PR. Just tell me what notice you want to put.

[meleu]

From @ScottFromDerby on February 25, 2018 22:53

I think all emulators we've used are GPL, which I think means we don't have a choice in the matter, however is GPL still the best choice? https://opensource.com/article/17/2/decline-gpl I'm not up to date with licensing, I've not had chance to educate myself fully about it

[meleu]

From @ScottFromDerby on February 25, 2018 22:56

From my perspective, my official stance is "do what you like". Ctrl+A Ctrl+P and live under the printouts if you like

[meleu]

From @leiradel on February 25, 2018 22:59

Thanks for the answer @ScottFromDerby but like you said, I too believe there's no choice. Also, people are afraid of using code which doens't have a clear license, because having no explicit license doesn't mean it's not copyrighted and that the owner won't want to exercise their rights on the code.

I believe releasing the code under a license is for the best interest of RA, but it has to be one that is compatible with the license of the other emulators.

It could be LGPL for the code that is used to build the DLL, and public domain, or MIT or zlib, for the code that is compiled into the emulators.

[meleu]

From @leiradel on February 26, 2018 9:34

I take that back. Of course there are options, any GPL-compatible license can be used. If you want to release the source code under a "do what you like" license, I suggest releasing it under the 3-clause BSD, MIT, or zlib/libpng, but don't take my word, look around and decide what's best for you and RASuite.

Other OSI-approved licenses can be found here. A list of GPL-compatible licenses can be found here. Again, it's better to have a clear statement on how the code can be used otherwise people will be afraid of using it in their code.

[meleu]

@leiradel Can we close this issue?

[meleu]

From @leiradel on April 15, 2018 14:24

Better ask the integration developers. RALibretro is GPL, but it's still unclear what the integration license is.

[meleu]

From @leiradel on April 15, 2018 16:50

Let me put it in a different way: right now we're violating the license of the libretro cores that are GPL, because I compile code into RALibretro which doesn't have an explicit license stating that it can be used in GPL'ed code.

[rzumer]

See my comments in #241.

If you want to use GPL, it is important to make sure that none of the software using RAIntegration right now is actually using its components directly when compiling or linking statically. Including a header for dynamic linking should be fine. A custom license might be more appropriate to discourage misuse of the interface.

And as mentioned by @leiradel, it is not legally safe to use code that is not licensed explicitly, so I would like to resolve this as soon as possible. See this and this page for reference.

[Jamiras]

From #241:

I think that GPL makes sense. RAIntegration is fairly closely tied to RA, so a more permissive license would probably not do much good. A custom license could also be better if we want to restrict the ability of a third party to distribute derivatives that may be less secure.

MIT makes sense for rcheevos on the other hand, because it is not as dependent on a specific back-end, so I hope it remains licensed permissively.

The main difference between GPL and MIT (as I understand it) is that GPL requires the software consuming the library also be open-sourced. Since both basically say "use this however you want", I don't have a strong preference one way or the other, but from an ownership perspective, rcheevos is the main engine of the product, and the only thing I'd really consider "intellectual property", so we should consider its licensing first.

It's entirely possible to create a standalone application that uses rcheevos and static files without ever communicating with the server. That's the only thing I'm really worried about as far as people using the code in an unapproved manner.

The DLL is just a set of tools that allow for creating the data and simplifying the integration of the runtime into existing emulators, RetroArch already illustrates how unnecessary it is if you don't want to create achievements. I could care less if people use the DLL code maliciously, but if we make rcheevos GPL, it will have to be GPL too.

As far as I'm aware, nothing outside of RAEmus and RALibRetro is currently using RAIntegration in any manner. RAQuasi88 uses the BSD 3-Clause license, and RAMeka has a custom license that is similar to the Apache license (though it claims similarity to the BSD license). The other emulators all use GPL. All of these license schemes would uptake either GPL or MIT without any issues.

The emulators pull in two files from RAIntegration - RA_Interface.hh and RA_Interface.cpp. These are the bootstrap stubs for loading the DLL and calling the DLL methods. They are not part of the RAIntegration build, so I don't believe the license directly affects them. They could probably be considered their own product with their own license.

Our only dependencies currently are rapidjson and rcheevos, both of which uses the MIT license. rcheevos is loosely dependent on lua (it's not actually in use yet, but does get compiled in). lua also uses the MIT license.

In my opinion, I'd prefer rcheevos be GPL (which would implicitly make RAIntegration GPL) so third-party emulator-in-a-box products have to at least consider the ramifications of using it as a standalone product, although I'm pretty sure there's already precedent for them doing that with RetroArch (which is also GPL), so it doesn't seem like a huge barrier. On the other hand, it might even serve as free advertisement - after the player finds achievements for popular games, they might search out achievements for other games and find us.

Scott has indicated that he's open to a fully permissive license:

From my perspective, my official stance is "do what you like". Ctrl+A Ctrl+P and live under the printouts if you like

Bottom line, we just need to come to a consensus: 1) MIT - anyone can do anything with the software as long as they don't hold us responsible 2) GPL - anyone can do anything with the software as long as they don't hold us responsible and also make their source code available.

[rzumer]

The main difference between GPL and MIT (as I understand it) is that GPL requires the software consuming the library also be open-sourced. Since both basically say "use this however you want", I don't have a strong preference one way or the other, but from an ownership perspective, rcheevos is the main engine of the product, and the only thing I'd really consider "intellectual property", so we should consider its licensing first.

That is a misinterpretation of GPL. There are licenses that are closer to your interpretation, but the reason GPL is controversial is because it is viral, i.e. programs that use GPL code must be licensed under the GPL.

Again, I do not believe this applies to dynamically linked programs like RAIntegration, but I believe there are some emulators that include RAIntegration code directly, or at least includes the project in VS solution, so it is important to make sure that they do not fall under the criteria that trigger this same-license requirement if they are not already GPL-licensed. LGPL is similar but more lenient in general. I will have to review the terms of each one to confirm whether GPL would work with the current emulators or not.

It's entirely possible to create a standalone application that uses rcheevos and static files without ever communicating with the server. That's the only thing I'm really worried about as far as people using the code in an unapproved manner.

Why? If derivatives do not interact with RetroAchievements, there is no reason to deny others the opportunity to reuse the code, in my opinion; that is, unless we want to make competitive platforms difficult to set up, and I don't think that would be a very productive endeavour personally.

The DLL is just a set of tools that allow for creating the data and simplifying the integration of the runtime into existing emulators, RetroArch already illustrates how unnecessary it is if you don't want to create achievements. I could care less if people use the DLL code maliciously, but if we make rcheevos GPL, it will have to be GPL too.

Isn't cheating a concern? Licensing could provide legal ground against it (whether anyone is willing to enter legal fights against cheater is a different matter, however).

As far as I'm aware, nothing outside of RAEmus and RALibRetro is currently using RAIntegration in any manner. RAQuasi88 uses the BSD 3-Clause license, and RAMeka has a custom license that is similar to the Apache license (though it claims similarity to the BSD license). The other emulators all use GPL. All of these license schemes would uptake either GPL or MIT without any issues.

True (assuming that Meka does not directly use RAIntegration code), but there is no guarantee that no application will use RAIntegration or at least part of it in the future. Licensing is as much about ensuring future derivatives follow a certain set of rules as it is about giving permission for the current clients to use the library.

The emulators pull in two files from RAIntegration - RA_Interface.hh and RA_Interface.cpp. These are the bootstrap stubs for loading the DLL and calling the DLL methods. They are not part of the RAIntegration build, so I don't believe the license directly affects them. They could probably be considered their own product with their own license.

Agreed.

Our only dependencies currently are rapidjson and rcheevos, both of which uses the MIT license. rcheevos is loosely dependent on lua (it's not actually in use yet, but does get compiled in). lua also uses the MIT license.

Good, that means they can be compatible with any license we choose for RAIntegration.

In my opinion, I'd prefer rcheevos be GPL (which would implicitly make RAIntegration GPL) so third-party emulator-in-a-box products have to at least consider the ramifications of using it as a standalone product, although I'm pretty sure there's already precedent for them doing that with RetroArch (which is also GPL), so it doesn't seem like a huge barrier. On the other hand, it might even serve as free advertisement - after the player finds achievements for popular games, they might search out achievements for other games and find us.

Licensing is never implicit as far as I know. If rcheevos is GPL-licensed, it must be clear that RAIntegration is also GPL-licensed. However it is true that if rcheevos is GPL-licensed, RAIntegration must be GPL-compatible.

I disagree that rcheevos being GPL-licensed would be beneficial overall, though I am not completely opposed to it. However, seeing as it is currently licensed under MIT, anyone can use the current version of the software for any purpose whatsoever, and changing the license at this point does not change much unless major updates are introduced.

Scott has indicated that he's open to a fully permissive license

Then, MIT (or even the WTFPL) would work.

Bottom line, we just need to come to a consensus

A custom license is also possible. In my opinion the viral nature of GPL is not desirable at least for rcheevos. If other persons involves are in favor of GPL and understand the implications, I won't argue against it, but if it is only about keeping modifications open source, there are alternatives that are more permissive (I would have to read some more to recommend specific ones).

[Jamiras]

I believe there are some emulators that include RAIntegration code directly, or at least includes the project in VS solution

I could not find any. None of the .sln files I use to build any of the emulators include the RA_Integration project, and the only files that seem to be getting used that appear to be RA-specific are "RA_Interface.cpp" (from the submodule) and "RA_Implementation.cpp" (emulator specific implementations for wrapping the RA_Interface calls - similar to the retroachievements.cpp in RAQUASI88).

If derivatives do not interact with RetroAchievements, there is no reason to deny others the opportunity to reuse the code.

Isn't cheating a concern? Licensing could provide legal ground against it

One person making a custom build to cheat is not as much of a concern as someone embedding the achievement functionality in a standalone emulator-driven product (i.e. Mini-NES knockoff) and marketing it as feature.

Anything that does communicate with the server has a dependency that we can probably control if it came down to it.

Licensing is never implicit as far as I know.

Poor wording on my part. I was just trying to express the requirement that the DLL be GPL if `rcheevos were GPL.

seeing as [rcheevos] is currently licensed under MIT, anyone can use the current version of the software for any purpose whatsoever

Yep, but it's still pre-release software at this point. RetroArch rejected the first attempt to use it because of a crash on Android that still needs investigated. The new DLL (that I'm hoping to release next month) is using a version that's several months old. Getting the license updated before releasing AndNext and Prior would at least protect those.

I disagree that rcheevos being GPL-licensed would be beneficial overall

My only concern is properly protecting the intellectual property. I don't even know if that can be done through software licenses, or if we need to file a patent of something similar. Or even if we care. It doesn't seem like Scott is concerned about it. Maybe I shouldn't be either.

That is a misinterpretation of GPL.

Possibly. Which is one of the reasons I haven't just applied it and called it good. I never claimed to be a licensing expert and have been looking for guidance (or at least feedback) from others. You've provided more in one day than I've gotten from everyone else over the last few months.

If you think leaving rcheevos as MIT and making RAIntegration GPL is the best solution, I don't have any good counter-arguments. From what you've been saying, there's very little benefit in making RAIntegration GPL, so they might as well both just be MIT.

[leiradel]

GPL is viral, and would limit the usage of RAIntegration with emulators that adopt different licenses. LGPL is better, but still poses some problems in some situations.

Example: Someone wants to ship an Android app that is an emulator with RAIntegration (lets suppose it's possible to compile it for that platform). If RAIntegration is LGPL, it means that users of the app should be able to recompile RAIntegration and swap the version of the app for the new one. The issue is, users won't be able to do that unless the app is released in binary form to be re-packaged as an Android app with the new RAIntegration, because of app signing and stuff.

MIT is a better option IMO, and one that requires users to disclose that they're using the software. Some still refuse to use MIT software because of that, and there are other licenses that avoid even that.

I vote for MIT for both RAIntegration and rcheevos.

[rzumer]

Right, I mixed up GPL and LGPL. In fact, dynamically linking a GPL program is still deriving from it (though this is subject to interpretation) and would require emulators to be licensed as GPL in turn.

With LGPL, when dynamically linking there is no such restriction.

I am not familiar with Android deployment, but the concern seems valid. There are also "middle ground" licenses between MIT and L/GPL worth looking into if there is a reason for concern about how the software is used. fmgen, used in QUASI88, uses a custom license requiring the terms to be reproduced in derivatives and those derivatives to remain "free software" (a bit vague for my taste).

On January 11, 2019 5:16:49 AM EST, Andre Leiradella notifications@github.com wrote:

GPL is viral, and would limit the usage of RAIntegration with emulators that adopt different licenses. LGPL is better, but still poses some problems in some situations.

Example: Someone wants to ship an Android app that is an emulator with RAIntegration (lets suppose it's possible to compile it for that platform). If RAIntegration is LGPL, it means that users of the app should be able to recompile RAIntegration and swap the version of the app for the new one. The issue is, users won't be able to do that unless the app is released in binary form to be re-packaged as an Android app with the new RAIntegration, because of app signing and stuff.

MIT is a better option IMO, and one that requires users to disclose that they're using the software. Some still refuse to use MIT software because of that, and there are other licenses that avoid even that.

I vote for MIT for both RAIntegration and rcheevos.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/RetroAchievements/RAIntegration/issues/20#issuecomment-453466646

[Jamiras]

Since the toss-up was between GPL and MIT and it appears that the only difference is of no benefit to us, it seems like MIT is the way to go. I'll leave this open for another week in case anyone else has any feedback, then make the change next weekend.