This repository was archived by the owner on Apr 30, 2025. It is now read-only.
2025-04-2716:18189158github.com
The Homebrew Channel - open source edition. Contribute to fail0verflow/hbc development by creating an account on GitHub.
Read the original article
Comments
I'm not a lawyer, but publicly announcing that you found out that you were using a library largely consisting of decompiled Nintendo SDK code, then continued to use it and distribute binaries with the library compiled into them seems inadvisable to me. On the other hand, the Wii's no longer commercially relevant so I doubt Nintendo will do anything about it either to him or to the DevKitPro project. Maybe that's why Marcan waited so long to go public about this. I'm also not sure why he thought copying code uncredited from a Nintendo SDK was good enough to "reluctantly continue to use the project" but copying code uncredited from a 25 year old release of an RTOS written by a defense contractor was a step too far. Different people have different moral standards I guess.
I will say that in general, the DevKitPro maintainers are very much on the "Cathedral" side of the spectrum and behave very abrasively, so the reaction Marcan lists doesn't surprise me. In general their licensing philosophy is "make it as easy as possible to write homebrew using the toolchain while making it as difficult as possible to fork/build your own copy of our toolchain". All of the console-side libraries are permissively licensed, while the tooling to build at least some of their libraries doesn't have a license file, is undocumented, and the maintainers ignore any requests for help from people who are trying to use it. DevKitPro is also extremely aggressive with enforcing their trademarks, to the point of issuing takedowns to people who are hosting unmodified old releases of the toolchain. Trying to sweep the libogc licensing issue under the rug (i.e. moving the issue about the licensing to a private repo instead of even just closing it) to try to keep the project Zlib licensed tracks with this behavior IMO.
Copyright laws (in sane countries) have (varying amounts of) exceptions for reverse engineering pieces that are required for compatibility/interoperability.
Whether this applies to the Nintendo SDK… no clue, ask your lawyer ;). (i.e.: was there an alternative option to using RE'd pieces of the Nintendo SDK?)
It makes sense from a perspective/perception of: with the Nintendo SDK, [if] there wasn't really a choice or an alternative. With the RTEMS code there was.
By giovannibajo1 2025-04-2723:562 reply Of course there was. You can clean-room reverse-engineer the hardware. This is what is done daily by Libdragon maintainers for supplying an open source SDK for Nintendo 64 with zero proprietary code in it.
way back in the before times... Open Source projects went to great lengths to make sure they didn't use anything that could 'taint' the code (eg Samba )
I think the DeCSS stuff wasn't used till it had been publicly leaked and was considered 'common knowlege' or some such to prevent lawsuits
By amiga386 2025-04-2812:36 Not quite. There was nobody holding back on sharing for legal reasons, and it didn't prevent lawsuits.
The LiViD mailing list was full of people trying to get DVDs working with Linux, and they were already quite far into it. Derek Fawcus had already written the drive authentication code (so the drive would allow the host to read most disc sectors).
A piracy group, DrinkOrDie, reverse engineered the Xing DVD player for Windows and released DoD DVD Speed Ripper (no source code).
MoRE (Masters of Reverse Engineering) also reverse engineered the Xing DVD player and released DeCSS (no source code).
MoRE consisted of "mdx", "the nomad" and Jon Lech Johansen. "the nomad" reverse engineered the Xing DVD player. "mdx" used them to write a decrypter. Jon made a GUI frontend.
Prior to DeCSS's release, someone sent Derek Fawcus the decryption code. And he got around to playing with it, and was going to publish it on the LiViD list.
But before he did, DeCSS came out, and also its source code leaked, and Fawcus noticed his own code was in it (the drive authentication code), stripped of his credit. He complained about this and Johansen got in touch, and ultimately he allowed DeCSS to use his code under a non-GPL license.
Then, famously, Norway's "economic crime" unit brought criminal charges against Johansen. Ultimately, they concluded that Johansen himself hadn't infringed anything, because it was Derek Fawcus, "the nomad" and "mdx" who did that, and they're not Norwegian.
So, with that in mind:
- the LiViD mailing list would almost certainly have developed a DVD solution for Linux, not caring about clean room implementation, if DeCSS had not beaten them to the punch
- the fame DeCSS got also brought the angry litigators (though eventually justice prevailed)
I'll end on a quote from Derek Fawcus:
https://web.archive.org/web/20001202051300/http://livid.on.o...
> Something that may be of interest to people in the states is that I've had an offer of help to produce a specification of the algorithm - from which a third party could produce an implementation. i.e. proper clean room approach. This doesn't really matter from my point of view (or in my opinion most Europeans) but may be of use to the Yanks.
By ranger_danger 2025-04-281:482 reply How could one ever prove that a solution was clean-room? For example I would consider the oman leak to taint all development of N64 in existence. Even if someone didn't personally look at it, they most certainly got information from someone else that did.
By giovannibajo1 2025-04-2813:44 I don’t understand if this question is legal or morale/technical. I will answer to the latter, from the point of view of a prospective user of the library that wants to make their own mind around this.
Its quite easy to prove that libdragon was fully clean roomed. There are thousands of proofs like the git history showing incremental evolution and discovery, the various hardware testsuites being developed in parallel to it, the Ares emulator also improving its accuracy as things are being discovered over the past 4-5 years. At the same time, the n64brew wiki has also evolved to provide a source of independently verified, trustable hardware details.
Plus there are tens of thousands of Discord log messages where development has incrementally happened.
This is completely different from eg romhack-related efforts like Nintendo microcode evolutions where the authors explicitly acknowledge to have used the leaks to study and understand the original commented source code.
Instead, libdragon microcode has evolved from scratch, as clearly visible from the git history, discovering things a bit at a time, writing fuzzy tests to observe corner case behaviors, down to even creating a custom RSP programming language.
I believe all of this will be apparent to anybody approaching the codebase and studying it.
Lawyers, discovery, and a courtroom. The reason clean room works out is due to various lawsuits on the topic as a matter of law.
The Wikipedia article on clean room reverse engineering has all the examples that came to my mind and then some. https://en.wikipedia.org/wiki/Clean-room_design
By braiamp 2025-04-283:49 > Lawyers, discovery, and a courtroom
In other words, money that these people don't have. The legal system is not a solution for these kinds of problems, nor it is affirmative defense. Anything that makes the defendant bear the burden of raising and proving that their actions didn't foul any legal requirement, is basically killing any project, even when using your "solution".
By ranger_danger 2025-04-282:441 reply To me this still means "there IS no way". You can get sued and convince a judge you didn't do it, sure, but that's not necessarily 100% accurate, and also probably extremely unlikely to happen anyway in most cases. And you'd be surprised how easy it is to fake evidence with no way to prove otherwise. Plus all that still requires going to court.
By timschmidt 2025-04-283:391 reply Generally one has two sets of developers, one doing the RE work, and one doing the new implementation, and the only way you allow them to communicate is through documentation of the reverse engineered implementation. Should this go to court, you can walk each member of each group in to testify, and show off the stacks of documentation produced in the process.
By ranger_danger 2025-04-294:152 reply That might convince a judge, sure, although it's still possible to fake the evidence... but I would argue the vast majority of people who claim to have clean-room RE'd something absolutely did not go through anything close to this process.
By timschmidt 2025-04-294:57 I don't know anything about the majority of developers, and I think sweeping claims about any group require strong evidence, which seems lacking. But there are plenty of examples of companies that followed such a process, and succeeded in court: https://en.wikipedia.org/wiki/Clean-room_design#Examples
By theshackleford 2025-04-297:081 reply > I would argue
With what evidence?
By ranger_danger 2025-04-2914:43 I think when someone fails to produce any evidence of a clean-room process being followed when they claim it's clean-room, is probably a good indicator. Yea you can call that "trust me bro" if you want, I won't be upset.
By selfhoster11 2025-04-283:27 > On the other hand, the Wii's no longer commercially relevant so I doubt Nintendo will do anything about it either to him or to the DevKitPro project.
They've been going after ROM sites. Going after libogc or Marcan would fit their recent MO.
I think it is really, really unwise to put libogc on blast like this. It draws Nintendo's attention, which is never good. It would be better to reach out privately, and tell them you'll publically call them out unless they add missing credit and/or remove the offending code. Which for all I know, might have been retired already.
To me this looks like a bad attempt at exposing dirty laundry in bad faith, which is not too surprising coming from him.
1. Commit 3ba50ec which Marcan is complaining about was pushed in 2008 and didn't just delete attrib specifically, but all (?) VCS comments indiscriminately. The file was barely touched since
2. "The authors of libogc didn't just steal proprietary Nintendo code (...) ignorance about the copyright implications of reverse engineering Nintendo binaries" ---> AFAIK it's software RE work, and nothing done in the console hacking scenes is truly cleanroom at all, and there's no point to it either as Nintendo can knock&talk and/or send strongly worded letters when they please, legality be damned
I don't know much about the Wii scene specifically, and libogc seems to be a mess in general, but what I do know is that libctru (3ds)/libnx (Switch) don't have that drama nor made the mistakes made in libogc
> AFAIK it's software RE work, and nothing done in the console hacking scenes is truly cleanroom at all
There's a wide gradient of how much effort people put into reverse engineering consoles in a legal way vs. just copying code straight from their decompiler and slapping an open source license on it. libogc is very much on the "didn't even try" side of that gradient, it's been known since pretty much forever, and even their documentation is straight up copied from Nintendo's SDKs for part of their libraries.
What's new here is discovering that even the parts people thought were developed "fresh" and not just straight-up asm2c'd from Nintendo are actually stolen from other open source projects in a way that tries to conceal the origin of the code.
Whether you'll find that "more morally reprehensible" or not will largely depend on your personal morals, but clearly for some people that seems to be the case...
By TuxSH 2025-04-2717:54 Yes, libogc is a dumpster fire and the dkP org would be better served by rewriting a libogc replacement (w/ a different API) from scratch, quite honestly.
What I find odd is the timing, I highly suspect he learned about it many months ago.
> There's a wide gradient of how much effort people put into reverse engineering consoles in a legal way vs. just copying code straight from their decompiler and slapping an open source license on it.
Agreed (I replied the same in another comment)
By JoshTriplett 2025-04-2717:44 > To me this looks like a bad attempt at exposing dirty laundry in bad faith, which is not too surprising coming from him.
It seems odd that you would complain about the messenger, here, since it seems you don't actually dispute the message.
> Commit 3ba50ec which Marcan is complaining about was pushed in 2008 and didn't just delete attrib specifically, but all (?) VCS comments indiscriminately.
So it's OK that they did something wrong because they did everything wrong?
> there's no point to it either as Nintendo can knock&talk and/or send strongly worded letters when they please, legality be damned
There's very much a point to it (when you're building an emulator or tooling, rather than e.g. romhacks where it's unavoidable), because if you carefully stay entirely above board, you can burn those strongly worded letters, make DMCA counter-notices, and otherwise rely on the fact that both emulation and reverse-engineering are legal.
By amiga386 2025-04-2812:43 Hector just doesn't have enough drama going on in his life after resigning (twice!) from the LKML, eh?
Nonetheless, I respect him for calling out FOSS license violations, even if he's done it in the most drama-pilled way.
> 1. Commit 3ba50ec which Marcan is complaining about was pushed in 2008 and didn't just delete attrib specifically, but all (?) VCS comments indiscriminately. The file was barely touched since
FWIW -- I think this is the commit being talked about: https://github.com/m87h/libogc/commit/3ba50ecd4134ef37a0f18f...
Looks honestly totally innocent ...
By scripturial 2025-04-2811:551 reply This by itself just looks to me like someone getting rid of the old CVS comments that are messing up the headers. Maybe the problem is that younger people don’t recognize what a cvs header is?
By amszmidt 2025-04-2812:08 Yeah entirely possible.
The threading code does seem to be "similar" enough to warrant some investigation, but from the looks no license notice was "removed". Even the threading code in question has never had one, from the initial import from CVS/Subversion.
Making a mountain out of a molehill .... before the molehill is even there?
By sunaookami 2025-04-2720:48 >I don't know much about the Wii scene
It shows. It's an open secret to everyone in the Wii scene that libogc is based on proprietary Nintendo code.
>but what I do know is that libctru (3ds)/libnx (Switch) don't have that drama nor made the mistakes made in libogc
Because WinterMute is not behind them.
By userbinator 2025-04-2720:101 reply which Marcan is complaining about
"That prick again?" Not surprised at all. He's been trying to stir shit up for a long time, and best ignored as a troll.
By userbinator 2025-04-286:33 Yes, for those who don't know, this prick has even tried to take on Linus, with the expected result: https://news.ycombinator.com/item?id=42978765
(Read the dead comments there - very enlightening.)
How extremely weird. Why didn't they just use RTEMS openly? Was it for clout or did they want to circumvent the GPLv2? I can't imagine the Wii Homebrew scene being commercially significant that it would matter.
I suspect that it was neither for clout nor circumvention, but ignorance and people doubling down on that ignorance. If you are not specifically bathed in the norms of the FOSS community, GPL is kind of an unintuitive concept. It's a copyright license that forces you to disclaim most of the benefits of copyright protection. If you're coming from a piracy or game modding scene, where copyright is a thing you wipe your ass with, even the bare minimum of GPL compliance is going to seem like a waste of time at best and someone else trying to butt in on your project at worst.
Think about how many pirates do piracy because they think copyright is unethical, versus how many of them are data hoarders, or just want shit for free, or are reselling shady IPTV boxes on eBay. The former two groups are FOSS-adjacent, but the latter two do not care. Then keep in mind how basically any free shit tends to be almost immediately abused by children with an Internet connection and no access to payment rails.
Homebrew scenes seem like a candidate for doing things "the right way", but culturally they're a lot closer to piracy scenes than anyone wants to admit, at least in front of a court.
By dokyun 2025-04-2720:11 That's what makes it come off as stupid and kneejerk to me. This guy wrote "The Wii homebrew community was all built on top of a pile of lies and copyright infringement" like it's some kind of shocking revelation. The guy writes it in a way that makes me think it's fueled by some years-long grudge rather than an intent to unravel some kind of conspiracy. It's kinda pathetic, really.
> Homebrew scenes seem like a candidate for doing things "the right way", but culturally they're a lot closer to piracy scenes than anyone wants to admit, at least in front of a court.
I realize the homebrew scene doesn't view themselves this way, but I pretty much view them as part of the piracy scene even when they are antagonistic towards those who pirate games. The main difference is that they are "pirating" hardware rather than software. By that I mean they are overriding DRM created by the hardware vendor to use the hardware in unauthorized ways.
Now it is easy to say that you should be able to do what you want with hardware you own. In most respects, I am sympathetic with that. Yet I don't like that philosophy for one big reason: it creates a huge disincentive to those who want to create open platforms since it is going to be nearly impossible for them to get any traction when they are up against jailbroken devices from huge multinational corporations.
By asiekierka 2025-04-2720:241 reply > it creates a huge disincentive to those who want to create open platforms since it is going to be nearly impossible for them to get any traction when they are up against jailbroken devices from huge multinational corporations.
I'm not so sure about that. More specifically, I wonder if there are more or fewer Steam Decks in the wild than jailbroken Nintendo Switch units.
By II2II 2025-04-280:08 When I was writing that, I was thinking of other platforms. For example: I had a GP2X at one point, which was a handheld console that ran Linux. It clearly wasn't a mass-market device, but it was an open platform with plenty of development tools. It should have been the sort of thing that appealed to homebrew developers. It was appealing for some, but it was up against the Nintendo DS with flash cartridges. There were almost certainly more flash cartridges than GP2X's in the world, even though they were a grey market item (at best). They didn't have a chance, and I think they only managed to produce one successor before going out of business. (Of course, there were other factors. This was right around the time of smartphones becoming popular. Smartphones may have crumby controls for gaming, but at least anyone could develop software for Android and the barrier to entry was relatively low for iOS.)
The Steam Deck, well, that has other things going for it. Yes, it is an open platform. Yet it, along with similar devices, are also PC compatible. That makes it appealing to developers, may they be developing games for Linux or Windows. Perhaps the biggest thing going for it is being backed by Valve, which is large enough to coexist with Nintendo and is unusual for a larger company in that they value an open ecosystem. To understand how unusual that is for a large player entering the market, just look at the original Xbox.
By frumplestlatz 2025-04-2720:24 I very much doubt that jailbreaking and the homebrew scene contribute significantly to the difficulty of building a financially viable open hardware platform.
Building a mass market hardware platform of any kind is incredibly difficult on its own merits.
By JoshTriplett 2025-04-2717:411 reply Note the mention that libogc also copies code from the official Nintendo SDK, which is proprietary.
I would guess one of three cases:
- They didn't want to respect the GPL, because they thought their library would be less popular if it were GPLed. (Many homebrew projects don't want to be fully Open Source because they want to hold back some special sauce, either to slow down efforts by the console vendor to stop them, or to differentiate themselves from other homebrew projects for clout. So someone building a foundational library for homebrew on a platform might want to, legitimately or otherwise, avoid presenting themselves as GPLed.)
- They didn't want to respect the GPL because they couldn't, because they were also pulling in proprietary code they weren't supposed to be using anyway.
- They didn't care because they were already ripping off the Nintendo SDK so why not rip off an Open Source project too. For instance, they just pointedly didn't care about copyright at all, which is a very different position than just not caring about code being proprietary.
(I can respect the position of "we're ignoring the copyright on this old game, so that we can do some awesome modding/romhacking", which is very different than ignoring Open Source licenses and failing to even give credit. I don't see the former as hypocrisy; it's just "we should be able to hack on anything". Console game modders / romhackers / etc tend to have a huge amount of respect for the original game and its authors, and give due credit, even if they're technically violating copyright.)
> Many homebrew projects don't want to be fully Open Source because they want to hold back some special sauce, either to slow down efforts by the console vendor to stop them, or to differentiate themselves from other homebrew projects for clout. So someone building a foundational library for homebrew on a platform might want to, legitimately or otherwise, avoid presenting themselves as GPLed.
For context, The Homebrew Channel itself was one of these projects. fail0verflow had put shittons of work into DRM for the Channel and its installer... purely so that you couldn't remove an anti-scam warning screen that they'd put in there to warn people about shady people trying to sell The Homebrew Channel.
Thing is, GPL requires you to explicitly allow that behavior[0], so HBC can't use GPL software.
[0] It is extraordinarily difficult to write a blanket copyright license that provides most of the terms we care for but prohibits this kind of behavior, without giving the authors the ability to veto anything they don't like. Standard operating procedure in the FOSS space has been to just allow all commercial activity.
By asiekierka 2025-04-2718:041 reply > Thing is, GPL requires you to explicitly allow that behavior, so HBC can't use GPL software.
Couldn't, not at the time. HBC has been open-sourced some time ago, sans DRM, as the Wii has long lost commercial relevance beyond enthusiast communities. This open-source re-release is what the repository is.
Also worth noting: the version of GPL used by RTEMS seems to be one with a compiler exception, so it probably wouldn't have been an issue for HBC.
By kmeisthax 2025-04-2722:39 Yes[0], and if Team Twiizers had consciously decided to use RTEMS code in that way, they probably would have been fine. However, libogc still cannot legally strip out the GPL copyright notices and distribute RTEMS code in that way.
That being said, RTEMS itself is trying to relicense to BSD 2-Clause, which would obviate the concerns over copyleft, but NOT the thing that libogc did. In fact, the 2 clauses left in the BSD 2-Clause license are the ones that require you to retain the copyright notices. So libogc is still in the wrong.
[0] https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/LICENS...
What was the nature of the stolen(infringed really) code? Because a naive first glance show that they were distributing source code from a project that requires that you distribute source code.... shrugs, what's the problem here?
So was it removing license comments from the files?
By qwery 2025-04-2720:05 It's plagiarism.
They laundered source code from a free software project in a deliberate attempt to deceive.
(allegedly, etc.)
By napierzaza 2025-04-2719:33 [dead]
