libogc, the library used for Wii homebrew development, has been found to plagiarize an open source project: https://github.com/fail0verflow/hbc/blob/80a80251f83f1993c272c58e471d040f3eb1dee9/README.md
hbc/README.md at 80a80251f83f1993c272c58e471d040f3eb1dee9 · fail0verflow/hbc

The Homebrew Channel - open source edition. Contribute to fail0verflow/hbc development by creating an account on GitHub.

GitHub
@JosJuice The similarity is even more obvious if you compare the lwp_thread_ready function. And this similarity goes back all the way to 2004. Chilling.
@JosJuice Ah, the cat's out of the bag.

It has been discussed for some time in public chat rooms, but IIRC the consensus was that there's nothing that can really be done about it - while the RTEMS code could be updated and re-attributed, as it was relicensed to 2-clause BSD a few years ago, that does nothing with the stash of decompiled Nintendo code. Said code would require someone with very specialized skills and an interest in the GameCube but with no pre-existing knowledge of the code in question, which is not viable on a budget of nullptr_t.
@JosJuice There's a GPL-licensed project I collaborate with, which has a Wii port. It had many maintainers throughout its life, so nobody holds total copyright; as such, exceptions to the GPL for the port cannot be introduced. At the same time, I don't think one can relicense decompiled code to GPL-compatible terms unilaterally.

In this context, finding out about this a few years ago has been personally heartbreaking.
@asie I do happen to have skills and interest while basically not having looked at all at libogc's implementation or Nintendo SDK functions... I bet I would never find the time for it though
@JosJuice aw crap! looks like i gotta get the FOSS version of HBC

@JosJuice Not this only like 1/3 true bullshit again, and that 1/3 part being shagkur's shoddy decompilation. None of the rest of it is true. We talked to shagkur and he admitted he was using RTEMS as reference and too closely at that, but the examples are cherry-picked and don't represent all of the threading code. Also, since RTEMS has relicensed to BSD years ago, even if it had possibly been a problem for a while it isn't anymore.

As for the decompilation...yeah, it ain't great. But if Nintendo cared about it, they would have done something years ago. Which they didn't.

Shitting on WM for any of this is also completely unnecessary and just makes people even more bitter.

@JosJuice As for the now-deleted issue? I get emails on every libogc issue and comment filed (for reasons I don't remember), so I have a copy of it. It's just an inflammatory rant by Marcan telling people not to touch it. Pretending it was people not wanting to fix things (only one of which was actually broken) is disingenuous. It's no wonder it was deleted.

@endrift perhaps you'd like to start posting some comment logs from the github issue instead of us just taking your word for it that it was "an inflammatory rant" while also just "hiding" the github issue?

Not a good look that every time someone opens an issue asking for an official addressing of this that they just close it and remove it from public view. Certainly not how one would go about presenting themselves in a way that would add to positive PR of handling a situation.

@axum I closed and removed none of that; it was someone else acting on their own. While I do have the logs of the original posts, I don't have any versions that may contain edits, by either party, and don't really want to repost them without permission from any of the people who did post in that thread. If DacoTaco, the person who replied first and closed it, OKs it I will post them. The hiding was done by someone else later.

I'm barely even affiliated with the project. I've just seen lots of bullshit levied at people who are already struggling day-to-day and don't need more shit to deal with. Passive aggressive phrasing and holier-than-thou speeches from someone who actually has zero affiliation with the community helps literally no one.

@endrift @JosJuice

It is all completely unnecessary, sure. In the end, everyone affected will be back to using libogc by Tuesday; I tried to rally together people to work on a libogc alternative, but it's a lot of work for what is nowadays a very niche platform.

However, it also could have been avoided by putting out a transparent statement saying exactly this any time during the past 16 months (!) since the original accusation repository dropped in January 2024, and that's a big part of my personal frustration. These links spread around in chat rooms, in private circles, but the only time anyone gets a response is when shit hits the proverbial fan. Misconceptions are never clarified, because the homebrew scene has been permanently divided between a private Discord attached to a GitHub organization with dozens of deleted issues on one side, and everyone else on the other side.

As it stands, we've spent years idly wondering if the Wii port of an open source project is legal to distribute or not in the first place. I've spent hours tracking down the original author of a DS touch driver to figure out if it was decompiled and how said decompiled code got into libnds; getting libgl2d at all licensed and getting DLDI headers relicensed.

Even today, I've had to put out misconceptions on four Discord servers, not only to defend the reputation of a project I'm banned from contributing to and many of my friends in the community are banned from contributing to as well, but also to be able to get back to productive things, like not wondering if we're all a bunch of hypocrites if our homebrew releases pirate someone else's code while we proclaim a blanket ban on copyright infringement and just enjoying our awkward little retro console hacking hobby again.

To be clear, I know it's not your fault, but this keeps happening and it seriously makes me want to not contribute to any homebrew scene with a devkitPro-backed toolchain attached, because somehow that's the correlation I'm dealing with here - I don't see this kind of stuff in the NES scene or SNES scene or Mega Drive scene; the N64 and PS1 scenes have problems with leaked/decompiled code, but everyone will transparently tell you where the issues are and many are working on fixing them; the Game Boy scene has a schism of its own but plenty of people work across the drama lines; etc, etc.

I'm going to bed; I'd like to wake up tomorrow in a world where we once again know how to talk to each other.
@asie @JosJuice I may look into filing a PR to attach BSD 2-clause acknowledgments to the lwt stuff if that hasn't happened already. That's really all that needs to be done there. But the decompiled code is...much harder to do anything about. It would require people with expertise, time and motivation, and it's very much a "pick two" type situation. I'm not entirely sure how putting out a statement would really help anything other than try to stave off misinformation, though.
@endrift @JosJuice

The acknowledgements will only apply if none of the code in question was removed before the relicensing; however, if what you're saying is true, that should be pretty easy.

TuxSH made it pretty clear in GodMode9 and on HN already that the answer would be to write a clean library, and I agree with him there; however, I've looked for people willing to do it as early as 2023, and nobody with interest had time, nobody with time had interest, while those with both interest and time were already "tainted".

Honestly, if there's one good outcome of this drama, it could be that a group of people forms who take on the challenge...
@asie @endrift @JosJuice hopefully! I'd do that myself if there wasn't a need for the library to use C..

@endrift @JosJuice

I'm not entirely sure how putting out a statement would really help anything other than try to stave off misinformation, though.I missed this part, sorry. Yes, I think it would stave off misinformation, at the cost of having to deal with a (much reduced) version of the drama up front. I also think staving misinformation in general would really help devkitPro's mission - instead, people with knowledge are being told to "[not] engage if you aren't a stakeholder" on back channels, allowing Hector's version to pretty much monopolize public discourse.

@asie @endrift @JosJuice

"TuxSH made it pretty clear in GodMode9 and on HN already that the answer would be to write a clean library, and I agree with him there;"

To be clear this is my personal opinion, and I kind of had calico in mind (something which was used to rewrite the innards of libnds) when writing that.

@endrift @JosJuice

"admitted he was using RTEMS as reference and too closely at that" is overstating things quite a bit I feel. Used as a reference then wrote his own code which ended up with similar variable names and similar functions would be closer to the mark.

@endrift @JosJuice

Brandolini's law in full effect as usual. I removed Marcan's "issue" because it's just more drama from someone who's had a grudge for many years and likes to signal boost all the disingenuous claims of wrongdoing. Why should I put up with inflammatory rants on my github issues rather than just filing them in the bin where they belong? Why do people take the drama at face value but any defence of us or our work needs a higher standard of evidence?

@endrift @JosJuice

Shagkur may have reverse engineered (and in one of the truest senses of that phrase) an SDK library that someone else gave him. There was no reading of source code or tools to turn assembly into C. It wasn't until after Marcan turned up throwing his weight around demanding to be treated as the god of wii homebrew & expecting Shagkur & I to bow down before him and immediately change our working practices to suit his agenda that things became a big problem.

@endrift @JosJuice

To be clear here. Shagkur approached me in 2003 with what became libogc. I worked with him to clean things up and integrate some parts with devkitPPC. Perhaps I was naive but I had no idea any of this was RE'd from a leaked SDK at the time and remained oblivious until Marcan started a bunch of drama around 2009/2010 that was mainly a storm in a teacup. We couldn't go back in time 6/7 years and rewrite everything. Many people contributed code and bugfixes

@endrift @JosJuice

libogc was its own thing by that stage and Nintendo hadn't come after us at all. We know for a fact that Nintendo have used devkitPro tooling for various things. There are server logs showing people at NERD installing tools and libraries.

We've done a lot to help improve homebrew ecosystems over the years. Many people appreciate that. Many people have leveraged the experience gained using our tools into well paying jobs.

@endrift @JosJuice

I'm sorry for whatever has gone wrong in Hector's life that he feels the need to lash out at us 14 years after he heard that parts of libogc were RE'd from SDK code. I hope he finds peace one day.

I have family and my own things to deal with. I have little time for internet drama.

@davejmurphy @endrift @JosJuice
Thanks for sharing this! I had just written a blog post with my opinion on the issue because it was already clear that there was nothing "stolen" here: https://mardy.it/blog/2025/04/no-libogc-did-not-steal-rtems-code.html
But it's anyway relieving to see this confirmed by the source.
No, libogc did not steal RTEMS code

All of a sudden the Wii homebrew community is in flames after Hector Martin (marcan, also known in the Linux Kernel community), co-author of “The Homebrew Channel” application, decided to close the p

Mardy
@mardy @davejmurphy @endrift @JosJuice I spent weeks on this issue back in January 2024, and I do strongly believe RTEMS was plagiarized wholesale. I just wish we could come to a solution like adults, and we have an easy one available.
@extrems @davejmurphy @endrift @JosJuice There are two questions I'd like you to answer then:
1) What exactly do you mean by "plagiarized wholesale"?
2) How did you form this opinion?
@mardy @davejmurphy @endrift @JosJuice I compared everything independently with the actual RTEMS source tree. The structure is the same (including the weird .inl/.h splits), the naming is practically the same, the operations are written the same. It's just... difficult to think otherwise. Even the Dolphin SDK-like API is based off their pthreads interface.
@extrems @davejmurphy @endrift @JosJuice Have you got more bits of code to compare? It's just that those provided by Marcan are far from being a smoking gun. It looks like a close reimplementation of only the needed features.

@extrems @mardy @endrift @JosJuice

Of course you do. It's not like you've spent years trying to get traction for all your hostile forks of libogc ...

@JosJuice Insane news to just randomly stumble upon.

I had already known about the rumours about shagkur smuggling in code and secret knowledge from the SDK into libogc, but didn't think there was anything beyond that.

Well, I also knew that the kprintf implementation that libogc uses is GPL'd (https://github.com/devkitPro/libogc/issues/75) and they just dropped it right into the library, but threading and other integral functionality being tainted like this is absolutely bonkers.

kprintf is GPL · Issue #75 · devkitPro/libogc

libogc includes a copy of kprintf, which was distributed under the GPL, despite libogc having a license most closely matching MIT. https://github.com/devkitPro/libogc/blob/master/libogc/kprintf.c

GitHub