This isn't passing the sniff test. I think Marcan is just trolling.
Goes right in line with his behaviour in the kernel rust saga. Conclusions are up to the reader.
Effiectively its 12-19 years old now, for me, while I understand it also kinda falls under "who cares" because homebrew always was always somewhat equal to piracy.
FWIW the price performance ratio of older consoles was better than what you get today. It was impossible to find a high definition video player for under $1000, except for the Xbox. People were more motivated to do real, non-piracy homebrew.
Today, you can buy a raspberry pie for $40. I think that must have something to do with the fading of homebrew.
Gimmicks and ease-of-hacking also matter IMO.
With the Switch, I believe we are seeing the "threat model" (from Nintendo's PoV) shift from on-device hacking to emulation, which is far more scalable and resilient to vuln fixes (system only needs to be hacked "once" to get crypto secrets and to dump code). This enables large-scale piracy and high financial stakes, see the ToTK debacle.
On the other hand, there's no (?) handheld system with 3D like the 3DS; and playing DS/3DS games on emulator feels a bit awkward.
The only thing I'm using my hacked Switch 1 is to dump/restore save files. Thanks to cloud saves and local save transfer, my other Switch units don't need to be hacked.
Unfortunately for Nintendo, reverse-engineering a console to run code the first party has not authorized is not actually a violation of any law. Nintendo surely was grumpy at them, but they had no leg to stand on.
[1] And still does, see their takedown of yuzu, who was openly allowing and encouraging Switch piracy in the Discord server.
I can't speak for everyone but personally I find there's a moral imperative in making sure that we can actually own the devices we buy. Comments and sentiments like these needlessly devalue the work being done to achieve this, and is part of why the broader homebrew community is bitter about it.
I want to caution also that the claims here about violating Nintendo copyrights have been known for some time, that part is not new. The open-source plagiarism is the new part and the most upsetting.
https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc...
https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103...
Multiple functions in that file are near identical.
The original code this was copied from was open source; why not "just" say "oops we are sorry" and add the attribution?
Licensing issues? But the repo in OP is also GPL?
https://mas.to/@davejmurphy/114414723608693881
There's a legal and moral implication. Legally, saying that you took someone else's code as "source of information" would probably be seen as copyright infringement. Morally, I must say I find it difficult to get worked up about it. How to write a basic OS with a threading implementation shouldn't be rocket science for anyone with a good CS background (yes, I'm aware RTEMS was literally written for rockets, but still). Yes, he took a shortcut here by looking at an existing project, and if this was a commercial project, I might see why one could get angry. However, I also can't really understand why they simply refuse to give credit to the original project and maybe also change the license to GPLv2.
Not necessarily. There are ways to work around that, for example white box reverse-engineering[1]. Also there are exemptions for some use cases, like interoperability. I'm sure a lawyer could figure something out, but it looks like they didn't consult any, and didn't follow a rigorous process.
[1] https://ospo.co/blog/modern-reverse-engineering/ - a random link I found by googling, but presents the idea well.
> maybe also change the license to GPLv2
Without a CLA, that's not doable without the approval of all the contributors.
Furthermore, the point of these libraries (libogc, libctru, etc.) are to be a FOSS SDK. Non-permissive license like GPL aren't really an option in this situation.
If I'm not mistaken, RTEMS has been relicensed to BSD-2; even if the licenses were incompatible at the time, they don't seem to be anymore.
Three things:
- libogc is BSD 3-clause[1], which is GPL-compatible[2][3]. That means that while you can't just strip off the existing BSD license, you can distribute a combination of source code that is BSD and GPL licensed, it just has to be distributed under the terms of the GPL, which is fully compatible with the terms of a BSD license, too, since all BSD licenses require is maintaining the copyright notice/disclaimer, and nothing about that requirement conflicts with the GPL. (IANAL, so take with a grain of salt, but I'm pretty positive on this one.)
- Although RTEMS is traditionally GPL, it's actually a modified version of GPL with the GNAT exception[4]. A compiler exception effectively allows users to link the object files into software of any license without invoking the copyleft provisions, so to my understanding this would basically be identical except for people who are modifying the source code of libogc (I imagine this is exceedingly rare.)
- And finally, RTEMS has been re-licensing to BSD 2-clause for a long time[5], so it's very possible all of the relevant code is now available under a BSD license with effectively equivalent permissiveness.
So actually I think this situation is probably much a nothingburger in that regard...
[1]: https://github.com/devkitPro/libogc/blob/master/libogc_licen...
[2]: https://www.gnu.org/licenses/license-list.en.html#ModifiedBS...
[3]: https://en.wikipedia.org/wiki/License_compatibility
[4]: https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/LICENS...
[5]: https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/LICENS...
deng•9mo ago
smcin•9mo ago
dharmab•9mo ago
devixluvic•9mo ago
smcin•9mo ago