SSDD

But that's a pretty dumb scam: act obnoxious then beg for (a lot of) money to compensate for your own mistakes? If that was the plan all along, it seems pretty incompetent. I'd expect a competent scammer to have a better understanding of psychology.

It is the sort of dumb crap some humans try, and occasionally manage to get away with because other humans are chronically gullible. So it wouldn't be beyond the realms of reason that the agent couldn't have had relevant information in the training sets such that it generated such a plan and guardrail checks didn't flag it as a problem.

Dedicated Internet wires came much later, and then the dedicated phone lines were dropped as voip was better quality and cheaper compared to the dedicated lines.

While the phone still had a dedicated line it didn't actually need a power connection, as the power through the phone wire was sufficient.

AOL was offering free minutes because it was an ISP, not because it was an online service. (It was also an online service. Most of that service was indeed free; some of it billed by the minute, but that was separate from the rate you paid for connecting to the internet.)

The telephone network made the utterly bizarre choice to intentionally degrade the audio signal of a call, guaranteeing that people would have an unnatural, distorted voice if you spoke to them over the phone. There was no way for voip not to be better quality.

1. those assets are stored in proprietary formats that only the game code itself understands, and

2. no tool exists in the project to extract the assets from these proprietary formats into open formats, unless that tool itself exists only in source-code form in the codebase, and requires the ROM as an input to compile it (even if in the case of such a tool, the ROM is doing nothing but serving as a "key" to unlock compilation.)

Basically, if you have to prove you have your own copy of the IP in order to make their embedded copy of the IP "legible", then it's very hard to construct an evidence-based DMCA takedown order that actually makes any coherent point about the project "distributing" said IP.

That being said, shipping assets like this at all, even if you "can get away with it", is ultimately just a kind of laziness / shortcut-taking. They do it because there's either no clear/simple/obvious way to automatically extract the given asset data from the ROM (e.g. because the relevant data is split up into various data planes + metadata bits that are stored "exploded" all over the ROM), so they just did it once by hand, committing the results; or because there's no clear/simple/obvious way to store the extracted asset data such that a regular compiler/assembler natively understands how to embed it into the binary in the particular form it was found in the original ROM. (Remember, re-assembling/compiling to the original ROM is always the test these projects use to ensure their disassembly/decompilation is preserving semantics. So they need to replicate every weird layout quirk the original dev tooling imposed upon the original ROM. And sometimes the original dev tooling included special-purpose domain-specific asset-codegen tools that aren't part of regular compiler toolchains.)

What these projects should actually be doing, is taking on the schlep: writing the extract tooling anyway, even if it's just "copy these bytes from here and these bytes from there, and spit them out as hex in an .asm file with this header"; and/or writing matching asset-codegen tooling to the tooling that likely existed in the platform SDK, to run before compile/assemble time, converting the extracted ROM asset files into a form (probably a bunch of little assembly files) that will land in the right places when linked back together to form the original ROM.

And, to be clear, they mostly do do this! These projects are very good at doing this!

But sometimes — especially on a larger project with many contributors — one or two things like this aren't audited properly, and fall through the cracks. Or they start out as temporary "bootstrap" approaches made during a private phase of development to get things working + compiling to a correct image; and then not all of those get cleaned up before the repo gets made public.

To be clear; I don't really understand the law around this - my own country is based on case law which means that even if I wanted to open source some of my reverse engineered games (I have a few private partial implementations of some old defunct game engines in-progress), the distinct lack of prior cases means, sadly, it's prudent not to release them at all while the companies are still active.

The Spanish Civil War was arguably just a proxy opening of WW2 between the USSR and Germany. Doesn’t change your point, just came to mind while reading your comment.

Ultimately, a company like Stripe sits on top of a fragile patchwork of societal/technological abstractions that are a byproduct of generations of compounded wealth.

Humans battling in the marketplace builds this compounded value, humans battling in warfare destroys it and makes you start from zero.

Just as the industrial revolution started decades before humans began leaving the farm en masse, the digital revolution started decades before anyone had a personal computer on their desk.

Europe was busy rebuilding firebombed cities and industrial capacity, while Americans were free to birth the next layer of abstraction post-WW2 (the digital one). This early lead compounded. Moral of story: don't get in wars on your soil.

The "on your own soil part" is even more complex than this implies. America spent decades waging wars across the world to reduce the chance that Russia could do the same.

It's a noble pursuit, but the key part for you is that you _wanted_ to avoid those mistakes and put forth an effort to learn how to. The necessity, in order to truly avoid them, is that enough individuals collectively desire and pursue that. It's why (good) public education is so important for the long term health of societies.