Repair, Portability, and Interoperability: Ownership in a Permissioned Economy

Ownership has moved into software

The old right-to-repair debate was about parts and manuals. The current debate is about software-controlled products and data-dependent services. A tractor, car, phone, appliance, medical device, printer, or industrial machine may be physically in the owner's possession, but the useful ability to diagnose, repair, calibrate, update, or export data can sit behind manufacturer-controlled software.

That changes the economics of ownership. Downtime becomes more expensive because only the authorized channel can perform the repair. Independent repair shops cannot compete even when they have the mechanical skill. Farmers can miss planting or harvest windows. Consumers discard products that could have been repaired. Small businesses stay with software vendors because exporting data and rebuilding integrations is too costly.

The FTC's January 2025 Deere complaint made the stakes concrete. The agency and two states alleged that Deere restricted access to a fully functioning repair tool needed for certain farm-equipment repairs, steering customers toward the dealer network and raising repair costs and downtime. Deere disputes the allegations, and the litigation remains a case, not a final finding of liability. But the structure of the dispute is exactly why this issue belongs in a technology platform: software control over a physical product can become market control over repair.

The burden of proof should sit with the restriction

Manufacturers and platforms often raise safety, privacy, and cybersecurity objections to repair and interoperability mandates. Some are legitimate. A bad repair can make a vehicle, medical device, grid component, or battery unsafe. A careless API can leak sensitive data. A firmware tool can become an attack path. The platform should not dismiss these concerns as pretexts just because some restrictions are pretextual.

The correct standard is burden of proof. A company that restricts repair or interoperability should identify the specific risk, show why ordinary access would create it, and provide the least-restrictive alternative that addresses the risk. That might mean logged access, certified procedures, safety-critical calibration checks, delayed release for an active security vulnerability, or privacy-preserving data-transfer protocols. It should not mean a blanket rule that only the manufacturer may repair, access, or connect.

FTC's own discussion of interoperability, privacy, and security points in this direction. It recognizes that privacy and security can coexist with interoperability and that claims about competition being blocked for privacy or security reasons deserve close scrutiny. That is the right posture for this issue: evaluate the risk, do not accept the slogan.

Portability is a competition and autonomy right

Repair applies to products. Portability applies to data and services. Both address the same problem: a user should not be trapped because leaving means losing records, history, configuration, reputation, or business data. A small merchant should be able to export product catalogs, customer records subject to privacy limits, transaction history, and analytics. A farmer should be able to move agronomic and equipment data into a competing tool. A patient should be able to move health records under HEALTH-02's interoperability principles. A consumer should be able to export photos, contacts, messages, and smart-home configurations in documented formats.

Portability is not enough by itself. If a dominant platform exports a technically valid file that no competitor can ingest, the right is formal rather than useful. The standard should be usable portability: documented schemas, machine-readable formats, bulk export, reasonable rate limits, and no retaliatory degradation after a user connects another service.

The privacy rules have to be built in. Portability cannot become a way for data brokers or fraudulent apps to trick people into moving sensitive data. Consent, authentication, revocation, audit logs, and data minimization are part of portability, not exceptions to it.

Interoperability should target lock-in

Interoperability mandates can be overused. A small product should not face a complex API mandate because it has a loyal customer base. A security system should not be forced to connect with any third-party tool without assurance. But in markets where a platform's value comes from network effects, switching costs, and control over interfaces, interoperability can be the difference between competition and permanent dependency.

The platform should therefore use a targeted standard. Interoperability duties should apply where a market has durable lock-in, user or business data cannot move practically, and closed interfaces block competing services without a specific safety, privacy, or security justification. The remedy should be scaled: data export first, then documented APIs, then stronger standards where a market has become critical infrastructure for commerce or public access.

This approach also protects innovation by smaller firms. Startups and independent shops cannot compete if every device, platform, and data silo requires permission from the incumbent they are trying to challenge. Interoperability makes markets more contestable without asking government to pick the winning product.