The editorial emphasizes that the petition's actual ask is far more modest than 'gamers vs. publishers' framing suggests: when a publisher stops supporting a game, it must be left in a 'reasonably functional state' without requiring publisher infrastructure. This means offline modes, private server binaries, or protocol documentation — a technical requirement, not a commercial obligation to maintain games forever.
The editorial argues the real precedent here extends far beyond games — Stop Killing Games is the first mass-market legal test of whether software sold as a perpetual license can be revoked by the seller. The HN comment thread reinforces this, pivoting immediately from games to Adobe, Autodesk, and John Deere, suggesting the gaming case is a wedge for broader software ownership rights.
By submitting the BBC article to HN where it reached 125 points, Brajeshwar surfaced a discussion that immediately broadened beyond games to encompass revocable licenses across all software categories. The top comments treating this as a precedent for Adobe and Autodesk indicate the developer community sees this as a software ownership issue, not a gaming issue.
The editorial points to Ubisoft's specific choices as the catalyst: killing a primarily single-player driving game gated behind always-on authentication, offering refunds only to recent buyers, and stripping the game from libraries of people who paid full price a decade ago. This pattern — taking away purchased content without offering offline alternatives — is framed as the radicalizing force that pushed 1.4 million signatures past the threshold.
The editorial stresses that crossing the 1M signature threshold plus per-country quorums triggers mandatory Commission response within six months and a public hearing in the European Parliament. While the Commission can technically say 'no,' it cannot stay silent, and Pirate Party MEPs have already signaled intent to push binding legislation — meaning the process forces a substantive political reckoning regardless of outcome.
The Stop Killing Games initiative — a grassroots campaign started by YouTuber Ross Scott after Ubisoft killed *The Crew* in March 2024 — has crossed the threshold to force an official European Commission response. As of this week, the European Citizens' Initiative has gathered over 1.4 million verified signatures across EU member states, well past the 1 million required and the per-country quorums in at least seven countries. The BBC's coverage put the campaign on the front page of Hacker News at 125 points, where the top comments are not about games at all — they're about Adobe, Autodesk, John Deere, and every other vendor that has discovered the recurring revenue of revocable licenses.
The ask is narrower than the headlines suggest. The petition does not demand publishers support games forever; it demands that when they stop, the game must be left in a "reasonably functional state" that does not require the publisher's infrastructure. That's a technical requirement, not a commercial one: ship an offline mode, release private server binaries, or document the protocol. *The Crew* shipped none of those, despite being a primarily single-player driving game gated behind always-on authentication. Ubisoft's response — offering refunds only to recent buyers and stripping the game from libraries of people who paid full price a decade ago — is what radicalized the signatures.
The Commission now has three months to acknowledge receipt and six months to issue a formal response. That response can be "no," but it cannot be silence, and the Citizens' Initiative process triggers a public hearing in the European Parliament. Pirate Party MEPs have already signaled they'll push for binding legislation.
The framing in most coverage — "gamers vs. publishers" — buries the actual precedent. Stop Killing Games is the first mass-market test of whether software sold as a perpetual license can be unilaterally revoked by the seller, and the answer will not stay confined to games. Every SaaS vendor that bills itself as "buy once, own forever" while reserving the right to disable activation servers is watching this. So is every IoT vendor that has discovered they can sunset a $200 device by shutting down its cloud backend. The Spotify Car Thing, Sonos's forced app migration, Google's graveyard of bricked Nest products, Insteon's overnight shutdown — these are all the same architecture question dressed in different industries.
The HN thread is unusually focused on the engineering implications. The highest-voted technical comment lays out the actual ask: a teardown obligation. Just as factories in regulated industries must post decommissioning bonds, publishers would need a documented end-of-life plan before shipping an always-online product. That moves "can we shut down the servers cheaply" from a finance question to a compliance question, and compliance questions are where architectural decisions actually get made. Several commenters note that the requirement is closer to GDPR than to copyright law: it doesn't dictate what you build, it dictates what state you must be able to deliver at end-of-life.
The counter-argument from the industry trade group Video Games Europe is technically thin and politically loud. Their position paper claims that mandating offline modes would "chill innovation" and that anti-cheat, matchmaking, and live-service economies cannot function without server-authoritative architectures. This is true and irrelevant — nobody is asking Fortnite to ship a private server binary while it's still running. The ask is what happens *after* the publisher stops caring. The industry's real objection is that always-online is load-bearing for the recurring-revenue model, not for the gameplay; admitting that publicly is what they're trying to avoid.
There is genuine engineering hard mode here, and the petition's critics aren't all wrong. Server emulation for a modern MMO involves reconstructing not just the protocol but the entire backend economy, anti-cheat handshakes, payment integration stubs, and a years-deep stack of microservices. Games like *Concord* — shut down 11 days after launch — would be functionally impossible to preserve under the current text. But the petition's lawyers have been careful: "reasonably functional" is a deliberately squishy standard, the same one EU consumer law already uses for repair obligations on appliances. The bar is *something runs*, not *the live-service experience is preserved*.
If you ship anything with a server dependency to consumers in the EU — games, smart-home devices, productivity tools sold as one-time purchases, even subscription apps with offline modes — the next 18 months are when this becomes a real architecture constraint. The cheap reading is "add an offline mode." The expensive reading is correct: always-online as a default is about to carry a tail liability, and the teams that win are the ones who designed for graceful degradation from day one rather than retrofitting it during a sunset.
Concretely, three patterns get more valuable. First, protocol documentation as a deliverable — not a wiki page, an escrowed spec. Several commenters point to the model used in regulated medical devices: source code and protocol docs deposited with a third party, released on end-of-life or bankruptcy. Second, server-authoritative-but-self-hostable designs — the *Minecraft* and *Factorio* model, where the canonical implementation runs on the publisher's infrastructure but the binary is shippable. Third, client-authoritative fallback modes for games that don't need anti-cheat after the competitive scene ends. None of these are new ideas. What's new is that one of them may become mandatory.
The inverse warning is for VC-backed live-service plays. If you're pitching a game-as-a-service or device-as-a-service that depends on the option to unilaterally end-of-life the product, the cost-of-shutdown line in your model just got an asterisk. The EU has not historically been shy about extraterritorial enforcement — the Digital Markets Act and GDPR both apply to US companies serving EU users, and there is no reason to expect a game preservation law would be different.
The Commission's response is due before the end of 2026, and the smart money is on a watered-down directive that mandates disclosure ("you must tell buyers this game requires servers and may become unplayable") rather than preservation ("you must ship a way to keep playing"). That would still be a meaningful change — every storefront would need a server-dependency label, and the *Crew*-style silent kill would become a consumer-protection violation. But the harder version is on the table for the first time, and the petition's success has already shifted the Overton window. The era of treating "the servers are off" as a complete answer to "where did my game go" is ending. The only question is whether your architecture is ready when it does.
Part of this is simply fixed by a tweak to copyright that if the IP isn't available for sale at a reasonable price the copyright no longer applies. Games, books, movies, music, etc.
Tell gamers how many months, for the advertised price, they will receive a guaranteed level of service and features for.Then let gamers decide.Example: If I'm reminded, at purchase time, that this $70 game will work online for 24 months and single-player offline for 36 months, then I can make a
My lateral solution: don’t let the companies use the words “purchase” or “buy”, force them to use the words “rent” or “license”.You can only use the words “purchase” or “buy” if you can install / move the files to a device that is completely airgapped from the internet and continue to use the p
Just don't design the game so that, when the business model stops working, every paid copy becomes a brick
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
The goal is a good one, but it's too specific. It should not be allowed for a developer or device manufacturer to kill or nerf any product remotely, once it was bought and paid for. This problem is sneaking into other non-game software, and even physical devices! If you buy a thing you shouldn&