libogc

> Without a CLA, that's not doable without the approval of all the contributors. Three things: - libogc is BSD 3-clause[1], which is GPL-compatible[2][3]. That means that while you can't just strip off the existing BSD license, you can distribute a combination of source code that is BSD and GPL licensed, it just has to be distributed under the terms of the GPL, which is fully compatible with the terms of a BSD license, too, since all BSD licenses require is maintaining the copyright notice/disclaimer, and nothing about that requirement conflicts with the GPL. (IANAL, so take with a grain of salt, but I'm pretty positive on this one.) - Although RTEMS is traditionally GPL, it's actually a modified version of GPL with the GNAT exception[4]. A compiler exception effectively allows users to link the object files into software of any license w

I think this comparison by armada651 linked in yesterday's thread is a better example (https://news.ycombinator.com/item?id=43818214) https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc... https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103... Multiple functions in that file are near identical.

I looked for other examples in the code and found __lwp_thread_changepriority pretty damning, judge for yourself: https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc... https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103... The only difference is that the prependit parameter and its associated branch is missing, other than that the functions are completely identical.

> The OP cites these (https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103... and https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc...), but that's hardly a smoking gun. The function is trivial, just filling in some struct fields. Yeah, I'm with Marcan 90% of the time, and in my view Marcan is more likely than not right that that function is derived from the RTEMS function, but in my view there's still reasonable doubt. That is to say, purely based on the evidence linked, I only agree that it's probable that the code is copied and disagree with Marcan's claim that it's "not possible" for the implementation to be non-infringing. The fact that some of the identifiers are similar raises the biggest suspicions. "__lwp_stack_isenough" vs. "_Stack_Is_enough" is suspicious because I'd probably call that "sufficient_stack_avail

This is a strange accusation. The repo linked as proof (https://github.com/derek57/libogc) consists of over 100 commits meticulously converting the libogc codebase to look more like the RTEMS codebase, and claiming that's enough proof that it's the same codebase. I wonder if it'd even build, or if those changes didn't break anything? Regardless of whether there's any truth to this anonymous accusation, this doesn't seem like the right way to go about it. An article walking through some of the similarities would be much more helpful to prove the point (and probably less work for whoever went through this exercise). At least provide some links to RTEMS code comparing the libogc code. The OP cites these (https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103... and https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc...), but t

If anyone is interested in making homebrew for the Wii: https://github.com/devkitPro/libogc is pretty good. Certainly not as easy as say GBStudio or any game engine but the Wii's graphics being fixed function makes things a lot easier.

As with most console homebrew communities, this is already a thing. https://github.com/devkitPro/libogc It doesn't seem like it's been heavily used on GC, but the Wii has a decent homebrew scene. Nothing really compares to the OG Xbox though, starting off in console modding on that platform really ruined me for everything else.