FSF announces Librephone project

Project goals and scope

  • Librephone is framed as a long‑term reverse‑engineering effort on Android device blobs (firmware, drivers, HALs), not a new phone or distro.
  • Aim: enable fully free (as in FSF‑free) Android‑compatible OSes by replacing non‑free components; benefits are expected to flow to LineageOS, GrapheneOS, postmarketOS, and other GNU/Linux efforts.
  • Scope currently stops at the OS/firmware layer; no direct hardware design or manufacturing.

Why base on Android instead of “Linux phones”

  • Many see Android as the only realistic base: mature UX, massive app ecosystem, lots of existing device support.
  • Prior “desktop‑Linux‑on‑phone” projects (FirefoxOS, Ubuntu Touch, postmarketOS, PinePhone, Librem 5) are praised philosophically but criticized for poor usability, battery life, camera quality, and app availability.
  • Others argue FSF should have built on Librem 5 or postmarketOS instead of touching a Google‑defined stack.

Binary blobs, modems, and regulation

  • Consensus that userland blobs are tractable but baseband/wifi firmware is the hardest layer:
    • Modern modems are deeply integrated into SoCs, run large proprietary RTOS stacks, and often have DMA access.
    • Regulatory regimes (FCC, PTCRB, Part 96, etc.) require certified firmware for licensed spectrum; open, modifiable modem code may be effectively illegal on commercial networks.
  • Some argue these hurdles are decisive and show FSF “doesn’t understand the problem”; others note this is very similar to doubts voiced against GNU in the 1980s.

Ecosystem lock‑in and attestation

  • Many commenters think blobs are a secondary problem compared to app‑layer control:
    • Banks, governments, and large sites increasingly require proprietary mobile apps, hardware‑backed attestation, or “Play Integrity”–style checks.
    • Trend toward app‑only banking and government ID is seen as a bigger threat to freedom than firmware.
  • Suggested workarounds:
    • Two‑phone model: a “compliance” phone for banking/ID, and a free phone for daily use.
    • Relying on web apps/PWAs where possible; some urge devs to ship fully functional PWAs.
    • However, others warn the web itself is drifting toward DRM and attestation (e.g. CDNs offering “verified user” toggles).

Hardware lifecycle and feasibility

  • Major skepticism that one developer (currently funded) can keep up with fast phone cycles; by the time a device is fully deblobbed it may be obsolete.
  • Counter‑argument: once one SoC family is understood, successive models and sibling devices get easier as designs are incremental.
  • Some propose focusing on a single, stable platform (e.g. Fairphone‑class hardware, or even simpler “dumb” phones) rather than chasing flagship SoCs.

Comparison to existing projects

  • GrapheneOS, LineageOS, /e/OS, postmarketOS, Librem 5, PinePhone, and FLX1s are heavily discussed:
    • GrapheneOS praised for security and banking‑app compatibility, but limited to Pixels and still at mercy of Google’s APIs.
    • /e/OS and Fairphone criticized as years behind on kernels and security patches despite “privacy” branding.
    • Librem 5/postmarketOS get credit for being closer to pure GNU/Linux, but widely viewed as niche due to cost, aging hardware, and app gaps.

Strategy, politics, and FSF competence

  • Some see Librephone as “15 years late” and think FSF’s real leverage should be lobbying regulators (for open bootloaders, against mandatory attestation, for web access alternatives).
  • Others reply that FSF’s role is precisely to be uncompromising on software freedom and to produce technical groundwork others can build on.
  • A recurring theme is fragmentation: repeated calls for unifying or at least coordinating LineageOS/GrapheneOS/postmarketOS/Fairphone/Pine64 efforts, rather than spawning yet another silo.

User needs and appetite

  • Many commenters want a “mostly normal” phone: calls, SMS, good camera, battery life, NFC payments, banking apps. They’re willing to trade some freedom for that.
  • Others are ready to sacrifice convenience, run a separate “token phone,” or restrict themselves to browser‑based workflows if necessary.
  • Overall sentiment mixes hope (“better late than never,” “this is the last chance before Android locks down”) with broad skepticism about scale, timelines, and whether FSF can deliver anything beyond symbolic purity.