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 was halfway through this article when I noticed the formatting, and had to scroll back up to double-check I was still on HaD. This is the first HaD article I’ve noticed that doesn’t have the [] around names.
Yeah, right? Sometimes we don’t use ’em when everyone is under their real name.
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.
You gotta love how everyone blindly assumes in all of those discussions that source code is actually copyrightable in the first place, when the lawyers are doubtful about it, and there are multiple court rulings that decided otherwise at least in specific cases. Even if we think that some source code could be copyrightable, it’s not “illegal” until a judge says so.
Especially when there is only one obvious way to do something on a specific hardware, can that code really be considered creative and original?
This is what I’m wondering as well. If they had found out about this earlier, what would an alternative library have looked like? They should’ve given proper credit, that much is clear, but apart from that I’m struggling to imagine what significant difference there would’ve been in the end product.
It wasn’t copyrightable in the early days in the US.
Binaries and source are copyrightable: (1983)
https://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Franklin_Computer_Corp.
How to tell if more than just literal copying is infringing: (1992!)
https://en.wikipedia.org/wiki/Computer_Associates_International,_Inc._v._Altai,_Inc.
(I edited this to throw in the first link 11 hours after the first post.)
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.
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.
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.
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?
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
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.
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!
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.
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/