I believe it makes more sense to treat dkP as an "organization whose decisions can be annoying" (like Nintendo, Microsoft, etc), that's just
also not-for-profit. They make a free toolchain, and help make crucial decisions in the homebrew ecosystem, but that doesn't mean they don't still have certain incentives.
Between the buildscripts and the releases, the dkP organization asserts there is enough to comply with GPL. So that's kind of the full story. Even if it didn't comply, there are no "lost damages" to sue them over, which seems like all that a copyright violation would amount to anyway (but I'm not a lawyer, etc).
Every for-profit organization I've ever been a part of is 100% hesitant to touch anything copyleft/open source due to fear of being sued, but it's a little different when your goal isn't to make money. If dkP defines the "value"/secret sauce of their organization as tagging these releases and deciding which binaries go where, I've come around to, we aren't necessarily "owed" the transparency behind this process.
Quark's post above is important, but it's more about the internals of how they run their org. At the end of the day, as long as we
do have these archive collections or docker images, the problem of reproducible builds is not that bad. It's a community-originated desire that is also being solved by the community.
Viewing it like this, the way that the dkP org reacts "frustratingly" in certain scenarios (eg. the ones referenced in that tweet thread), is really more of a PR problem for them. I think there can exist a set of branding that would keep their role clear, but also not conflate it with the kind of open-source-transparency-mentality that "we" (devs/enthusiasts) are "expecting".
It feels like the "come talk with us" line on their site about updating old homebrew runs contradictory to this. Those chats can be quite "unfriendly"/confrontational to the uninitiated, and that's both unprofessional and poor "customer" service. If they just completely ignored mirrors and what people do with their tech, they would be much better off, PR-wise.
Ironically, that's kind of how Nintendo deals with the homebrew scene: just totally ignore it, and people can't come and get upset with you for what you haven't said. It seems odd to suggest that dkP should take this same approach to the "FOSS scene", but
I think what's really being carved out here is a middle "tier" in between "official licensed Nintendo SDK" and full "free open source software", and that's where dkP's toolchains lie. Unofficial and free, but not all the way in the FOSS-ethos camp.
TLDR: Zen of devkitPro org interactions -> ignore any passive aggressive comments, keep calm and archive old versions (but still comply with their copyright, trademark, and GPL).
Although, that
all being said, it might be more accurate for the page with these old toolchains to not directly refer to them under the trademarked organization name (kind of like IceWeasel vs Mozilla FireFox, OpenJDK vs Oracle JDK, or even Rocky Linux vs RHEL).
It's honest and historically accurate to present them as "old devkitPro tools", and just link to the buildscripts on Github as a source, but the phrasing should matter. The
Rocky Linux site for example has no issues stating that the releases are 100% identical to RHEL releases, even with the same version numbers, but it does not claim that its downloads are "RHEL" itself.
This is a long winded and annoying final conclusion, but I would suggest to change the wording of "As
the devkitPro software is [...]" to "As devkitPro
's software is [...]" in the second paragraph, and also to remove "devkitPro" from the root folder name, so there's no confusion of endorsement. Maybe something like "/archive/", "/packages/", or some other generic name. A redirect could be added, so that old URLs are still valid.
The "source code" (aka dkP's Github repos) should also be periodically archived and hosted separately, in case dkP overwrites or takes down those GH repos, the entire collection would be at risk of a GPL violation (for reasons already talked about much earlier in this thread).
BUT those are all just my opinions and stuff. I've thought about these things for way too long trying to comply with dkP's practices, but I do think this is the best way to handle it. It
is easy to see how at least avoid mentioning their org by name alongside old download URLs, and rehosting old sources as well, satisfies the language on
this page ("devkitPro trademarks may not be used" and "you may not distribute GPL binaries without corresponding source code").
