asiekierka

I had no issue with the toolchain, as I happened to work on a game (ZZT) whose toolchain of choice was documented by the author himself (well, he was off by one Turbo Pascal release). Lucky!

What took me the most time was actually the beginning: building a mental model of what assembly patterns map into which Pascal patterns, and finding good areas to start writing code from. In hindsight, I should have probably started by generating inline assembly equivalents of each procedure/function. The ending was relatively smooth sailing in comparison, but it is of course much easier if the compiler you're targeting doesn't do much in the way of optimization passes, so it's not representative of decompilation work for more modern targets.

I think it is more likely that the "amazing" things, as described, will become mundane, thus shifting the definition of what becomes interesting or noteworthy. Even then, I believe people who continue to write by hand will still be appreciated, given this is fundamentally a hobbyist space.

One good example is nocash, who continues to write all of his Windows-targetting emulators in hand-rolled assembly to this very day. For a long time, some of his emulators - most notably NO$GBA - were at the forefront of popularity among homebrew developers due to their unmatched debugging tools; even though one could make them much faster with an HLL, nobody really stepped up to the task. Even now, his work remains relevant thanks to the extensive documentation he maintained alongside the emulators he developed.

Does it being a creative transformation rob the derivative work status? Personally, I'd liken the process of decompilation to that of translating a book from one language to another - the copyright on the original work does not become void merely because the process of translation requires extensive creativity.

Nicalis and Take-Two have both gone after decompilation projects, also. In particular, Nicalis has gone after a decompilation of Cave Story, but not a black box reimplementation of the same, while Take-Two ended up suing a decompilation developer (albeit settled out of court). However, in some jurisdictions, even clean reimplementations have failed - see Tetris v. Xio.

(I am not a lawyer either, etc etc, but that's my understanding)

For the sake of public record, I would like to state that I was doing nothing "behind the scenes". My part of the conversation in question is public - I was pinged as a gbdev Discord community member and that is the extent of my "consultancy". I also warned the GBcompo organizer that they should validate the rules' interpretation with a lawyer before trying to justify any requests that go beyond disqualification/delisting, particularly ones where finances get involved.

The comment about "burning bridges" is not a statement of intent, but of observation: if I publicly call someone out on the Internet, and we fail to reach a common agreement or understanding, that bridge inevitably becomes burned - even if I'm correct, even if most people agree with me! It was based on my understanding of how other people reacted to the controversy as it was brewing in community spaces, but I understand now how it could have been interpreted as a threat in its own right.

The reason I made a comment below the post (now deleted as per the game author's wishes) is because I saw him accusing the gbdev community of "censorship" - as such, I wanted to provide full transparency and accountability with regards to my role in the dispute. That was the extent of what I could do at the time, as someone who was never involved in the organization of gbcompo23 or any other gbdev community event and thus had no decision-making powers. I realized later that my stance led to harm. I regret getting involved in this at all, and I regret the things I said.

It is not possible to create a license that would satisfy the Free Software Foundation's "four freedoms" while also solving the issues many of those vendors have with the AGPL. At the same time, the "source available" mindset doesn't have a steward organization like the FSF or OSI.

We already know what the main remaining issue is - LLVM-MOS's register allocator is far from optimal for the 6502 architecture. mysterymath is slowly working on what may become a more sutiable allocator.

> 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.

> 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.

IIRC, at least a few years ago, Mumfrey had a tendency to develop Mixin in private and only push the commit backlog for releases, leading to periods of time where no activity was publicly visible. (Also IIRC, this is part of the reason why the FabricMC fork exists.)