RTEMS

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

You have a great point. I'm finding it hard to determine that actual harm has occurred here. The problem can be corrected, and the hbc project can still meet the requirements and spirit of open source. But neither fail0verflow nor libogc seem to care about any of this, and instead everything was frozen. You don't need permission to use open source code.. So there appears to be two double standards occurring at once. This story is weird. >The current developers of libogc are not interested in tracking this issue, finding a solution, nor informing the community of the problematic copyright status of the project. When we filed an issue about it, they immediately closed it, replied with verbal abuse, and then completely deleted it from public view. >For this reason, we consider it impossible to legally and legitimately compile this software a