My insulin pump controller uses the Linux kernel. It also violates the GPL

Who’s responsible & how to escalate

• Discussion clarifies that the main actor is the US company (Insulet), with the Chinese phone maker mainly supplying hardware.
• Several comments ask how to “petition” for enforcement; others explain this goes to Software Freedom Conservancy (SFC), not FSF, with specific emails and processes mentioned.
• SFC is said to be resource‑limited and selective; medical devices are seen as high‑impact targets for them.

GPL obligations, written offers & who can sue

• Long debate on GPL v2 section 3:
  • One side: the user only has a right to source if they received a written offer and then it’s a contract issue; lack of offer is a GPL violation enforceable only by copyright holders.
  • Others argue the GPL itself guarantees user access to source when binaries are distributed.
• Disagreement whether GPL is a “contract” or a pure copyright license; several people note this is legally unsettled.
• The SFC v. Vizio case is cited as trying to establish that end users are third‑party beneficiaries who can enforce GPL terms.
• There’s an extended subthread on first‑sale doctrine and whether resellers must pass along GPL notices/offers, with no consensus.

Practical enforcement & corporate behavior

• Some argue: stop debating and file a lawsuit; filing fees are modest. Others counter that real legal costs and fee‑shifting risks are high.
• The US Copyright Claims Board is mentioned as a cheaper forum for some cases.
• Multiple comments note that front‑line support and engineers aren’t empowered to release code; requests must reach legal/compliance, which often doesn’t happen.
• One ex‑insider describes setting up a formal GPL‑tarball process and notes many requesters mistakenly expect all product source, not just GPL parts.

What source is actually owed

• A common view: if only the Linux kernel is GPL, the user may get little more than a mostly‑stock kernel tree; it might be of limited technical value but is still an obligation.
• Others emphasize even tiny or hardware‑specific kernel changes are covered, and “it’s trivial” is not a reason to ignore the license.

Medical device safety vs hacking & agency

• Large subthread on open‑source insulin pump / “artificial pancreas” projects (OpenAPS, Loop, etc.):
  • Pro‑hacking side: users whose lives depend on devices have strong incentives to avoid errors, and open code can be reviewed; some distrust corporate quality and motives more than DIY communities.
  • Cautious side: hobby projects lack regulatory testing, broad coverage, and liability; pushing code to others’ life‑critical devices is ethically fraught.
  • Several insist that people with implanted devices (pumps, pacemakers) should at least have the right to inspect and even modify code, while acknowledging it’s often unwise.

Reverse engineering & modern security

• Comments note that many older pumps have been fully reverse‑engineered and integrated into DIY systems; newer devices (Omnipod 5, recent Medtronic pumps) use strong encryption and keys tied to cloud accounts, partly in response to updated FDA cybersecurity guidance.
• Some claim companies have been tolerant of reverse‑engineering communities; others say modern vendors now take security more seriously.

Phone‑based controllers

• Explanation that regulators long required a complete standalone system, so vendors shipped locked‑down phones as dedicated controllers even though most users prefer real phones.
• These controller phones are heavily restricted (no apps, no Wi‑Fi) because they can directly deliver lethal insulin doses. Newer products in some regions now allow standard phones.

Meta: “Hacker” values vs caution

• A side debate emerges: one camp is frustrated that many comments effectively say “don’t touch it, you’ll die, trust the manufacturer,” seeing this as anti‑hacker and anti‑agency.
• Others stress that personal freedom to tinker coexists with real risk in life‑critical systems and that skepticism toward DIY medical firmware is reasonable.