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.
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.
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.
can I buy the game and do NOT agree to TOS?
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/
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
Sounds like “someone”(cough,cough) is just trin’ to make a splash
in the pond. It was 20 YEARS ago……dang dude, Let It Go.
…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.