A solo developer used Rust and Claude Code to build what Linux users have needed for years: a proper, open-source kernel driver for USB DisplayLink docks. Synaptics responded with a cease-and-desist, over 125 patent citations, and financial demands escalating at $25,000 per week. The repository is offline. And here is the part that should concern every developer building tools that touch proprietary hardware: the code was clean-room. Mike Lothian did not copy a single line from Synaptics. Under copyright law, he was untouchable. Under patent law, he had no defense.
The Problem Vino Was Solving
If you have used a USB DisplayLink dock on Linux, you know the experience: it works until the next kernel update, then it doesn’t. Linux support for DisplayLink hardware has always depended on two components. The first is EVDI, an open-source kernel module originally developed by DisplayLink itself. The second is DisplayLinkManager, a closed proprietary daemon that handles the actual video encoding. EVDI is GPL and freely available. DisplayLinkManager is a binary blob that breaks on major kernel versions, is unauditable, and ships on Synaptics’ schedule — not yours.
Lothian’s Vino driver was designed to eliminate DisplayLinkManager entirely. A pure Rust DRM/KMS kernel driver — no proprietary daemon, no DKMS rebuild anxiety, no closed binary in your stack. By version 3 in August 2026, it worked across three dock generations: Ella (DL-3×00), Ridge (DL-6xxx, including the Dell D6000), and Navarro (DL-7400). This was real progress toward first-class DisplayLink support in mainline Linux.
How a Request for Help Became a Legal Threat
In early July, Lothian emailed a Synaptics engineer to flag potential issues and ask for guidance. That email ended up in the legal department. A different Synaptics employee replied to say the concern was not the Rust rewrite itself — it was DisplayLink’s protocol and codec, which Synaptics believes are covered by patents.
On August 17, the formal cease-and-desist arrived: stop development, withdraw all submissions, sign a confirmation by August 28. The letter cited over 125 patents without specifying which ones applied. Lothian asked for specifics. In October, Synaptics provided claim charts mapping two UK patents — GB2484736 and GB2485613 — to his source code. They also billed him $25,000 for the cost of preparing those charts, with the amount increasing by at least $25,000 per week if he missed the October 11 deadline. Lothian offered to pause development and negotiate a non-commercial license. Synaptics declined and set a final deadline of October 18.
The repository came down. No lawsuit was filed. Synaptics won without entering a courtroom.
Clean-Room Is Not the Shield You Think It Is
The headlines have leaned into the AI angle: “developer used Claude to write a Linux driver.” That framing is misleading. Claude Code is a tool, the same way a compiler is a tool. It doesn’t change the legal analysis. Synaptics never claimed Lothian copied proprietary code. They claimed he implemented a patented method — and those are fundamentally different claims.
Copyright and patent law operate on different tracks. Clean-room design defeats copyright infringement because it proves independent creation. Copyright protects expression, not ideas or methods. But patents protect methods. If your code implements a process covered by a valid patent — regardless of whether you wrote every line yourself, used AI assistance, or reverse-engineered the behavior from USB traffic — you infringe. Independent invention is not a defense to patent infringement. It has never been. This is not a quirk of AI-era law; it is how patent law has worked for decades.
Developers building open-source replacements for proprietary hardware protocols tend to think about this problem in copyright terms. That instinct is wrong in environments with active patent portfolios.
OIN Did Not Save Him Either
Lothian registered as an Open Invention Network licensee on August 17 — the same day the cease-and-desist arrived. OIN is a patent cross-licensing pool that protects the Linux ecosystem, and Synaptics joined as an OIN member when it acquired DisplayLink in 2020. On paper, this should have provided some protection.
It didn’t. OIN’s Linux System Definition excludes audio and image codecs unless they are expressly listed in an exceptions table. DisplayLink’s DL3 display encoding technology falls into the codec category. OIN investigated and concluded that its protections did not extend to Lothian’s kernel contributions because of that exclusion. Broad participation in OIN is not a patent-safe guarantee for every corner of the Linux stack.
What This Actually Means
The AI angle is a distraction. The real story is simpler and older: hardware vendors have discovered that patents can permanently block open-source interoperability, and they can do it without filing a single lawsuit. The playbook is straightforward — release an open kernel module for optics, keep the codec patents quiet, let the community do your testing, and when someone goes further than you want, send a letter. The asymmetry does the rest. A solo developer cannot fund patent litigation against a company with a legal department. It doesn’t matter how strong your prior art arguments are.
USB2-era DisplayLink hardware had functional community drivers. USB3-era hardware, with its newer patent portfolio, does not — and probably won’t. This outcome was not an accident.
If you are building an open-source replacement for proprietary hardware protocols, check the patent landscape before writing a line of code. Verify your specific use case with OIN — membership and the codec exclusion are separate questions. Understand that clean-room methodology addresses copyright, not patents. And if you email a hardware vendor’s engineer asking for guidance, that email may end up in their legal department. The full correspondence is on LWN.
