FTDI, or how to run a company into the ground using DRM

And why they should get the book thrown at them

FTDI is a UK-based niche-player in the semiconductor market that used to be rather well-known in embedded systems circles for its high quality USB-to-serial controller. Wait, what? Serial, isn’t that the cheap way of linking stuff (usually through 9- or 25-pin connectors) that fell to the wayside when USB became affordable? Internet aeons ago, when people were waiting in line at night in front of shops in order to buy Microsoft’s latest and greatest OS? Yes, indeed, since a lot of hardware out there contains components won’t talk USB directly and are not meant to do so since that would be complete overkill. Especially in the world of CNC-machines and all sorts of little pieces of dedicated equipment, serial communications are pretty common, although often not with the connectors that we used to use till USB came along. But the computers that are connected to these gizmos do no longer have an external serial port, so enter the USB-to-serial converter, either included in the gizmo itself or as part of a converter cable as depicted in the background of this page.

FTDI is kind of the go-to brand in this niche market and as is often the case with market leaders, they face competition from imitators. In the case of FTDI imitation from suppliers that have replicated the functionality of their chips to the point that they present themselves on the USB-side of things with the USB-manufacturer- and device-IDs of FTDI and function similarly enough that they are fully compatible with the FTDI device drivers for Windows, Linux and OS X. Another form of competition comes from outright copies of the chip itself, clones in other words.

So you have roughly ten flavours of FTDI-compatible devices:

1. Genuine FTDI chips sold as such;
2. Genuine FTDI chips incorporated in third-party products;
3. FTDI-clones emblazoned with a FTDI logo and sold as such;
4. FTDI-clones without the FTDI logo and marketed as “FTDI compatible”
5. FTDI-clones with the FTDI logo and incorporated in third-party products;
6. FTDI-clones without the FTDI logo and incorporated in third-party products;
7. FTDI-compatibles emblazoned with a FTDI logo and sold as such;
8. FTDI-compatibles without the FTDI logo and marketed as “FTDI compatible”
9. FTDI-compatibles with the FTDI logo but incorporated in third-party products;
10. FTDI-compatibles without the FTDI log and incorporated in third-party products.

FTDI is thoroughly unhappy with the glut of cheaper chips, so it decided to take Digital Restrictions Management (DRM) to the extreme: it released an update to its Windows device drivers that attacks FTDI-compatible chips (but not FTDI-clones). It does that through very clever use of a feature of its own product: FTDI chips (and their clones) ignore data written to uneven addresses in the memory space of the chip. FTDI-compatible chips do not ignore such data and will execute code written to those addresses in concert with code written to even addresses. The combination written by the FTDI-driver resets the device ID to zero, a value that will result in the chip being ignored by most contemporary operating systems, effectively disabling the serial communication with the device.

The net result of this exercise is that this driver update will brick any device that incorporates an FTDI-compatible chip, but not full-on clones. FTDI has acknowledged this behaviour and justified as ”protection of their IP”. Sadly their tweets saying so have recently been deleted, what remains now is a half-hearted apology and a promise for a new driver that won’t exhibit the behaviour of the current one.

This behaviour of FTDI, no matter how painful it must be to see their market being flooded with counterfeits by unscrupulous copycats and also-runs that jump on their bandwagon, is stupid from a business perspective and a legal perspective.

First the business perspective: from the above list of cases, nrs. 3-7 and 9 above, are FTDI’s worst enemies: they are true counterfeits that are obviously hurting their bottom-line and infringing on their IPR. However, this driver bricked nrs. 7–10, but not nrs. 3–6. So they went after a group that for the most part is less likely to take away sales from those willing to pay the premium for the real deal. Moreover, it signalled to anyone in the market that they shouldn’t touch anything implementing their API since it might become bricked when attached to a PC running Microsoft Windows. Given that it often is hard to distinguish counterfeited chips from genuine ones, it means that this is likely to cause customers away from anything reeking of FTDI to competitors that have a different API and different USB vendor and product IDs. This is also known as shooting into one’s own foot.

And now for the legal perspective: regardless of whether something is a counterfeit or not, in hardly any jurisdiction end-users are liable for the posession of counterfeit goods. And even if they were, that would not necessarily result in a right of the rightsholder to damage goods. And to what constitutes a counterfeit: FTDI-branded chips that aren’t manufactured by or on behalf of FTDI are clearly counterfeits on their own. So are literal clones of their chips. But it already becomes more fuzzy if they are incorporated in another device. Especially when done in good faith and subsequently sold on to end-users that are acting in equally good faith. Something a driver cannot possibly assess, even if you were of the position that a trademark owner would be justified in taking harsh action against end-users, which is not how trademark law works in general. The primary function of trademark is to prevent confusion in the relevant market. Incorporation of FTDI-branded chips in products that are branded differently, even if the chip is still visible, is unlikely to confuse consumers. So that category is out. Leavesus FTDI-branded chips that are marketed as such: trademark law protects the trademark owner against its competitors, not against its end-users.

It becomes more complicated when we are talking about FTDI-compatible chips that aren’t FTDI-branded, because then the main question is: is the API or the USB ID protected. In either case the only right that might apply is copyright. Ever since the SAS/WPL decision Court of Justice of the European Union APIs are granted a very low level of protection under copyright law within the European Union (which the United Kingdom, where FTDI has its headquarters, is still part of). Similar legal questions are playing out in the Google/Oracle case that is still ongoing in the United States.

But what about the USB vendor and product IDs, surely FTDI paid for those and action against those must be justified? The problem here is that we are no longer talking about intellectual property rights (IPR), but possibly about passing off, misappropriation and/or slavish imitation. Which are concepts from competition law and again can be used against unlawful competition, but not against end-users.

Not to mention that all these rights are primarily meant to be enforced through courts. Courts that typically frown upon vigilante justice. Especially vigilante justice that amounts to the intentional creation and distribution of malware. Something that is a criminal offence in the industrialised world. If anything, I hope that an English prosecutor will look into this and take action. Given the general enthousiasm for prosecution of relatively minor examples of computer-related offences in support of Wikileaks, this should be a walk in the park, shouldn’t it?

But what should FTDI have done then? If anything, there are strong measures to enforce trademark law in place in much of the industrialised world. The only real difficult country for enforcement is China, and even that situation has changed significantly in the past decade. It should have gone after distributors of counterfeits. And as for the abuse of their USB vendor and product IDs? If you can detect those chips in your driver, don’t brick them, just let the driver refuse to work with them. Preferably while notifying the user.