Printer lock-in is not implemented in the printer. It is implemented in the driver you have to install and the consumable you have to buy. That is why the portable part of any printing stack is the command language: a documented set of bytes the printer accepts directly, with no driver or cloud service in between that can be withdrawn after you buy.
Four printer lock-in stories reached the Hacker News front page between March 2025 and August 2026, and every one of them landed on one of those two chokepoints.
Four lock-in fights in eighteen months, all about the same two chokepoints
The headlines, in order:
- "Brother accused of locking down third-party printer ink cartridges" (Tom's Hardware), March 5, 2025, 538 points. A firmware update, third-party cartridges, and a lot of people going through their own printers' update history.
- "Inkjet printer with DRM-free ink will be launched via a crowdfunding campaign" (notebookcheck, covering Open Printer), September 30, 2025, 553 points. The pitch is the absence of a feature.
- "Restore full BambuNetwork support for Bambu Lab printers", May 12, 2026, 671 points. A network stack change on a 3D printer, and users organizing to get direct control back.
- "An ongoing 3D-printer AGPL violation" (LWN), August 26, 2026, 489 points. The licensing end of the same argument.
Two are inkjet, two are 3D printing, and the thread running through all four is the same: the owner of the hardware lost the ability to talk to it on their own terms, because the path to the hardware ran through software or a supply the vendor controlled. Nobody in those threads was asking for a new protocol. They were asking to keep a path that already worked.
A printer vendor has four places to put a control point
If you want to predict where the next fight lands, know the available positions.
Firmware. The lowest one, and the one you cannot route around. Firmware decides what commands exist and which cartridges authenticate. Firmware updates can take a working configuration away after purchase, which is what made the Brother story land.
The driver. The vendor's code on your machine, translating documents into whatever the printer expects. The most common control point, because it is also the most legitimate: without it, generic printing does not work. It is also the one that quietly decides which operating systems you can use and how long the printer stays supported.
The cloud account. Newer, and the one that changes ownership most. If the printer will not accept a job until it has checked in with a service, the service is part of the product, and products get discontinued.
The consumable chip. Cartridges, filament spools, ribbon. Chip authentication turns a purchase into a subscription with extra steps.
Note which of these are software. Three of the four.
Industrial label printing mostly dodged this, for a boring reason
The reason is that the command language is written down and multiple vendors implement it.
| Language | Origin | Who speaks it |
|---|---|---|
| ZPL | Zebra Programming Language | Zebra, plus many non-Zebra thermal label printers that implement it for compatibility |
| EPL | Eltron, older Zebra line | Older and entry-level label printers |
| ESC/POS | Epson's command set for receipt printers | The de facto standard across receipt printers from many vendors |
A label printer that speaks one of these needs no vendor driver to do the thing you bought it for. You open the device or a raw operating system queue, write bytes, and the printer prints. There is no rendering step to intercept, no PPD to go stale, no account to check in with.
This is not virtue. Their customers are warehouses running software written by third parties, and a warehouse that cannot generate labels from its own ERP does not buy the printer. Openness at that layer was a commercial requirement.
The practical consequence is large: the same 4x6 ZPL you generate today will very likely print on a different vendor's printer in five years. The same cannot be said for a document that goes through a driver. We covered that tradeoff in ZPL versus PDF for shipping labels.
Windows is about to make the driver layer thinner, which cuts both ways
The driver control point is shrinking on the platform where most label printing happens.
Microsoft's Windows Protected Print mode, available in Windows 11 24H2 and Server 2025, is off by default and can be enforced by group policy. When it is enabled, it uninstalls printers that use third-party drivers, removes those drivers from the driver store, blocks new third-party driver installations, and prints only through the built-in IPP class driver, which Microsoft calls Windows Ready Print. It is designed around Mopria certified printers.
Alongside that, industry summaries of Microsoft's published plan describe a timeline: from January 15, 2026, new third-party printer drivers are no longer published to Windows Update for Windows 11 and Server 2025 and later; from July 1, 2026, Windows prefers the inbox IPP class driver for new printer installs; and from July 1, 2027, third-party driver updates are limited to security fixes. Existing drivers keep working, and vendors can still ship installers outside Windows Update.
For anyone worried about driver lock-in, that is a reduction in vendor control. For anyone printing labels, it is a warning.
Mopria and IPP Everywhere standardize the document path: send a raster or a PDF, get a page. They do not standardize the label path. Cutter behavior, darkness, print speed, media calibration, and the label languages themselves are vendor territory, and many thermal label printers are addressed on Windows as raw queues installed by a vendor driver. If that driver will not install on a machine with Protected Print enabled, the raw queue is not there either.
We are not going to tell you which models break. We have not tested a meaningful sample under Protected Print, and anyone claiming a general answer is guessing. The testable question is narrow: put one representative machine in the state your IT department is heading toward, enable the policy, and print your actual label. Do it before the policy arrives.
Four questions to ask before buying a printer you intend to automate
Ask them in this order, because the first subsumes most of the rest.
- Is the command language published? Ask for the programming manual as a PDF, by name, before you buy. If the answer is that their software handles it, the software is the product and the printer is a peripheral of the software.
- Does a raw or generic queue work? Can you install it on your operating systems without the vendor's own installer, and write bytes to it? On macOS that means a raw CUPS queue. On Windows it means a generic or text-only driver plus the spooler.
- Does it speak IPP, and does it advertise itself? Useful even if you plan to send raw bytes, because it is the path that survives driver retirement for document printing.
- Does it require a cloud account to print locally? If yes, price in the day that service is discontinued.
A printer that answers yes, yes, yes, no is one you can still automate in ten years.
The honest caveat: a documented command set is not an open standard
ZPL is Zebra's language. Zebra defines it, extends it, and owes nobody compatibility. ESC/POS is Epson's. Other vendors implementing them is a market outcome, not a guarantee, and implementations differ in the corners. Firmware still decides which commands your unit honors, and firmware still updates.
Raw bytes cost you things too. You give up the operating system's document pipeline, and with it font substitution, page scaling, and the per-printer options a driver exposes. You take on knowing the printer's resolution, because a label authored for 203 dpi comes out at two thirds size on a 300 dpi printer and there is no layer left to save you. For a multi-page invoice, a raster through a driver is the right answer and raw ZPL is not.
So the claim is narrower than "raw languages are open." It is that among the four control points, the command language is the only one where your code talks to the hardware with nothing in between that a server can revoke.
What this looks like in a print API
RocketPrint is a remote printing API and desktop Station for software platforms: your backend POSTs a print job, and a small app beside the printer prints it, with no inbound networking, no drivers for raw label formats, and a durable job record.
We took the position above literally. Raw jobs arrive as raw_base64 and go to the operating system's raw path without interpretation: on macOS through CUPS with lp -o raw, on Windows through a native Winspool helper. We do not parse your ZPL, which means we also cannot fix it, and a malformed label prints as garbage rather than returning an error. Printer IDs stay stable across renames, so renaming a queue on a Windows box does not break your integration.
And we are on the other side of this argument too: we are one more piece of software between your backend and your printer, and we run as a service. If that is the control point that worries you, read designing for the day your vendor is down. The short version is that the raw bytes you generated are yours and will print through any path that can reach the queue.
For which format avoids driver behavior, see printers and formats. To see the raw path end to end, the first ZPL label walkthrough and the quickstart are two curl commands long.
END / printer-drm-open-hardware-raw-languages
More field notes →