Will this any affect future versions of the vgmplay/in_vgm?Please be aware that only files distributed by Mamedev (those available via the official GitHub) have been subject to the relicensing efforts.
If you maintain a derivative build please be aware that you will have to gain the correct permission from all contributors for any extra code you have in your build. Code that was distributed under the previous MAME license can not be included or linked to MAME from this point forward without being relicensed, requiring permission from all contributors to that code.
This applies to all derivative builds, including MAMEUI, MESSUI etc. so if you have a derivative build based upon that code you will need to either rewrite from scratch or obtain permission from all contributors to the code in order to relicense.
I just noticed this
Talk about whatever you want. General forum rules still apply.
Moderator: Staff
I just noticed this
http://mamedev.org/?p=423
- ValleyBell Offline
- Posts: 4804
- Joined: 2011-12-01, 20:20:07
- Location: Germany
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.
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...
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.
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.
Lol. This is why I kept on offering the inpout32 alternative builds. And PortTalk is garbage anyway.ctr wrote: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.
-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.
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.
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.