What Game Decompilation Teaches Us About Owning Software vs. SaaS

What does game decompilation teach us about owning software vs. SaaS?

Owning software instead of renting it means keeping access, control, and the right to modify the code no matter what the vendor decides next. Nobody has proven that distinction more thoroughly, or paid more for it, than the communities that decompile old video games.

What does owning code actually look like in the RE4 decompilation?

In late 2025, a developer using the handle adonis-singh published a complete, byte-identical decompilation of Resident Evil 4's GameCube debug build, the so-called "Nov 25 2004" prototype known internally as G4BE08, on GitHub. Every function in that binary now exists as readable, buildable C and C++ that compiles back down to the exact same machine code Capcom shipped two decades ago. The developer said the conversion, aided by an AI coding tool, took under a week.

That's not a hack, a patch, or a fan translation layer sitting on top of someone else's binary. It's the source code itself, recovered function by function until the output matches the original perfectly. Once you have that, you can read the game's logic, change it, rebuild it, and understand exactly why it behaves the way it does. That's the whole definition of owning software. Capcom never handed this project the source. The community rebuilt it from the outside.

Is game decompilation a one-off, or a movement?

RE4 is the newest entry in a much older tradition. The n64decomp project spent years decompiling Super Mario 64 into C, and its GitHub repository now builds byte-identical ROMs for five separate regional releases and has drawn more than 8,800 stars and 1,600 forks.

According to Ars Technica's reporting on the effort, the project's actual goal was never to make a PC port. It started because speedrunners wanted to understand the game's code well enough to find exploits. The PC port, the mods, and the new levels people built on top of it all came later, as a consequence of having real source rather than the point of the exercise.

The Legend of Zelda: Ocarina of Time got the same treatment. The zeldaret/oot project set out, in its own words, to "recreate a source code base for the game from scratch," and after years of volunteer work it succeeded, later enabling fully independent PC ports. None of this is easy or fast. Reverse-engineering an N64-era game byte for byte means first figuring out the exact version of the original SGI IDO compiler, then hand-converting assembly instructions into C, function by function, until the recompiled output matches the original bit for bit. Mario 64 took roughly two years. Several months into the Ocarina of Time effort, the team had converted only about 15% of the game's more than 15,700 functions.

One caveat worth flagging: decompiled source covers logic, input, and animation, not the art or sound assets. You still need an original copy of the game to build something playable. Decompilers aren't pirating the game. They're recovering the part of it that was never supposed to be theirs to see.

Why isn't running a binary the same as owning it?

Here's the technical distinction the whole ownership argument rests on. You can run a compiled game on original hardware or in an emulator for years without ever owning it in any meaningful sense. You can play it, mod its data files a little, even take it apart with a debugger. What you can't do is understand it well enough to change its behavior with confidence, fix a bug the publisher will never fix, or rebuild it for a platform the publisher never intended.

That gap, between having access to a binary and having buildable, modifiable, byte-matching source, is exactly the gap decompilation closes. It's also exactly the gap most companies live inside every day with their SaaS stack, minus the years of dedicated reverse-engineering that gamers are apparently willing to put in and enterprises are not.

What happens when the rights holder says no?

Decompilation communities don't get to do this for free. In August 2026, Nintendo filed seven separate DMCA anti-circumvention notices with GitHub in a single day, wiping out more than 400 Switch emulator repositories, including forks of projects that had been dormant for years. The campaign built on precedent: Yuzu developer Tropic Haze LLC agreed to a $2.4 million settlement with Nintendo in 2024 and shut the project down entirely.

That's the real cost of not owning the source in the first place. You get to exist at the pleasure of the rights holder, and the rights holder can change its mind. Enterprises tend to call this vendor lock-in when it happens to them and treat it as a contract problem rather than a legal one. But the mechanism is identical to the risk laid out in the case against renting platform access: someone else controls the thing you depend on, and someone else's decision can take it away.

What are the benefits of owning software vs. SaaS?

Strip away the game consoles and the DMCA notices, and decompilation is just an extreme, adversarial version of a question every software buyer should be asking: what do you actually get from owning the thing versus renting access to it? The concrete advantages are consistent whether you're talking about a 20-year-old GameCube prototype or a CRM your finance team depends on:

• Continuity. Owned software keeps running even if the company that built it disappears, pivots, or gets acquired. Rented software stops the moment the vendor decides it should.
• Customization. Source access means you can change behavior to fit your workflow instead of filing a feature request and waiting.
• Cost control over time. A one-time or capped cost beats a per-seat subscription that scales with headcount whether or not usage does.
• No forced obsolescence. Vendors sunset products, force migrations, and deprecate APIs on their own schedule, not yours.
• Audit and compliance control. You can inspect exactly what the software does with your data instead of trusting a vendor's documentation.
• No seat-based rent. You stop paying more every time you hire someone who barely touches the tool.

Every one of these is something decompilers fought years, and in some cases six-figure legal risk, to get for a video game. Enterprises can usually get the same thing by negotiating a contract, building in-house, or choosing self-hosted software up front, without anyone filing a DMCA notice against them.

How much SaaS spend actually goes to waste?

The strange part is how much enterprises already pay for renting instead of owning, without the payoff decompilers eventually get. Fifty-one percent of enterprise SaaS licenses go unused, the highest waste rate on record, with only 49% of purchased licenses logged into within the past 30 days. Zylo's benchmark, built from 30 million licenses and more than $34 billion in tracked spend, puts the average enterprise's annual SaaS waste at roughly $18 million, up 7% from two years earlier. Flexera's 2022 survey of 465 IT professionals at companies with 1,000-plus employees found close to 29% of SaaS spend underutilized or wasted outright.

That's not a rounding error. That's tens of millions of dollars a year, per large company, spent on access rather than ownership, with no source code, no modification rights, and no guarantee the vendor will still exist or still care about your use case next year.

Is software escrow the enterprise version of decompilation, minus the code?

Enterprises do have a formal answer to this risk, and it's telling how weak it is compared to what decompilers actually achieve. Source code escrow arrangements have a neutral third party hold a vendor's source code, to be released to the customer only if the vendor goes bankrupt or stops supporting the product.

It's a reasonable insurance policy. It's also entirely reactive. You get the code only after something has already gone wrong, and only if the escrow terms were negotiated well in advance and the vendor actually deposited a current build. Decompilers don't wait for a trigger event. They go get the source themselves, years before anyone asks permission, because they've decided access without ownership isn't good enough. That's a higher standard than most procurement teams ever set.

What happens when the vendor walks away?

Both worlds show the same failure mode when dependency isn't backed by ownership. On the SaaS side, when a provider shuts down, customers can lose their dashboard, files, and stored data immediately, often with no warning, no backup, and no export path. On the gaming side, the Video Game History Foundation's study with the Software Preservation Network found that 87% of classic video games released in the U.S. are out of print and effectively unavailable through any commercial channel. No period of gaming history the study measured even reached 20% commercial availability. In both cases, the software didn't disappear because it stopped working. It disappeared because access depended entirely on someone else's continued goodwill.

Should you build or own where it's core, and rent where it's commodity?

Decompilers prove that full ownership of complex software is technically achievable, even against a rights holder actively trying to stop you. That's the standard worth borrowing, not the DMCA risk. For commodity tools where switching costs are low and nothing critical rides on continuity, renting SaaS is still fine. For the systems that run your actual business, the same logic that pushed Nintendo fans to spend two years hand-converting assembly into C should push a CFO to ask what happens if the vendor gets acquired, pivots, or simply raises prices 40% at renewal.

A real self-hosting movement has started answering that question the way decompilers did, by building local-first, source-controlled alternatives that customers can run, modify, and back up themselves instead of renting access indefinitely. Companies like Remy are part of that same shift, building tools that let businesses own their software stack outright instead of subscribing to it forever. Nobody's asking procurement teams to reverse-engineer assembly code. They're asking them to apply the same test decompilers already answered: if the vendor disappeared tomorrow, would you still have something that works?