The hardware story is only half the story
When a new console plays an old game, the conversation usually lands on silicon: did the team build an emulation layer, did they carry forward compatible CPU cores, did the memory architecture survive the generation gap? Those are real constraints, and they matter. But a console generation also ends with a library of software built under specific licence agreements, engine deals, middleware contracts and publisher arrangements — and none of those transfer automatically to a new platform.
Every commercial game on a certified platform is there because someone signed a licence agreement with the platform holder ↗. That agreement covers the original hardware, the original storefront, sometimes a named title. When Sony Interactive Entertainment, Microsoft or Nintendo launches a successor console, the old agreements do not silently extend themselves. A publisher whose game is now playable on new hardware — particularly if that hardware is sold as a selling point — may reasonably argue it is receiving a new commercial use the original contract did not anticipate.
Middleware is where it gets specific
Inside most commercial games sits licensed middleware: physics engines, audio systems, video codec libraries, anti-cheat systems, user interface frameworks. Each of those carries its own licence, often tied to a platform, a version or a unit-sales threshold. A physics library licensed for PlayStation 4 is not automatically licensed for PlayStation 5, even if the platform holder's backward-compatibility layer can run the binary perfectly. The developer who shipped the original game may no longer hold a current agreement with that middleware vendor — the studio may have been restructured, the vendor may have been acquired, the licence may simply have lapsed.
This is not theoretical. It is the mechanism behind games that quietly vanish from backward-compatible libraries. A title that was available at launch of a legacy programme, then disappears six months later, has almost certainly hit a contractual wall rather than a technical one. The Berne Convention ↗ and national copyright law sit underneath all of this: the underlying code, assets and music are copyrighted works, and backward compatibility does not create any new exception to who controls their distribution.
Music licensing compounds the problem further. Soundtrack rights in games are frequently time-limited — a label agrees to in-game use for five years, or for a specific platform, not in perpetuity. A game with a licensed soundtrack that runs on new hardware may be distributing that music under terms its original licence no longer covers. Removing the game from a backward-compatible catalogue is the cleanest legal exit.
Why it appears and disappears across generations
The practical consequence is that backward compatibility is never simply a hardware decision that, once made, stays made. It is a continuous legal maintenance task. Platform holders that commit to it — as Microsoft has with its Xbox backward-compatibility programme, which has required title-by-title legal clearance alongside the technical work — must run a dedicated function that renegotiates, confirms or removes titles on an ongoing basis. The hardware team builds the capability; the legal and business affairs team determines what actually runs.
This is also why the feature tends to shrink across generations rather than compound. A platform holder theoretically capable of running software from three previous generations faces not one but three layers of expired agreements, defunct studios, acquired middleware vendors and lapsed music rights. The further back the library, the higher the clearance cost per title relative to the commercial value of running it. Preservation of truly obsolete systems is, for this reason, increasingly left to archives, libraries and documented institutional programmes ↗ rather than first-party platform decisions.
Silicon determines whether an old game can run on new hardware. Contracts determine whether it does.
