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.
Relicensing libogc from permissive license to GPL shouldn’t be that much of a trouble. It may be more difficult for projects depending on it.
The similarity to linux 2.4.10 spinlock.h is almost 100%. And because the spinlock type signatures are linux-specific, it is unlikely that code is from any other source.
“Relicensing libogc from permissive license to GPL shouldn’t be that much of a trouble.”
Uh… there’s no guarantee it’s even possible? You literally have to get permission from everyone who contributed. They gave the code initially under the original license, you can’t just decide as a non-entity ‘group’ of active users to change it.
Way better off finding replacements for infringing files that can be compatibly-licensed. Still a mess.
Between the lack of contributor history that would make re-licensing all but impossible and the potential that there’s even more “borrowed” code hiding (be it from Nintendo or other open source projects), it may well be that libogc is tainted beyond the point of repair.
At the same time, I don’t know that there’s the will out there to create a new library for the Wii (let alone the GameCube). Can’t say I’m overly optimistic that this story has a happy ending for the community.
Stole the code
came here to say this. it’s likely that most of the codebase could remain dual-licenced GPLv2 and libogc-licence, while the bits from linux and perhaps the stuff closely tied to it could be GPLv2-only.
“relicencing” is kind a misnomer, as you CANNOT remove the licence terms someone committed code under. ever. if they’re permissive enough though, you could distribute it under another licence as well, like the GPL. plenty of code in the linux code us under a mix of licences in addition to the GPLv2.
You absolutely can remove the license terms someone committed coder under, if they individually agree to do so. If you cannot get in touch with a particular contributor or they refuse, you remove their code, which can admittedly be an un-fun thing to have to do.
But this hand-wringing about how relicensing libogc would be too onerous given “dozens” of contributors and the lack of an explicit
CREDITSfile is patently ridiculous.MAME existed as a project for 18 years and had hundreds of contributors by the time it was decided, in 2015, that the project needed a more permissive license. During those 18 years, it was released under a semi-custom license which purported to prohibit commercial use of the codebase.
After realizing that this did not deter bootleggers, and merely prohibited good-faith organizations from using its code, there was a concerted push to locate, contact, and solicit permission from every single person who had ever contributed code to the project. This was achieved through a combination of SVN and Git logs as well as release notes dating back across that entire time.
Ultimately, all but two individuals were able to be contacted, and everyone who was able to be contacted understood reason, and agreed to relicense under either 3-clause BSD, GPLv2, or LGPLv2+.
Point blank, if the libogc team wanted to relicense, they could, but they won’t, as it wouldn’t play well with [WinterMute]’s desire to portray themself and the rest of the libogc team as poor, set-upon victims.
the spinlock code is apparently dead weight according to someone tasked with an audit, and can be removed, issue for existing releases might be a problem if it was linked into a binary, although assuming it wasn’t actually used, that can be fixed by a bit of ELF surgery to remove the unused assembly objects
The way things are becoming, it would be tempting to release open projects under a “pirate” license. You know, “you can steal this code however you want whatever, but trying to copywrite it or re-license it results in futility because we or anyone else will steal it again”. And make it viral too: anything it’s attached to or incorporated in is also fair game. If only that were possible…
Open source is already being stolen/gutted by large corporations, and infighting like licensing compatibilities will hasten its death.
You can’t apply any terms to code that isn’t copyrighted. A creative lawyer could say that, since you’re saying people can’t apply copyright to the code, if that includes yourself as well you disclaim all copyrights to the code and thus cannot enforce any terms on anyone else at all.
Says who?
Nice try diddy…
Code is copyrighted automatically, by virtue of having been written. You don’t have to file anything. That lawyer would be lying.
a) this is jurisdiction specific
b) most countries (probably not all, IDK) have default protection for creative work. That default is that all creative work (code is that) is automatically protected to full extent meaning if you don’t grant explicit rights to others, by for example attaching a license, than others simply have no rights. This means that if you find some code on the internet without a license and without any other explicit statement from the author about what is allowed, you simply can’t use that code (or any other creative work). That is why it is so important to always attach a license to the code you publish on the internet if you want it to be useful to others.
Also there is this deep rabbit hole with public domain concept and problems it creates if specified explicitly. TLDR; Always use a license.
What you are describing is, effectively, a “copyleft” license.
They are not uncommon in open source already.
The major “drawback” is that if you use a copyleft license, there is roughly zero chance your stuff will be used commercially
Isn’t that basically what GPL and other copy-left licenses are?
Modify, view, and redistribute all you want, just don’t put your modifications behind closed doors?
My question is, how long until Hackaday gets a takedown notice for the cover art. It’s a cool illustration from a clearly talented artist, but Nintendo is notoriously litigious. That and Nintendo likes to shut down even the discussions around homebrew software.
The cover art is clearly within the Fair Use doctrine “that allows the limited use of copyrighted material without permission for specific purposes like criticism, comment, news reporting, teaching, scholarship, or research”.
Fair use protections only apply to individuals and organizations that can afford to defend themselves in court.
Being in the right doesn’t matter — most people can’t survive the process of being sued, so to change your behavior an organization like Nintendo doesn’t have to threaten to win a lawsuit, they just have to threaten to bring one.
Literally, LITERALLY everyone involved in this weird internecine tussle has the same goal: to unlock the power of computing hardware for the people who want to use it. Putting that goal at risk in the service of intellectual property protection is as absurd as it is graceless.
Except nintendo. :P
But if you thing this is insane, you should see all the times people have gotten their underwear in a twist over copyleft licences that are mutually incompatible but try to achieve the same goals. The original MPL licence(s) come to mind, as well as a well known example involving a certain licence derived from it.
We are speaking of Linux code here, there aren’t any stuff called comment in that code. And the variable name are 2 letters long. Hard to justify copyright infringement if you choose to call your iterator “i” or your read write lock “rw”.
Anybody have a PPC developers manual around? Decent chance half the code is directly from such a manual.
If the manual outlines how to do various types of locking and provided a substantial sequence of the machine instructions the chances of the code being otherwise copyrightable by anyone else is negligible. And it wouldn’t be particularly unusual since proper locking protocols require very specific instructions and sequencing, usually provided by the manufacturer who designed the CPU.
(This also makes it particularly difficult to be under copyright. If there’s really only 1 correct way to do it, and only a few ways to express it, the copyrightability of that code goes down significantly.)
Do I think the project was sloppy ? Absolutely.
Maybe ChatGPT wrote it?
When software was determined to be covered under copyright law with the status of literary works while avoiding the doctrine of first sale I laughed and thought it wouldn’t last a year……Now here we are.
Who was that guy who made a generative algorithm that basically wrote a very veeery long melody which included essentially all imaginable combinations of tones, then released it to public domain so that people couldn’t sue each other over riffs or hooks or melodies any longer?
I wonder what the limits of such a technique are. Obviously a lot of processing and memory is involved. Would you be able to do it to a programming language? If not, how much better hardware do we need before we can?
Unfortunately, that technique doesn’t work for copyright, for several reasons. Copyright applies to creative works, and it protects how the work was intended to be used. A list of every possible combination of notes is not creative; it’s exhaustive. The organization of how all of the pieces of that omni-melody fit together could maybe have qualified, but the individual pieces don’t establish prior art. This means it doesn’t do anything to make future melodies uncopyrightable. What that project did was to draw attention to the absurdity of the situation with lawsuits like the “Flame” melody as social commentary.
So pointless. All this over software self-styled hack software. Its unofficial software putting hardware to use outside the manufacturers wishes. Nintendo being infamaous for their general dislike of this kind of thing in the first place. Yet people have some expectation that they are going to be aware and care about some FOSS licenses which are rarely enfoced?
Also people are going to have a royal fit over whats coming with the now years of ‘vibe coding’ being practiced. Trying to pretend that FOSS software will be able to police that avalanche is foolish. It comes down to the same thing it always has.. if you want to make FOSS software .. make it and stop worrying about trying to control whats done with it because you can’t. If you want to control it, keep it closed source and keep that source secure.
i wish the mods would tell us why so many iterations of this sort of comment has been deleted on this article. i don’t care about free speech but i want to understand what’s going on here. it looks like a conscious choice to censor speech by content, as if we are not allowed to admit verbally that license violation is a part of life. is that really what’s happening???
or is a third party able to achieve that effect on here by reporting comments?
it’s just helpful to the community to know the rules