When hardware goes end-of-life, companies need to open-source the software

Original Article ↗ Hacker News Discussion ↗

Scope of the Proposal (Open Source at EOL vs. Just Interfaces)

  • Several commenters note the article mostly calls for publishing hardware specs, protocols, and basic firmware/SDK, not full codebases.
  • Some argue that for simple devices (e.g., scales) this is enough; for complex ones (routers, SoCs) it isn’t.
  • Others say reverse-engineering can already recover many specs; the real value is removing legal/technical barriers to alternative firmware.

Secure Boot, Signing Keys, and “Fail Open” Designs

  • Strong debate over whether EOL should trigger release of signing keys.
  • One side: forcing key release would create botnet risk and let attackers hijack OTA update channels.
  • Counterpoint: embedded security is already “an unmitigated disaster,” and inability to fix EOL bugs due to locked boot chains is worse.
  • Proposed compromise:
    • Multiple-key architectures (ROM → 2nd-stage bootloader → app) where an EOL update can unlock the 2nd stage.
    • Physical or explicit user actions (buttons, magnets, sequences) to enter “unlock” mode.
    • Laws requiring designs to allow post-EOL user control.
  • Some call for outlawing permanently locked bootloaders; others stress security models that depend on locking but want reversible unlock.

Regulation vs. Market / Consumer Responsibility

  • Many want EU-style regulation: mandatory unlock at EOL, open APIs, or liability/refund if core functionality is killed.
  • Skeptics doubt enforcement against large tech firms and foresee loopholes (e.g., redefining “main function”).
  • Another camp says consumers should refuse cloud-tethered/closed devices and “vote with their wallets,” though others call this unrealistic at scale.

Cloud Dependence, E-Waste, and Examples

  • Multiple examples of good hardware rendered useless when backends died (frames, thermostats, speakers, cameras).
  • Some point to successful community rescues (e.g., alternative firmware and self-hosted backends) as proof of demand.
  • General agreement that dependence on vendor servers for basic local functions is a major e‑waste driver.

IP, Cost, and Practical Constraints

  • Commenters note:
    • Commercial products often share codebases across generations; open-sourcing one can reveal active IP.
    • Third-party licensed components can’t legally be open-sourced.
    • Cleaning a codebase for release can be expensive (months, six-figure costs).
  • Hence suggestions to:
    • Require only open APIs and freedom to run alternative software.
    • Design around open standards (e.g., local protocols, non-cloud basics) from the outset.

Broader Ideas: Copyright, Games, and Archival

  • Some advocate short software copyright terms and mandatory source escrow so old software and games enter the public domain in usable form.
  • Others highlight the practical difficulty of preserving old code and toolchains for decades, questioning the value of such laws without strong incentives.