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.
> 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...
> 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.
> 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
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.
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.)
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?
Is RTEMS an active project? They should file a copyright complaint and have the libogc repo taken down if this is true. If it were me, I'd lawyer up and throw the book at them.
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...
Being active doesn't matter, the copyright holders still hold the copyright.
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.
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.
How much "reverse engineering" these days really is clean room and how much of it is just ripping off proprietary software?
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...
> The Wii homebrew community was all built on top of a pile of lies and copyright infringement
I think you can find evidence that basically all emulation since at least the N64 has been based on stolen SDKs and massive amounts of drama and infighting between overly-passionate groups of people.
Not to mention almost every single emulator developer pirates massive amounts of ROMs in order to test and debug games with their code. Many of them also have troves of proprietary SDKs as well.
i dont know of wii homebrew but in the nds space there is BlocksDS which is not part of devkitpro, and in gba space you can get (experimental) toolchains from wf-pacman (wonderful toolchain). sadly, the nintendo homebrew space is ruled by devkitpro, and i spent some time trying to find an alternative to it, but that doesnt seem to exist right now.
just realized you asked for something different, and my comment above is on the wrong subject. either way, i dont know of any big library/toolchain/sdk for the wii not from dkP, so the chances of a loader different from hbc and not based on libogc are small, sadly.
It's curious that the infractions were known about for so long—decades—but didn't make the news. I guess something happened to cause Marcin to speak up about it in 2025. But what?
This is a strange accusation. The repo linked as proof (https://github.com/derek57/libogc) consists of over 100 commits meticulously converting the libogc codebase to look more like the RTEMS codebase, and claiming that's enough proof that it's the same codebase. I wonder if it'd even build, or if those changes didn't break anything?
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).
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).
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).
FWIW, whether you agree with the accusation or not, it isn't anonymous. The commit history makes it obvious that it's marcan (Hector Martin) making the accusations.
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'm not an expert in embedded systems, but I do work on them at a very low level, and I can't be sure 100% of my code would differential from the RTEMS code base any more than libogs's. That doesn't mean they didn't do it - but the concepts behind Real Time Operating Systems in general are well known, and nearly standardized.
Isn't this like almost 20 years of history down the drain, including the project that gave marcan notability? Quite an event to transpire. It's crazy that millions of us looked at projects like THC as being acts of brilliance, not merely theft. There cleary were brilliant people involved in the project (segher who helped reverse engineer the NES/SNES/N64 CIC for example) so I don't doubt they're not capable.
sorry if this is an unpopular opinion, but i have absolutely zero problems with them reverse-engineering nintendo code, nor do i really care that much about GPL violations against a project called "Real-Time Executive for Missile Systems"
The power of a legal obligation like the GPL lies in its ability to bind equally people you like and people you don't; and in contrast to popular belief, social attitudes (like yours) do influence the courtrooms' disposition towards such laws—they certainly influence the lawmakers passing amendments and clarifications.
If we, the relevant community, do not think much of GPL violations when they hurt people we dislike, the social foundation that gives power to the law goes away.
Since y'all decided to flag my other comment I'll rephrase: 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?
Let's ignore for the moment nothing was actually stolen since the original authors still have their copies.
Call it what you want, but it's just disrespectful and unnecessary. I'm sure we've all fucked up somewhere and didn't attribute something correctly, but I feel like once it's been brought to your attention, it's just silly to not at least acknowledge it (especially if people are paying you to work on it). In this case, it's a somewhat serious licensing issue even if it is unlikely to lead to any actual legal action.
Stolen valor isn't really literal theft either, but that doesn't mean it's okay to do it.
You have a great point. I'm finding it hard to determine that actual harm has occurred here. The problem can be corrected, and the hbc project can still meet the requirements and spirit of open source. But neither fail0verflow nor libogc seem to care about any of this, and instead everything was frozen. You don't need permission to use open source code.. So there appears to be two double standards occurring at once. This story is weird.
>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"
In my opinion with how much Nintendo likes to sue this is about getting ahead of the situation and covering their backside of Nintendo wakes up and throw their lawyers at them
[+] [-] ndiddy|11 months ago|reply
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.
[+] [-] eqvinox|11 months ago|reply
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.
[+] [-] selfhoster11|11 months ago|reply
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.
[+] [-] TuxSH|11 months ago|reply
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
[+] [-] delroth|11 months ago|reply
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...
[+] [-] JoshTriplett|11 months ago|reply
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.
[+] [-] amiga386|11 months ago|reply
Nonetheless, I respect him for calling out FOSS license violations, even if he's done it in the most drama-pilled way.
[+] [-] amszmidt|11 months ago|reply
FWIW -- I think this is the commit being talked about: https://github.com/m87h/libogc/commit/3ba50ecd4134ef37a0f18f...
Looks honestly totally innocent ...
[+] [-] sunaookami|11 months ago|reply
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.
[+] [-] userbinator|11 months ago|reply
"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.
[+] [-] deng|11 months ago|reply
[+] [-] kmeisthax|11 months ago|reply
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.
[+] [-] JoshTriplett|11 months ago|reply
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.)
[+] [-] somat|11 months ago|reply
So was it removing license comments from the files?
[+] [-] napierzaza|11 months ago|reply
[deleted]
[+] [-] mubou|11 months ago|reply
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...
[+] [-] arghwhat|11 months ago|reply
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.
[+] [-] inamberclad|11 months ago|reply
[+] [-] brudgers|11 months ago|reply
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.
[+] [-] AshamedCaptain|11 months ago|reply
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...
[+] [-] ranger_danger|11 months ago|reply
I think you can find evidence that basically all emulation since at least the N64 has been based on stolen SDKs and massive amounts of drama and infighting between overly-passionate groups of people.
Not to mention almost every single emulator developer pirates massive amounts of ROMs in order to test and debug games with their code. Many of them also have troves of proprietary SDKs as well.
[+] [-] JoshTriplett|11 months ago|reply
Are there any Wii homebrew loaders that aren't based on libogc?
[+] [-] MelodyUwU|11 months ago|reply
[+] [-] MelodyUwU|11 months ago|reply
[+] [-] msephton|11 months ago|reply
[+] [-] Starlevel004|11 months ago|reply
[+] [-] bogwog|11 months ago|reply
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).
[+] [-] pcwalton|11 months ago|reply
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).
[+] [-] jchw|11 months ago|reply
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.
[+] [-] EdwardKrayer|11 months ago|reply
[+] [-] athrowaway3z|11 months ago|reply
[+] [-] unknown|11 months ago|reply
[deleted]
[+] [-] noobermin|11 months ago|reply
[+] [-] mouse_|11 months ago|reply
devkitpro needs to be shamed for knowingly shipping stolen code!
[+] [-] croes|11 months ago|reply
https://www.rtems.org/
[+] [-] thescriptkiddie|11 months ago|reply
[+] [-] ykonstant|11 months ago|reply
If we, the relevant community, do not think much of GPL violations when they hurt people we dislike, the social foundation that gives power to the law goes away.
[+] [-] indrora|11 months ago|reply
The kind of missile RTEMS was built for carries not bombs but science. The kind that put men on moons and get them back again.
[+] [-] jillyboel|11 months ago|reply
Let's ignore for the moment nothing was actually stolen since the original authors still have their copies.
[+] [-] jchw|11 months ago|reply
Stolen valor isn't really literal theft either, but that doesn't mean it's okay to do it.
[+] [-] bogwog|11 months ago|reply
> 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?
[+] [-] 1970-01-01|11 months ago|reply
>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"
>https://github.com/atgreen/RTEMS?tab=License-1-ov-file
[+] [-] unknown|11 months ago|reply
[deleted]
[+] [-] DidYaWipe|11 months ago|reply
[+] [-] londons_explore|11 months ago|reply
[+] [-] inamberclad|11 months ago|reply
[+] [-] xbmcuser|11 months ago|reply
[+] [-] chris_wot|11 months ago|reply