Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a license #47

Open
chrisdonahue opened this issue Oct 19, 2018 · 10 comments
Open

Add a license #47

chrisdonahue opened this issue Oct 19, 2018 · 10 comments

Comments

@chrisdonahue
Copy link

Hello,

Could you add a LICENSE for VGM Play? Preferably something permissive like MIT license but of course feel free to choose something appropriate :)

Cheers,
Chris

@felipesanches
Copy link
Contributor

felipesanches commented Oct 19, 2018

seems to be a mess... I think the end result needs to be GPL after mixing all of those licenses.

https://github.com/vgmrips/vgmplay/blob/f712603913050feca455dcd547f981dc1f2ebc9a/VGMPlay/licenses/List.txt

I agree that licensing should be stated more explicitly in the root of the repo.

@chrisdonahue
Copy link
Author

Oh wow somehow I missed this. Thanks for filling me in! I agree that it would be nice if this could be aggregated at the root.

@felipesanches
Copy link
Contributor

can you help us figure out the best way to do it?

@superctr
Copy link
Contributor

Vgmplay is really one giant license violation, mixing GPL, non-GPL and proprietary licenses. I would not suggest using it for commercial purposes.

@felipesanches
Copy link
Contributor

Beware that a licensing violation is still a violation even if not used with commercial purposes.

I would like to see such hypothetical violation fixed, instead of worked around.

@superctr
Copy link
Contributor

Yes but doing so will either require a lot of work to replace the violating code or removing functionality. And much of the focus is now on libvgm anyway.

@leycec
Copy link

leycec commented Jan 29, 2019

In Gentoo land, our working assumption has been that VGMPlay's bundling of multiple GPL 2-licensed dependencies effectively mandates that VGMPlay itself be GPL 2-licensed. Of course, there are confounding factors:

  • The license of three bundled dependencies (i.e., Ootake, MEKA, and in_wsr) is literally unknown.
  • Non-GPL dependencies are not necessarily compatible with the GPL 2 – but usually are, thankfully.
  • Nobody cares, because VGMPlay will either:
    • Be rewritten from the ground up to use libvgm, at which point most or all of this encumbered code will "be disappeared."
    • Go away entirely in favour of more mature alternatives (e.g., libvgm-based mpd plugin).
  • The legality of vgmrips.net itself is dubious at best. Fortunately, none of the relevant copyright holders (e.g., Sega) appear to particularly care – presumably because they're sufficiently divorced from reality that they fail to realize what an absolute goldmine of 80's synthwave nostalgia they're lazily hoarding.

It is sad. It is life. </collective_shrug>

@superctr
Copy link
Contributor

Probably the biggest license violation currently in vgmplay would be most of the sound chip emulators that still fall under the old MAME license, which explicitly prohibits commercial use and is incompatible with the GPLv2. This code was rebased to the latest MAME version (which is either GPLv2 or BSD 3 clause) in libvgm.

@ValleyBell
Copy link
Contributor

I'm afraid libvgm still contains the sound cores from Ootake and in_wsr and this won't change anytime soon.
I need to replace the POKEY emulator someday though. It's the only one that still has the old MAME license.

libvgm won't use sound cores from MEKA at least. VGMPlay uses one of its cores for playing YM2413 VGMs on AdLib/Sound Blaster cards, but that's not something I plan to add to libvgm.

The biggest copyright violation in the whole project is PortTalk anyway, which is used for I/O port access on Windows NT/2000/XP.

@superctr
Copy link
Contributor

superctr commented Jan 31, 2019

Ootake's author can be contacted though the email address in the readme file. I would suggest doing so and ask if it is OK to distribute the sound code under the GPL.

in_wsr code comes from Oswan, for which I could not find a license or even the author's email address.

Porttalk I wouldn't worry about as it can easily be removed and I don't think the original author cares. His website is here anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants