Live data from Hacker News

Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

github.com

81–90 of 169 posts

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#81
post #68
post #58

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…

FWIW, whether you agree with the accusation or not, it isn't anonymous. The commit history makes it obvious that it's marcan (Hector Martin) making the accusations. Whether it's really worth all of the hooplah or not is going to be up to taste. I think it's pointless to just not explicitly credit RTEMS personally, but I suspect the real point of doing this is probably in large parts just to distance themselves from t…

> FWIW, whether you agree with the accusation or not, it isn't anonymous. The commit history makes it obvious that it's marcan (Hector Martin) making the accusations.

I was referring to this repo by github account "derek57": https://github.com/derek57/libogc

I assume it's anonymous because the account has no public contact info.

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#82
post #71

Earlier quoted context omitted.

> Thing is, GPL requires you to explicitly allow that behavior, so HBC can't use GPL software. Couldn't, not at the time. HBC has been open-sourced some time ago, sans DRM, as the Wii has long lost commercial relevance beyond enthusiast communities. This open-source re-release is what the repository is.

Also worth noting: the version of GPL used by RTEMS seems to be one with a compiler exception, so it probably wouldn't have been an issue for HBC.

Yes[0], and if Team Twiizers had consciously decided to use RTEMS code in that way, they probably would have been fine. However, libogc still cannot legally strip out the GPL copyright notices and distribute RTEMS code in that way.

That being said, RTEMS itself is trying to relicense to BSD 2-Clause, which would obviate the concerns over copyleft, but NOT the thing that libogc did. In fact, the 2 clauses left in the BSD 2-Clause license are the ones that require you to retain the copyright notices. So libogc is still in the wrong.

[0] https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/LICENS...

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#83
sorry if this is an unpopular opinion, but i have absolutely zero problems with them reverse-engineering nintendo code, nor do i really care that much about GPL violations against a project called "Real-Time Executive for Missile Systems"

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#84

How much "reverse engineering" these days really is clean room and how much of it is just ripping off proprietary software? One can easily find a bazillion of "github repos" that distribute what is evidently directly decompiled game code with minimal cleanup. Bonus points if they also claim it is OK as long as the game art is not distributed, which in addition to being wrong is disrespectful to developers as a whole.…

Note that reverse engineering does not have to be clean room, poking at hardware without ever seeing any software. In many places, poking at the proprietary software, decompiling it, tracing it, and so forth is fine despite what unenforcable EULA's might suggest. What is not okay is taking the binaries or decompiled source verbatim and re-distributing it. Note that e.g. copyright does not apply to decompiled source c…

Copyright does apply to decompiled source code (it's a derivative work of the binary).

However, reverse engineering is allowed explicitly (...in several countries, ask a local lawyer!) for the purpose of interoperability, and sometimes for certain kinds of research. In those cases, what would otherwise be cooyright infringement is permitted.

If you're not doing it for those reasons (e.g. to attain exacting bug-for-bug levels of compatibility with a proprietary system, as is often needed in emulators), if in fact you could use any threading library, you don't then get to take an unrelated library and file the serial numbers off.

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#85

Earlier quoted context omitted.

Note that reverse engineering does not have to be clean room, poking at hardware without ever seeing any software. In many places, poking at the proprietary software, decompiling it, tracing it, and so forth is fine despite what unenforcable EULA's might suggest. What is not okay is taking the binaries or decompiled source verbatim and re-distributing it. Note that e.g. copyright does not apply to decompiled source c…

> the original authors did not write the decompiled source This isn't anything new or unique to programming. In the same way if I were to transcribe a movie (let's say it's a silent movie) to a script, it would still be that movie. Or if I were to translate a book into Klingon . Or even do a cover song of "Beat It" entirely with throat singing. Copyright would still apply.

> Or even do a cover song of "Beat It" entirely with throat singing. Copyright would still apply.

bad example, in this specific case copyright would actually not apply

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#86

What is "RTEMS?"

It’s a real time operating system for for serious embedded systems where standards compliance and predictability are critical — think satellites or military drones. It compares to VxWorks if you are familiar with it

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#87
post #58

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…

I'm not an expert in embedded systems, but I do work on them at a very low level, and I can't be sure 100% of my code would differential from the RTEMS code base any more than libogs's. That doesn't mean they didn't do it - but the concepts behind Real Time Operating Systems in general are well known, and nearly standardized.

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#88

How much "reverse engineering" these days really is clean room and how much of it is just ripping off proprietary software? One can easily find a bazillion of "github repos" that distribute what is evidently directly decompiled game code with minimal cleanup. Bonus points if they also claim it is OK as long as the game art is not distributed, which in addition to being wrong is disrespectful to developers as a whole.…

> How much "reverse engineering" these days really is clean room and how much of it is just ripping off proprietary software?

I did mine clean room. When I reverse engineered my laptop's features, I intercepted the proprietary software's communications with the hardware, compiled my findings into a whole bunch of notes and then wrote my own free software to do the same thing based on those notes.

> But when the Nintendo copyright czar wakes up, they're the bad guys...

They are always the bad guys. Copyright owners are monopolists. Copyright as a whole should be abolished. I don't care what the so called "pirates" are doing, they are always less morally wrong than eternal copyright monopolists who rob us of our public domain rights and turn perfectly good computers into locked down digital fiefdoms where we are serfs.

20 year old games you grew up with? Give me a break. These companies have all made their fortunes multiple times over. This "intellectual property" should already be in the public domain by all reasonable accounts. God forbid Nintendo be unable to sell you the exact same Mario ROM for the 10th time though. We're all going to be long dead before our culture returns to us. That means it effectively never will.

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#89
post #39

Earlier quoted context omitted.

Wow! What an achievement for those devs. https://www.rtems.org/applications/

It’s a missile OS so this isn’t particularly surprising.

Amazingly enough, things can be surprising when you don't know anything about them, regardless of their intended purpose.

But I suppose forums/Internet can be grumpy about other's amazement.

Re: Libogc (Wii homebrew library) discovered to contain code stolen from RTEMS

#90
post #58

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…

> 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_available" or something like that. "LWP_STATES_DORMANT" vs. "STATES_DORMANT" is also suspicious because the normal OS term would be "sleeping". Still, the function logic is different enough that, even with that evidence, one could plausibly claim that only the headers or interface were copied and the implementation was clean-room, which is non-infringing per Oracle v. Google.

In US legal system terms, I'd say that a preponderance of the evidence shows that the code is a derivative work (i.e. it's more likely than not that the code was copied at some point), but that there's still reasonable doubt (i.e. a reasonable person could plausibly believe otherwise).

Post reply on HN