Historically, efforts to create original games and tools, port over open source emulators, and explore a game console’s hardware and software have been generally lumped together under the banner of “homebrew.” While not the intended outcome, it’s often the case that exploring a console in this manner unlocks methods to run pirated games. For example, if a bug is found in the system’s firmware that enables a clever developer to run “Hello World”, you can bet that the next thing somebody tries to write is a loader that exploits that same bug to play a ripped commercial game.
But for those who are passionate about being able to develop software for their favorite game consoles, and the developers who create the libraries and toolchains that make that possible, the line between homebrew and piracy is a critical boundary. The general belief has always been that keeping piracy at arm’s length made it less likely that the homebrew community would draw the ire of the console manufacturers.
As such, homebrew libraries and tools are held to a particularly high standard. Homebrew can only thrive if developed transparently, and every effort must be taken to avoid tainting the code with proprietary information or code. Any deviation could be the justification a company like Nintendo or Sony needs to swoop in.
Unfortunately, there are fears that covenant has been broken in light of multiple allegations of impropriety against the developers of libogc, the C library used by nearly all homebrew software for the Wii and GameCube. From potential license violations to uncomfortable questions about the origins of the project, there’s mounting evidence that calls the viability of the library into question. Some of these allegations, if true, would effectively mean the distribution and use of the vast majority of community-developed software for both consoles is now illegal.
Homebrew Channel Blows the Whistle
For those unfamiliar, the Wii Homebrew Channel (HBC) is a front-end used to load homebrew games and programs on the Nintendo Wii, and is one of the very first things anyone who’s modded their console will install. It’s not an exaggeration to say that essentially anyone who’s run homebrew software on their Wii has done it through HBC.
But as of a few days ago, the GitHub repository for the project was archived, and lead developer Hector Martin added a long explanation to the top of its README that serves as an overview of the allegations being made against the team behind libogc.
Somewhat surprisingly, Martin starts by admitting that he’s believed libogc contained ill-gotten code since at least 2008. He accuses the developers of decompiling commercial games to get access to the C code, as well as copying from leaked documentation from the official Nintendo software development kit (SDK).
For many, that would have been enough to stop using the library altogether. In his defense, Martin claims that he and the other developers of the HBC didn’t realize the full extent to which libogc copied code from other sources. Had they realized, Martin says they would have launched an effort to create a new low-level library for the Wii.
But as the popularity of the Homebrew Channel increased, Martin and his team felt they had no choice but to reluctantly accept the murky situation with libogc for the good of the Wii homebrew scene, and left the issue alone. That is, until new information came to light.
Inspiration Versus Copying
The story then fast-forwards to the present day, and new claims from others in the community that large chunks of libogc were actually copied from the Real-Time Executive for Multiprocessor Systems (RTEMS) project — a real-time operating system that was originally designed for military applications but that these days finds itself used in a wide-range of embedded systems. Martin links to a GitHub repository maintained by a user known as derek57 that supposedly reversed the obfuscation done by the libogc developers to try and hide the fact they had merged in code from RTEMS.
Now, it should be pointed out that RTEMS is actually an open source project. As you might expect from a codebase that dates back to 1993, these days it includes several licenses that were inherited from bits of code added over the years. But the primary and preferred license is BSD 2-Clause, which Hackaday readers may know is a permissive license that gives other projects the right to copy and reuse the code more or less however they chose. All it asks in return is attribution, that is, for the redistributed code to retain the copyright notice which credits the original authors.
In other words, if the libogc developers did indeed copy code from RTEMS, all they had to do was properly credit the original authors. Instead, it’s alleged that they superficially refactored the code to make it appear different, presumably so they would not have to acknowledge where they sourced it from. Martin points to the following function as an example of RTEMS code being rewritten for libogc:
While this isolated function doesn’t necessarily represent the entirety of the story, it does seem hard to believe that the libogc implementation could be so similar to the RTEMS version by mere happenstance. Even if the code was not literally copy and pasted from RTEMS, it’s undeniable that it was used as direct inspiration.
libogc Developers Respond
At the time of this writing, there doesn’t appear to be an official response to the allegations raised by Martin and others in the community. But individual developers involved with libogc have attempted to explain their side of the story through social media, comments on GitHub issues, and personal blog posts.
The most detailed comes from Alberto Mardegan, a relatively new contributor to libogc. While the code in question was added before his time with the project, he directly addresses the claim that functions were lifted from RTEMS in a blog post from April 28th. While he defends the libogc developers against the accusations of outright code theft, his conclusions are not exactly a ringing endorsement for how the situation was handled:
In short, Mardegan admits that some of the code is so similar that it must have been at least inspired by reading the relevant functions from RTEMS, but that he believes this falls short of outright copyright infringement. As to why the libogc developers didn’t simply credit the RTEMS developers anyway, he theorizes that they may have wanted to avoid any association with a project originally developed for military use.
As for claims that libogc was based on stolen Nintendo code, the libogc developers seem to consider it irrelevant at this point. When presented with evidence that the library was built on proprietary code, Dave [WinterMute] Murphy, who maintains the devkitPro project that libogc is a component of, responded that “The official stance of the project is that we have no interest in litigating something that occurred 21 years ago”.
In posts to Mastodon, Murphy acknowledges that some of the code may have been produced by reverse engineering parts of the official Nintendo SDK, but then goes on to say that “There was no reading of source code or tools to turn assembly into C”.
From his comments, it’s clear that Murphy believes that the benefit of having libogc available to the community outweighs concerns over its origins. Further, he feels that enough time has passed since its introduction that the issue is now moot. In comparison, when other developers in the homebrew and emulator community have found themselves in similar situations, they’ve gone to great lengths to avoid tainting their projects with leaked materials.
Doing the Right Thing?
The Wii Homebrew Channel itself had not seen any significant updates in several years, so Martin archiving the project was somewhat performative to begin with. This would seem to track with his reputation — in addition to clashes with the libogc developers, Martin has also recently left Asahi Linux after a multi-bag-of-popcorn spat within the kernel development community that ended with Linus Torvalds declaring that “the problem is you”.
But that doesn’t mean there isn’t merit to some of his claims. At least part of the debate could be settled by simply acknowledging that RTEMS was an inspiration for libogc in the library’s code or documentation. The fact that the developers seem reluctant to make this concession in light of the evidence is troubling. If not an outright license violation, it’s at least a clear disregard for the courtesy and norms of the open source community.
As for how the leaked Nintendo SDK factors in, there probably isn’t enough evidence one way or another to ever determine what really happened. Martin says code was copied verbatim, the libogc team says it was reverse engineered.
The key takeaway here is that both parties agree that the leaked information existed, and that it played some part in the origins of the library. The debate therefore isn’t so much about if the leaked information was used, but how it was used. For some developers, that alone would be enough to pass on libogc and look for an alternative.
Of course, in the end, that’s the core of the problem. There is no alternative, and nearly 20 years after the Wii was released, there’s little chance of another group having the time or energy to create a new low-level C library for the system. Especially without good reason.
The reality is that whatever interaction there was with the Nintendo SDK happened decades ago, and if anyone was terribly concerned about it there would have been repercussions by now. By extension, it seems unlikely that any projects that rely on libogc will draw the attention of Nintendo’s legal department at this point.
In short, life will go on for those still creating and using homebrew on the Wii. But for those who develop and maintain open source code, consider this to be a cautionary tale — even if we can’t be completely sure of what’s fact or fiction in this case.
i don’t understand why libogc users would really care. if you want to run your own software on a computer without running afoul of licenses every step you take, there’s a whole world of non-nintendo hardware.
Nintendo specifically has a history of crushing community projects and threatening creators/users with life-ending lawsuits. If they can legally take your house and put you in jail, they will. And their attorneys are way better than yours. For homebrew on Nintendo consoles to be allowed to exist, it has to be more than squeaky clean. It has to unequivocally decry piracy. So having anything even possibly derivative included is a big problem.
They project is basically end of life. Archiving it just signals that.
Nintendo might send a largely pointless DMCA to take it down that will go unchallenged but still achieve nothing.
They have a history of going after projects that threaten their bottom line (Yuzu) and projects that could threaten their copyright ownership (Pokemon Uranium). They don’t care about homebrew unless it’s for their current system and advertises itself and/or piracy. (Also if it makes money).
False. Nintendo is litigous towards all of its properties. Whatever is making them money at the time is irrelevant. Just have a look at them blocking Dolphin from being released on Steam for fear of it easily enabling GCN/Wii emulation on the Deck. Their claim was that the Dolphin team used illegally obtained Wii decryption keys, but the project is still thriving as much as it ever did. Valve just came to an out-of-court agreement to block it from being released on Steam.
they AREN’T allowed to exist. they CAN’T be squeaky clean. if you wanted to work with a platform that isn’t backed by a company that’s at war with you, you CAN’T USE NINTENDO
and given that self-evident fact, that’s why i don’t understand anyone caring about libogc’s providence.
What’s wrong with this? It’s just reverse engineering
it’s not clean-room reverse engineering, the C code derived from decompilation is considered a derivative work of the original copyrighted program.
I know it’s not a guarantee but I think if that was true the N64 decomp projects would’ve already tasted the fire of heaven with how litigious Nintendo is.
I don’t think this is true outside of extra locked down countries. And clean room is just the gold standard because its basically completely free and clear outside of extremely draconian places where even complaining about it might cost you your tongue.
Some of them did. You don’t seem to understand how Nintendo affects the developer pool for these projects.
Who cares? It’s morally reprehensible that Nintendo would sue the creators of palworld on “patent infringement” grounds when they happened to make a game that people older than ten actually wanted. They sue even when they have zero grounds in the patents they’re arguing. They deserve to have their code stolen (which hasn’t happened here).
Not to mention this would have long hit the statute of limitations. You can only argue on moral grounds now since there’s nothing that can legally be done.
The reason the hacking scene died for Xbox and Sony is because the companies actually supported features that we wanted. Nintendo, instead of learning from homebrew, just litigates. They’re a garbage company stuck in their ways. They deserve to fall.
It’s illegal in some third-world countries.
RE violates the tos you agree to when buy a game. REd code can also be considered infringment.
TOS in and of itself is not legally binding, it has to be brought to court and successfully legally defended to really have any teeth.
can I buy the game and do NOT agree to TOS?
No, your purchase and use of the game constitutes an implicit agreement to the ToS.
In some countries yes, but the laws around that sort of thing vary a lot. Plus a company can claim all sorts of things in a ToS, but not all of them may be enforceable. (eg they may say you have no warranty, but some countries insist on a minimum warranty period).
Your purchase can’t. Not possible: you could’ve bought it secondhand and never seen it.
Use could, but you don’t have to use software to decompile it.
TOS is irrelevant unless you have some kind of ongoing reliance on the vendor for that specific thing, like a warranty. They can put whatever they want in there (and often do) but it’s not binding.
I personally wouldn’t give a damn. Console companies intentionally impede users from running their own code on a device they own. I think it is always morally acceptable to circumvent such a restriction. Practically speaking the console companies proprietary code and documentation is essential for this, so I don’t see any moral issue in using it. As for RTEMS, they should just add that attribution.
Developers have to care because Nintendo will burn them alive if they can get a claw in.
Regarding RTEMS, yes, they need to, the fact that they didn’t is a problem for everyone who used it. That they are pretending they don’t need to is not a good sign.
You should know as much as anyone what’s moral and what’s legal frequently do not agree, and the legal side will crush you.
I see a lot of accusations but little conclusiveness.
You don’t get the original C code from decompiling; and while those tools have improved lately, they weren’t exactly perfection ever. At best you get something that’s “similar” to, maybe “functionally equivalent” on a good day; but does copyright extend to it? Unlikely in most instances.
There’s also an assumption here the RTEMS is whole cloth from a developer or team, and not itself derived from somewhere else. It’s entirely possible parts are boilerplate from design documents or processor manuals. If so, it’s not a violation to get it from the same place and therefor inherent its general structure and conventions.
Don’t know about the decompiling and extracting strings from debug symbols and copyright. I think that’s pretty grey-area.
But have a look at the RTEMS code if you want. Entire sections of code are way too similar to have not included a disclaimer, in my opinion. And given that attribution is free, why not?
As someone that has worked with RTEMS code for different platform in aerospace over the years, RTEMS and in particular Embedded Brains GmbH are particularly known offenders for just fetching code from BSPs and drivers and just plugging them in the codebase with NO ATTRIBUTION.
So in that regard it is very likely that that specific section of code might have been taken from somewhere else. If you ever peeked at a RTOS scheduler that dispatch code is so common it could be made into law.
Taking inspiration from the works of others but not really using them directly is something you can jump up and down and get angry about anything a human has ever created if you really want to. So while it does look like enough of the original is in there to notice the similarities I’d have to agree that I’m not sure it really counts from the cursory glance I’ve taken. Though as in academia its always a good idea to cite your references even when you are not using it that directly and thus at least acknowledge the clear inspiration…
Also really not convinced a reverse engineering is grounds for anything but perhaps a violation of some EULA type thing for person that did the work at worse. I think you would have a hard time legally suggesting that having bought hardware, potentially second hand too that any user or other developer upon the reverse engineered elements is at risk. But I’m no lawyer, its just very obvious that reverse engineering is exceptionally common even at for profit business that almost certainly do have at least one lawyer to tell them its a bad idea to lock to horns with a giant like the Big N and their almost bottomless warchest…
I’m trying super hard but it’s just not happening: I don’t care about this. “Similar variable names”? Is it possible the variable names are similar because they are well-formulated?
When the only substantial differences are slightly different names and whitespace, it looks an awful lot like copied homework.
hah i was hacking on one of my projects and remembered this article, and ‘you wouldn’t steal a font’
when i abandoned virtual consoles in favor of X11 circa 2003, i dumped the default boot-up vga font and turned it into an X11 font (.pcf). and i made a couple tools that i used with a lot of elbow grease to scale it up from an 8×16 font to a 12×24 and 16×24 font. and i still use that font for all my xterms today. and in my project, i have a .h file that i’m pretty sure is just that font scraped into a bitmap array initializer (char font[] = { 0x12, 0x34, … };).
so i can’t honestly say where this came from — was it in videocard RAM, motherboard BIOS RAM, is it a part of the kernel a debian package? the pedigree is well-and-truly obscured and it’s gone through both machine and manual translations / obfuscations. i’ve got the original 8×16 and my 12×24 derived work, with no attribution or description. and i’m sure i’ll cut and paste this again, no?
i like to think my program would have to become very very famous indeed before i met someone who cared
Do you have the file on your PC still? I wanna use it myself, upload it to a drive app please!
sorry for the delay… http://galexander.org/gregfonts.tgz
That’s a sad story. I feel like the Kernel guys have been holding back the flood of bad short-term choices for decades, but it’s been crumbling.
“I don’t want to look at your work and understand the history, I want my changes my way and if I can’t get it I’ll burn the place down.” In this case the guy took a walk and start a fire elsewhere.
But when “the guy” is big enough you get eBPF, and a ton of lost innovation that’ll never make it back into the project.
I don’t have the answer, but maybe the project, and its SME, could do with a future plan of consolidation and simplification (not microPython, Rust or C) to reduce the entry barrier.
We all use git now, perhaps they can cook up something that codes kernel.
“But when “the guy” is big enough you get eBPF, and a ton of lost innovation that’ll never make it back into the project.”
How to allow proprietary blobs in linux. This was already the case with the GPLv2 for kernel modules, a mess that prevents some of my routers to be upgrade to a more recent version of Linux. Bravo Linus for not defending freedom.
Note that in the latest update to the hbc README, I pointed out a section of libogc code that is 1:1, bytewise identical, comments and formatting, to a header file from the Nintendo SDK (that happens to be available on GitHub).
It wasn’t just “reverse engineering binaries”. Shagkur was copying prototypes, declarations, and even documentation directly from the Nintendo SDK.
Even if it were “just” reverse engineering, disassembling code and manually translating it to C (what shagkur did for the most part) is still creating a derivative work and copyright infringement. Manually copying RTEMS code and renaming all the identifiers slightly also is.
Reverse engineering itself might be legal in some jurisdictions, but you can’t just copy the resulting code. You can reverse engineer something, learn how the hardware works, and write your own code to drive it. That’s mostly legal (and the legally guaranteed way to do it is “clean room reverse engineering”, though that’s not required to make it legal). If you just translate the algorithms, structure, control flow, etc. of the original code 1:1, then that’s not just reverse engineering, it’s reverse engineering and then committing copyright infringement by distributing a derivative work.
Funny thing I just found out: I’m actually talking to a bunch of people who are interested in doing things right and starting up a new Wii homebrew toolchain without stolen code. The subject of executable formats came up, and the elf2dol tool in WinterMute’s devkitPPC toolchain popped up. I look at the code and it looked awfully familiar. It was committed with no copyright nor attribution.
I looked through my old Wii backups and found elf2dol, dated a few hours before WM’s first commit.
So I had written that tool and given it to him, and he had committed it to devkitPro without even acknowledging where it came from in the commit message. 🤡
Doing a clean reimplementation of the tools is a great goal. Handling the RTEMS issue should be quick and easy — fork, attribute, done?
The rest sounds like good old fashioned hard work. :) I hope you get a good group together to get it done!
Probably won’t be RTEMS at all (there’s no real reason to use that and not other platforms when you’re starting from scratch). The extent of taint in libogc makes it impractical to just “fork and fix”, you have to start from scratch. We’ll see how things go.
Isn’t RTEMS itself BSD licensed? Perhaps I’m missing something, but it seems like adding proper attribution would be sufficient. I don’t know why they haven’t done that from the start, rather than obfuscating the origins.
@Hari To add the proper attribution would require a full audit of both libogc and RTEMS code and that would be time consuming.
@Hari There is also the issue of stolen Nintendo code which makes the entire project radioactive.
Isn’t the entirety of the recomp projects just taking code and reversing it directly and that hasn’t heard a peep of opposition.
I don’t see how decompilations result in problematic code outside of jurisdictions that add excessive restrictions. As far as I can tell most countries have that level of reverse engineering as fully legal.
Those projects are openly copyright violations. The copyright holders have every right to take down those repos, and the projects just rely on their goodwill that they won’t.
There is no legal precedent that decomp/recomp stuff does not create a derivative work. At best you can allege fair use, but that is a US only legal concept and difficult to assert in this case.
The difference with decomp/recomp projects is that they are stand alone projects not intended to be used by third parties, and are open about what they’re doing. What libogc is doing is the equivalent of a recomp project that pretends to be 100% novel code to reimplement the game, instead of openly admitting to decompiling code, and also encourages other novel games to reuse the code under a FOSS license.
Nobody cares if you do dodgy copyright things in your own, personal projects. That is your prerogative. When you do dodgy copyright things, and present your work as being completely clean, and encourage others to use it, and put yourself into a position of being embedded into an entire community’s works, then we have a problem.
In other countries, there are similar laws called fair dealing too, but those projects mentioned are pretty much playing with fire.
Clean room was actually more than that: they were really friggin scared of IBM.
You don’t just read the code and reimplements it, you read the code, document the behavior, and someone else implements it based on the documentation. It’s because algorithms can’t be copyrighted, so if you just document the algorithm it can’t contain copyright.
On a tangential note, LIBOGC should probably not be written in upper case. If it has, then you definitely shouldn’t tilt your head to the left….
https://www.theregister.com/2008/04/22/ogc_logo/
Well, for those who don’t know, using LWP for threading as of libOGC might have worked for most cases in the past without any major problems. Reworking everything to make it match the original RTEMS threading code was up to this point “challenging”. While the current outcome works for porting games for homebrew, it won’t properly work for simple things like the HBC source code after rewriting parts of it to make it match / work (with) the pthread* API found within the RTEMS source code.
Even though, after creating the repo with all those commits over at GitHub, I just cannot believe what shagkur wrote in that picture shown here where he talked to WinterMute. It’s just unimaginable that he rewrote things line-by-line from the official RTEMS source code into “LWP” as of libOGC as that’s tons of code to rewrite compared to renaming everything and even clearing out whitespace etc.. Instead, it would be much easier to port over the code by copying, running, debugging and then using tools or a simple shell script to search the source code files used for libOGC’s LWP code for strings and rename the matches in a row. It’s much, much easier and faster doing it this way.
At the same time, “LWP” (libOGC’s threading code) was introduced some time between March of 2003 and August 2004 from what was seen after we found v01 and v02 of libOGC’s source code online which had the very first stages from users like Titanik from “Crazy Nation” in the GameCube days. That was before WinterMute and shagkur took over and started adding more and more code to libOGC.
Yet, when LWP was introduced, all the commits shagkur pushed don’t have any information. They only contain bare changes to the code.
I for myself tried to rework LWP into what RTEMS actually is to make it match MOST of the original threading code and I personally prefer to have it pretty clean there. Some of the code within LWP is even just not required at all like a dozen of calls to the Watchdog handler etc., others are completely wrong compared to the code found in RTEMS.
I’m still constantly working on something that does “convert” LWP >—back-to—> original RTEMS.
For that “GitHub repository maintained by a user known as derek57” mentioned in the article above, it was me.
I didn’t contact WinterMute about the whole situation with LWP as back then I already knew what would happen if I would have tried. The outcome is still the same: I’ve set up that repo by the start of 2024 with all those commits, the maintainers of devkitpro realized that it was there and they immediately blocked me from the devkitpro GitHub account for absoutely nothing. It would have been much easier to try to get into contact with me for them but talking to WinterMute is just a pain in the b*tt. Years have passed where this guy was and up to this day still is unable to have a simple conversation about problems users have with his tools. He simply can’t handle critics and is not even willing to make things any better. Instead, they get worse * and you can see the outcome right now for the current case.
the most recent change to the video code of libOGC partially breaks console output and no one even realized yet? Do they even TEST their changes to the code? I guess not… But that’s just an example of how bad their behavior really is.
For mardy’s (Alberto Mardegan’s) blog post, I feel bad for him because of trying to protect the devkitpro maintainers with nonsense.
Sincerely,
nitr8 a. k. a. derek57
…so what about the Asahi Linux code, is that one completely clean or are there also parts Hector Martin always knew were stolen from somewhere else but continued to use “reluctantly”? The whole episode certainly doesn’t inspire a lot of confidence.
The trainwreck of libogc is precisely why I wrote and enforced https://asahilinux.org/copyright/ , to make sure it would never happen again.
Also, it wasn’t just “me” reluctantly using the tainted code. These issues had been brought up in community spaces several times, by myself and others, and to many were an “open secret”. It was just too late and libogc had entrenched itself in the community by the time this all came out, and nobody knew what to do. I guess since then, and since this was never openly admitted by the libogc developers despite being told about it many times, people have forgotten about it. They just swept it under the carpet and correctly believed people would forget that they stole code.
After that fiasco, I vouched that I would never trust any code from reverse engineering circles without carefully vetting it myself first. And I caught some in the context of Asahi Linux too, e.g. openiBoot is also a “shagkured” version of iBoot and its existence is why the Asahi Linux policy explicitly warns against blindly taking code from iOS-related projects. libogc isn’t the only offender here.
if you’re trying to use apple hardware without apple software and you’re expecting not to violate any licenses then you’re suffering a dysfunction
Love the scared look to the GC ports whilst the Ovwahlord (Wario) paints on the console, the artist did such a fantastic job
https://www.rtems.org/news/2025-05-06-rtems-devkit-libogc-response/
Now they cannot deny it anymore
Wonder what will happen if you file an Issue with that link?