Are there any Wii homebrew loaders that aren't based on libogc?
One can easily find a bazillion of "github repos" that distribute what is evidently directly decompiled game code with minimal cleanup. Bonus points if they also claim it is OK as long as the game art is not distributed, which in addition to being wrong is disrespectful to developers as a whole.
But when the Nintendo copyright czar wakes up, they're the bad guys...
Note that e.g. copyright does not apply to decompiled source code (the original authors did not write the decompiled source, unlikely assets taken verbatim - maybe that's where the arguments you mention stem from - although note that there may be regional regulatory differences). Instead, the things that might cause issues are things like the enforceable parts of the software license, any enforceable patents on the functionality, or enforceable platform license restrictions for applications built based on decompiled source.
Where does this non-sense come from exactly? Are you claiming the decompiled source code is not a derivative work? It is almost a text-book definition of one (in much the same way the executable is...).
There are some situations (and this depends on your legislation) in which _violating_ copyright is lawful (e.g. in the EU, if it is _strictly necessary_ to do so for interoperability reasons -- think cryptography for network equipment; a decade ago I used to work on this!). But blanket distribution of decompiled proprietary (or GPL'd!) binaries _is_ a copyright violation (literally textbook, as "decompilation" is quite an example of an automated translation). And frankly, I have no idea what kind of confusion of ideas makes these people believe it is OK to distribute game code publicly. Or why it would be OK for code but not for assets. (And it has nothing to do with patents).
This is absolutely not true. I've been seeing this claim for years, and it's complete nonsense. Otherwise I'd be able to decompile the entirety of Microsoft Windows and then just redistribute it as my own source code.
> the original authors did not write the decompiled source
The original authors also did not write the compiled binary. The copyright still applies to it.
This isn't anything new or unique to programming. In the same way if I were to transcribe a movie (let's say it's a silent movie) to a script, it would still be that movie. Or if I were to translate a book into Klingon . Or even do a cover song of "Beat It" entirely with throat singing. Copyright would still apply.
bad example, in this specific case copyright would actually not apply
> The object code of a program may be copyrighted as expression, 17 U.S.C. § 102(a), but it also contains ideas and performs functions that are not entitled to copyright protection. See 17 U.S.C. § 102(b).
> Object code cannot, however, be read by humans.
> The unprotected ideas and functions of the code therefore are frequently undiscoverable in the absence of investigation and translation that may require copying the copyrighted material.
> We conclude that, under the facts of this case and our precedent, Connectix's intermediate copying and use of Sony's copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony's software.
Not only are the methods of operation which underlie the code completely unprotected by copyright, the copying of and the application of tools to the code for the purpose of exercising your right to discover those unprotected elements is fair use.
However, reverse engineering is allowed explicitly (...in several countries, ask a local lawyer!) for the purpose of interoperability, and sometimes for certain kinds of research. In those cases, what would otherwise be cooyright infringement is permitted.
If you're not doing it for those reasons (e.g. to attain exacting bug-for-bug levels of compatibility with a proprietary system, as is often needed in emulators), if in fact you could use any threading library, you don't then get to take an unrelated library and file the serial numbers off.
In Nintendo console hacking scenes? None at all, there is no point to it, going through the hassle of doing cleanroom as an individual is wasted effort.
Though, the spectrum between copy-pasting HexRays output verbatim and rewriting things yourself is fairly large.
I'm sorry, this is supposed to be a bad thing?
I did mine clean room. When I reverse engineered my laptop's features, I intercepted the proprietary software's communications with the hardware, compiled my findings into a whole bunch of notes and then wrote my own free software to do the same thing based on those notes.
> But when the Nintendo copyright czar wakes up, they're the bad guys...
They are always the bad guys. Copyright owners are monopolists. Copyright as a whole should be abolished. I don't care what the so called "pirates" are doing, they are always less morally wrong than eternal copyright monopolists who rob us of our public domain rights and turn perfectly good computers into locked down digital fiefdoms where we are serfs.
20 year old games you grew up with? Give me a break. These companies have all made their fortunes multiple times over. This "intellectual property" should already be in the public domain by all reasonable accounts. God forbid Nintendo be unable to sell you the exact same Mario ROM for the 10th time though. We're all going to be long dead before our culture returns to us. That means it effectively never will.
LibOGC accepts donations via Patreon, which means -- if the allegations are true -- they're profiting off stolen code. RTEMS could and should sue for damages.
This isn't the first time I've seen an open source project stolen by someone trying to pass it off as their own work while accepting Patreon donations. I'd like to see some justice every now and then...
How much they profit off the stolen portion is also questionable, and open source licenses weren't meant to extort money but to grant us rights to the code. What they should do is add attributions and fix their licensing (libogc needs to be GPLv2), or remove the code. Willingly, yesterday.
Considering attribution was removed, I doubt it was approved, but it's not impossible that they somehow learnt and decided not to care as enforcement can be unreasonably cumbersome.
But I disagree. It's not extorting money to sue someone who stole your code and deliberately removed your copyright notices. The open source license only gives you the right to use the work for commercial purposes AS LONG AS you comply with the terms of the license. If you don't, then you're illegally profiting off stolen work. You can't violate the terms of a contract while still benefiting from it.
I don't know how much was stolen here, but if it's foundational enough to the project that HBC had to give up development, then they might have a case, but IANAL. Not doing anything though would mean letting them get away with their ill-gotten gains (again - if true), and I just don't think that's right. Like I said, I've seen similar things happen before and it pisses me off.
HBC has not been under real development for 10+ years. This is mostly a performative act.
The principles acknowledge that copyright allows GPL violators to be sued for financial damages, as you point out in your post. However, they also take into account that lawsuits don't necessarily further the goals of software freedom, because excessive litigation could disincentivize people from using free software out of fear of mistakenly falling into non-compliance. As a result, it's better for free software to give violators many chances to comply and to provide guidance towards this where possible, and also seek injunctions rather than financial remedies if the court with jurisdiction allows it.
The principles are well worth a read; they explain a lot about how organizations such as the Software Freedom Conservancy operate, and why the few lawsuits which they do bring are so weird.
It's also worth noting that these principles are sometimes considered extreme within the free software community from the other side, which argues that the GPL should never be litigated!
But I suppose forums/Internet can be grumpy about other's amazement.
Litigation is expensive.
Yeah, hobbies can be expensive and sure litigation could be someone’s hobby…nothing wrong with that and maybe worth having lawyers on retainer if that’s your jam.
But in this case, there’s probably not a business case…and being a civil matter, there’s no book-‘em Danoh book to throw. Just normal squeezing blood from turnips…which again, might be someone’s hobby at least in theory.
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.)
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.
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.
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...
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.
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.
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.
Building a mass market hardware platform of any kind is incredibly difficult on its own merits.
So was it removing license comments from the files?
They laundered source code from a free software project in a deliberate attempt to deceive.
(allegedly, etc.)
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
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.
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...
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)
"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.
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.
Let's ignore for the moment nothing was actually stolen since the original authors still have their copies.
Stolen valor isn't really literal theft either, but that doesn't mean it's okay to do it.
>The current developers of libogc are not interested in tracking this issue, finding a solution, nor informing the community of the problematic copyright status of the project. When we filed an issue about it, they immediately closed it, replied with verbal abuse, and then completely deleted it from public view.
>For this reason, we consider it impossible to legally and legitimately compile this software at this point, and cannot encourage any further development.
>fail0verflow.com: "when success just isn't an option"
? There isn't really any evidence that the original RTEMS developers are aware of this situation.
> You don't need permission to use open source code..
"Open source" on its own is just industry jargon. When you use open source code, you are copying it in accordance with an open source copyright license. The copyright license contains certain stipulations around how it is allowed to be used. For example, BSD licenses require that the copyright notice is included when using the code. IANAL but my understanding is if you omit this information even though your work is a derivative work of the original you're in violation of the copyright license.
> So there appears to be two double standards occurring at once.
You should really elaborate who is being held to what standards because I can't make sense of this.
Lawsuits are very expensive for all parties no matter what, there is clearly no intent to try to engage legal action. That has nothing to do with anything. They're trying to distance themselves from illicit behavior, including the behavior they already knew about and let slide in 2007.
(And I doubt it's being done for legal reasons, but distancing yourself from illicit behavior does matter; take a look at what happened with Citra. The case partially hinged on their responses to piracy.)
> It can be easily corrected by including these license files. Therefore nothing is blocking either project.
Tell that to the libogc developers who seem to only be interested in burying the problem rather than trying to rectify it in any way.
If you wanted to fork it and continue development you certainly could.
> Can someone explain what harm is being done by an open source non-commercial project "stealing" code? Who is actually hurt by this, and how?
It's an accusation of plagiarism. Do you not understand why plagiarism causes harm?
Regardless of whether there's any truth to this anonymous accusation, this doesn't seem like the right way to go about it. An article walking through some of the similarities would be much more helpful to prove the point (and probably less work for whoever went through this exercise).
At least provide some links to RTEMS code comparing the libogc code. The OP cites these (https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103... and https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc...), but that's hardly a smoking gun. The function is trivial, just filling in some struct fields. The logic for choosing the stack size is the same, but it's also trivial and I'd just as likely attribute it to the function interface.
I'm not saying it isn't true, I just find this to not be the most credible accusation I've seen. This feels like some opensource drama thing, and the readme doesn't help, being both lacking information and including lines like:
> How disgusting...
EDIT:
also, they have another serious accusation without ANY proof:
> we discovered that large portions of libogc were stolen directly from the Nintendo SDK or games using the Nintendo SDK (decompiled and cleaned up).
Whether it's really worth all of the hooplah or not is going to be up to taste. I think it's pointless to just not explicitly credit RTEMS personally, but I suspect the real point of doing this is probably in large parts just to distance themselves from the reverse engineered libogc code.
I was referring to this repo by github account "derek57": https://github.com/derek57/libogc
I assume it's anonymous because the account has no public contact info.
Yeah, I'm with Marcan 90% of the time, and in my view Marcan is more likely than not right that that function is derived from the RTEMS function, but in my view there's still reasonable doubt. That is to say, purely based on the evidence linked, I only agree that it's probable that the code is copied and disagree with Marcan's claim that it's "not possible" for the implementation to be non-infringing.
The fact that some of the identifiers are similar raises the biggest suspicions. "__lwp_stack_isenough" vs. "_Stack_Is_enough" is suspicious because I'd probably call that "sufficient_stack_available" or something like that. "LWP_STATES_DORMANT" vs. "STATES_DORMANT" is also suspicious because the normal OS term would be "sleeping". Still, the function logic is different enough that, even with that evidence, one could plausibly claim that only the headers or interface were copied and the implementation was clean-room, which is non-infringing per Oracle v. Google.
In US legal system terms, I'd say that a preponderance of the evidence shows that the code is a derivative work (i.e. it's more likely than not that the code was copied at some point), but that there's still reasonable doubt (i.e. a reasonable person could plausibly believe otherwise).
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.
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.
mouse_•6h ago
devkitpro needs to be shamed for knowingly shipping stolen code!