vgmrips

http://mamedev.org/?p=423



Will this any affect future versions of the vgmplay/in_vgm?

I'm not too familiar with the copyrights, but IIRC, MAME/MESS is open source, which means it can be shared, as long as there are no profits being made. I'm sure we're in the clear.

It didn't affect us previously, so it shouldn't afftect us in the future.

Actually, the relicensing of MAME source code should make VGMPlay less of a license violation than it is was before.
Previously it mixed "MAME licensed", GPL, LGPL and "Apache License" and I don't think the MAME license was compatible with GPL.
Additionally there is code from Ootake and MEKA emulators where I don't know what license they use at all.

tl;dr: It can only affect us in a positive way, if at all.

As you know, MAMEdev decided to relicense all the code under FOSS licenses. What that post meant is any code added to MAME from now on cannot use the old MAME license as it was not FOSS or GPL compatible.

Regarding VGMPlay, we're not a deriative of MAME but we do use MAME code, which used to be under the MAME license. A few months ago the FM cores were relicensed under the GPL version 2. At that point, all the MAME code we have in VGMPlay became either BSD or GPLv2 licensed.

Ootake prohibits commercial use, but could be disabled for a GPL-compliant release as the MAME core can be used as an alternative, while the MEKA code we use is in either public domain or public copyright..

dac_control.c prohibits non-VGM and commercial use, making it incompatible with the GPL. I don't think ValleyBell would mind removing those conditions though...

The only license violation we have right now would be the PortTalk code (which prohibits any distribution of source code). It can be safely removed if you don't need the hardware support.

With those steps done VGMPlay could be redistributed legally under the GPLv2 and be used in GPLv2 software without any legal problems...

I guess I was just being overly paranoid. When I first read it, it sounded like if you wanted to use any specific code you had to contact the authors who wrote it and get their permission to use it outside of mame (like what many mod authors for various games make you do these days). Looks like that's not the case.

No, with GPLv2 you don’t have to do that.

What the notice means is that if you are using MAME code in your project and others contributed modifications to that code in your project, in order to be able to distribute the MAME code as GPLv2 you must separately get relicensing permission from your own contributors, or remove/reimplement the modifications.

Even better, I just read on a news site that most of the MAME code is available under BSD license (free) rather than GPL (copyleft).

Well unfortunately for us all the FM cores are GPL'd.

Ah, that’s too bad…

Lol. This is why I kept on offering the inpout32 alternative builds. And PortTalk is garbage anyway.

_________________
-dj.tuBIG/MaliceX

Yeah- no.

The Mamedevs said a while back that we can't retroactively use older versions of the MAME-licensed codebase, even if the updated equivalent is now "free" aka GPL'd. Which means that we would have to do the MAME ports from scratch; again.

P.S: the dac_control.c and the PortTalk licensing issues are still not resolved.

A code review should be enough. If there aren't any real changes between the version we used and the first version after the relicensing, i think it will work without having to throw away our changes. The statements about not relicensing older versions i think applies to entire distributions, where code exists that was rewritten or removed due to their respective authors refusing relicensing. Afaik we don't have any such code.

I will say that the original MAME sources for the chips are usually from before they switched to C++, so we would have to undo that for every source file we port to vgmplay.

PortTalk can be safely removed (although it will affect real hardware interfacing on some Windows versions, but copyright-wise this doesn't even matter thanks to Oracle v. Google) and dac_control is not a real issue.

A final thing is that Valley Bell is currently working on a new VGM playback library called libvgm. I believe a goal is to make licensing easier by modularizing the code.