RTEMS Statement Deepens libogc License Controversy

Earlier this month we covered the brewing controversy over libogc, the community-developed C library that functions as the backbone for GameCube and Wii homebrew software. Questions about how much of …read more

May 14, 2025 - 20:26

RTEMS Statement Deepens libogc License Controversy

Earlier this month we covered the brewing controversy over libogc, the community-developed C library that functions as the backbone for GameCube and Wii homebrew software. Questions about how much of the library was based on leaked information from Nintendo had been circulating for decades, but the more recent accusations that libogc included code from other open source projects without proper attribution brought the debate to a head — ultimately leading Wii Homebrew Channel developer Hector Martin to archive the popular project and use its README as a central point to collect evidence against libogc and its developers.

At the time, most of the claims had to do with code being taken from the Real-Time Executive for Multiprocessor Systems (RTEMS) project. Martin and others in the community had performed their own investigations, and found some striking similarities between the two codebases. A developer familiar with both projects went so far as to say that as much as half the code in libogc was actually lifted from RTEMS and obfuscated so as to appear as original work.

While some of these claims included compelling evidence, they were still nothing more than accusations. For their part, the libogc team denied any wrongdoing. Contributors to the project explained that any resemblance between libogc code and that of either leaked Nintendo libraries or other open source projects was merely superficial, and the unavoidable result of developing for a constrained system such as a game console.

But that all changed on May 6th, when the RTEMS team released an official statement on the subject. It turns out that they had been following the situation for some time, and had conducted their own audit of the libogc code. Their determination was that not only had RTEMS code been used without attribution, but that it appeared at least some code had also been copied verbatim from the Linux kernel — making the license dispute (and its solution) far more complex.

Permissive vs Restrictive

At first glance, this all might seem like something of a non-issue. After all, libogc, RTEMS, and the Linux kernel are all open source projects. Surely, the point of releasing these projects as open source in the first place was to facilitate and even encourage the sharing of source code. In a sense, this could be looked at as the system working as intended.

Indeed, it’s not the reuse of code that’s really the issue here. The problem stems from the licenses by which the respective projects have made their source code available, and more specifically, how well those licenses integrate with each other.

When the complaint was that libogc was using large swaths of code from RTEMS, the path towards compliance was simple as latter project was released under what’s known as a permissive license, namely, the 2-Clause BSD License. As the name implies, permissive licenses such as this give the user broad rights on how they can reuse the code

For example, one could take BSD-licensed code, merge it as-is into a closed source project, and sell the resulting software for profit without violating the license. All the original project asks in return is that you give proper attribution. In this case, that means acknowledging you used code from said project in the documentation, and including a copy of the license.

Returning to libogc, the issue at hand could be resolved with a single commit to the project’s GitHub repository. A simple notice that the project used code from RTEMS and a copy of the BSD license is all it would take to satisfy the requirements. That the libogc developers will not make even such a simple concession in the face of overwhelming evidence that they did indeed reuse code is frankly indefensible; a sentiment expressed in the statement from the RTEMS developers:

RTEMS is open source and this means RTEMS can be copied and used as long as the license conditions are met and copyright is maintained. We are at a loss why there has been removal of license details and copyright and a general disregard to apply appropriate attributions. As a result the RTEMS license and copyright holders reserve their rights in relation to the copying of RTEMS code.

That being said, the revelation that libogc would appear to include code from the Linux kernel complicates matters considerably. Unlike RTEMS, Linux is licensed under the GPL v2 — a license that is not only far more restrictive, but viral in nature.

The Case for Kernel Code

It’s that viral aspect of the license that promises to give libogc the most trouble. If they did indeed use code from the Linux kernel, that would mean there are only two solutions. Either the offending code must be removed, or the entire project will need to be re-licensed under the GPL v2.

For a codebase as old as libogc, changing the license would be a massive undertaking, as every person who’s added code to the project would have to agree to have their individual contribution re-licensed. The libogc repository lists dozens of contributors, and that’s only since project was added to GitHub. As there appears to be no CREDITS file that lists the contributions before the advent of Git, there may be no way to know at this point how many contributors there actually are and what they added.

So the question of whether or not libogc uses Linux code is going to be critical to determining how the project moves forward. The RTEMS statement doesn’t go into great detail about this claim, simply stating that the “spinlock implementation is copied directly from Linux circa 2.4 or 2.6 release series.” Sure enough, when comparing the file spinlock.h file from the latest version of libogc to linux-2.6.0/include/asm-ppc/spinlock.h there are indeed functions which are nearly identical:

That said, this may not be as damning as it seems. To play Devil’s advocate, one could argue that the terse nature of assembly code means that a certain level of similarity is unavoidable between the two implementations. Of course, convention can only get you so far. It’s one thing to independently arrive at the same assembly code, but this explanation becomes harder to believe when you consider the identical variable names and comments.

What’s Next?

As of this writing, the libogc project has not made an official statement on the situation. We reached out to maintainer Dave [WinterMute] Murphy before going to press with this article, but he declined to comment, saying that he first needed to confer with the original developer of the library, Michael [shagkur] Wiedenbauer.

At the same time, our contacts within the RTEMS project have indicated they believe they have sufficient evidence to have libogc removed from GitHub if necessary. However, they’re understandingly hesitant to disrupt the Wii homebrew community over an issue that could ultimately be resolved with a simple discussion. While the potential use of Linux code does add a considerable wrinkle to the overall situation, if the libogc project would at least acknowledge the use of RTEMS code and properly attribute it after all these years, it would at least be a step in the right direction.

We’ll continue to keep an eye on the situation, and bring you updates as we have them. In the meantime, we think the final line of the RTEMS statement nicely summarizes the biggest takeaway from this whole mess:

Our goal now is to provide education on how the behavior engaged in by the devkitPro/libOGC project is a very good example of what not to do.