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

New Implementation: mGBA #3

Open
mid-kid opened this issue Jan 2, 2020 · 7 comments
Open

New Implementation: mGBA #3

mid-kid opened this issue Jan 2, 2020 · 7 comments

Comments

@mid-kid
Copy link
Member

mid-kid commented Jan 2, 2020

An old, linux-only implementation for mGBA was made here: https://github.com/mid-kid/mgba
This is of course, incomplete, and should be re-done, to fit better with the mGBA codebase, and support more platforms.

What is interesting about porting to mGBA, is that mGBA supports both GB and GBA games, and we can integrate it right in the emulator, making it the perfect option for the casual player that wants to get up and running. I presume this will become the primary non-development implementation in due time.

Ideally, this would also work on the other platforms that mGBA supports, but that should probably be a separate issue, given mGBA's structure.

@arves100
Copy link
Member

https://github.com/arves100/mgba/tree/feature/adapter
Implemented here, apart from the missing issues (the fork should be transferred to reon directly), the current license of libmobile would not allow a merge (it would relicense all mgba code to agplv3), an idea would be splitting arduino and libmobile repo.

@mid-kid
Copy link
Member Author

mid-kid commented Aug 20, 2021

I'll relicense it when I'm done with the wip branch, don't worry about that. I chose AGPL mostly due to that being my default for hw projects, but I realize that's not a good license for a library.

@mid-kid
Copy link
Member Author

mid-kid commented Aug 20, 2021

@endrift Is MPL acceptable?

@endrift
Copy link

endrift commented Aug 20, 2021

LGPL would be better for libmobile I think. MPL is...well, for libraries it's kinda meaningless.

@endrift
Copy link

endrift commented Aug 20, 2021

That said, it depends on what you hope to accomplish with the license. If you don't care how people use it beyond attribution then MIT or BSD 2-clause would be better. If you want proper attribution and copyleft-like for the library, LGPL is better.

@mid-kid
Copy link
Member Author

mid-kid commented Aug 20, 2021

Thanks for the insight. I mostly care about getting back improvements, and due to frequent ABI changes, I intend this library to be shipped along with a project (which in practical terms often implies static linkage), so I feel like LGPL might hamper its adoption. That said, I mostly care about mGBA, so if LGPL is acceptable for that, I'll probably use that.

@endrift
Copy link

endrift commented Aug 20, 2021

For static linking LGPL could hamper its adoption, since it requires statically linked programs to give a way to re-link with different versions of the library. This is rarely enforced, however, and is frequently violated. Either one works with mGBA since I'd probably vendor it upstream (unless I finally cave and use submodules).

@mid-kid mid-kid transferred this issue from REONTeam/ArduinoAdapterGB Aug 20, 2021
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

3 participants