Google's requirement for developers to be verified threatens app store F-Droid

Original Article ↗ Hacker News Discussion ↗

Impact on F-Droid and developer verification

  • Google’s new requirement that all Android developers be registered and verified conflicts with F-Droid’s model of anonymous, community-driven, free software distribution.
  • F-Droid says it cannot force contributors to register with Google without undermining its purpose, nor can it “take over” package IDs by uploading apps under its own account, because then F-Droid’s signing key would effectively become the exclusive distributor for many projects.
  • Some commenters clarify the technical issue: whichever signing key has the majority of installs for a given package name effectively “owns” that identifier, limiting the original developer’s options later.

Android’s shift from “open” to locked-down

  • Many see this as part of a long, deliberate tightening: deprecating open APIs in favor of closed Play Services, making custom ROMs harder, and now constraining sideloaded ecosystems like F-Droid.
  • Several call it a “long con”: Android was marketed as open and sideload-friendly to gain share and kill rivals, then gradually enclosed into an Apple-style “lavish jail cell.”
  • Others argue Google hasn’t literally eliminated all alternative OSes, but note that almost all surviving platforms are either Android variants or niche Linux-phone projects.

Security, regulation, and user freedom

  • Google’s justification—sideloading having “50x more malware”—is met with skepticism; people point out extensive scams and privacy abuses on the Play Store and even on Apple’s curated store.
  • One side analogizes phones to cars, food sales, and building codes: everything else is regulated for safety, so app distribution being licensed and identified is consistent.
  • The opposing side stresses externalities: bad decks or food harm others; installing an F-Droid tic-tac-toe app mostly affects only the user. They argue regulation should scale with platform power (Google) rather than individual users.
  • Debate branches into broader libertarian vs safety-regulation arguments, including whether “complaint-driven” laws and selective enforcement are acceptable.

Alternatives and custom ROMs

  • Some plan to move to Linux phones (Librem 5, PinePhone, Mobian, postmarketOS, etc.), but note limitations: weak battery life, LTE-only modems, flakiness, and poor US availability.
  • Others advocate de-Googled Android forks like GrapheneOS, /e/OS, and similar ROMs on Pixel or Fairphone devices, while warning Google is also making third‑party ROMs harder (e.g., reduced driver openness, bootloader lock trends).

Licensing, law, and proposed remedies

  • Suggestions include:
    • Shifting more projects to GPLv3 to resist tivoization and require bootloader unlock.
    • New “tiered” FOSS licensing that’s permissive for individuals but restrictive for large corporations (with pushback that this would no longer be OSI‑open).
    • Regulatory schemes dividing “hardware-part” software (must be open, modifiable) from “non-hardware” apps (can be proprietary but cannot assert control over the device).
  • Some want fraud or antitrust action, arguing Android was sold as open and is now being closed; skeptics respond that legal remedies are weak without new legislation.
  • Several hope the EU (DMA, Cyber Resilience Act) will constrain Google’s ability to insert itself into third‑party app distribution, though details and timelines are described as unclear.