[tmp26]

I don't think so. There was at least one guy in the thread who reprogrammed the PID back, and the chip worked with the old FTDI drivers again, which means the USB interface was working just fine (or else how could he access it to change it back).

[wtallis]

Having to write custom driver-level code to repair something falls pretty well inside the accepted usage of "bricked". It's only marginally easier than just hooking up a JTAG interface.

[bravo22]

They change the PID to zero, which means Windows won't associate it with FTDI or any other driver. You have to jump through some manual hoops to undo it, which is something most people can't do. So for all intents and purposes it is bricked, a.k.a "locked out".

[tmp26]

Most HN'ers seem to agree it is OK for FTDI to prevent their own drivers from working with the fakes, right? The fact that there are no OTHER drivers that are compatible (no matter what the pid is) with the fakes isn't their problem, is it?

[the_ancient]

It is ok to have SOFTWARE that refuses to work

It is NOT OK to modify the HARDWARE in ANY WAY, including changing the PID.

That is the issue.

Further Most people defending FTDI assume this code will be 100% pure and never incorrectly identify a real chip as fake, I find that claim to be suspect.

Lastly I would find it very hard to support vendors that take these aggressive risks and stances, I certainly would never incorporate a device from a manufacturer that uses these types of tactics into a mass produced product.

[jessaustin]

Honest question: are you participating in this thread as a greenbean because you want to hide your identity from harassment from those who disagree with your unpopular opinion, or because you want to hide the fact that you are affiliated with FTDI?

[tmp26]

Honestly? I rotate accounts on most major sites periodically. It is a tinfoil-hat foible, a way to distance myself from the exceedingly dumb things I have almost certainly said in years past.

Unfortunately for me, I chose today to rotate.

I don't work for FTDI; I'm not even British. But I did build that Adafruit altoid tin MP3 player eight years ago, which used a FT232.

Why am I wasting my time on this argument? I don't really know, aside from I hate the "internet dogpile" effect.

My credibility as a greenbean is nil of course, but oh well.

Edit: obviously folks do not believe me. Serves me right for trying to answer. jessaustin, I hope you at least feel like you got your answer. I get the feeling it doesn't actually matter what I say or even who I really work for- I'm branded.

[eksith]

I didn't downvote any of your posts and I believe you when you say you're not affiliated with FTDI. But I vehemently disagree with your stance that the sabotage of hardware is warranted or even that it's a minor inconvenience.

Let's take this from another point of view:

You purchase a device or some piece of hardware for a project which becomes useful to others and you decide to make the project marketable and release your own line. You source your components and one of them happens to have an FTDI chip that you believe legitimately came from the company. Your project is accepted by others and everyone is happy.

Then one day, your supplier decides to switch out a source for the chip in one of the components of your project to one that's cheaper (the supplier may not suspect these are counterfeit). You don't see any difference either as you haven't tested it with the latest driver, which may not be out yet. The project is now shipped.

A new driver is released. An overwhelming number of customers now hit your support system saying the update has stopped your project cold. Rolling back the update has no effect. You don't know which component caused the problem as your project uses several from different suppliers. It may take days or even weeks to track down the problem, but meanwhile, your customers grow angry.

This is now your fault and you're left holding the bag.

This scenario need not be hypothetical, as this is just the same as GM "fixing" a problem with their ignition switch that has already claimed lives, but leaving the part number the same. This makes recalling a nightmare as there's now no way to tell which cars are affected until the switch fails or someone dies again.

Just the same as there's no way to tell which one of your project's components carry counterfeit chips and you need to issue a recall for potentially 100K units since you don't know which ones carry a counterfeit and there's no software fix anymore as the chip is bricked. Your project is also potentially being used in mission critical infrastructure that cannot be shut down to do a test without costing a lot of money. Better hope no one follows "best practices" and updates the driver as it may also contain a security fix.

FTDI is well within their rights to protect their product. But are they doing the ethical thing by costing unsuspecting customers and potentially hundreds of other businesses that rely on their product valuable time and money? All for not knowing that somewhere along the supply chain, someone cut a few corners and got their chips from a counterfeiter? Should they be victims twice; once by the counterfeiter and again by the company?

[jessaustin]

I hope you at least feel like you got your answer.

Yes, I take this answer at face value. I didn't really think there were only two possibilities here. Perhaps I was a bit blunt in the hopes of eliciting a "real" answer like this one.

[nknighthb]

It's interesting that you're more eager to dispel the notion that you work for FTDI than that you support the crime of destruction of property. You need to think long and hard about the direction of your moral compass.

[Dylan16807]

It's asshole behavior to put code in their drivers specifically to detect and abort even trying to work with fakes, but they are fully entitled to do so.

They are not entitled to break the hardware by changing the PID so it doesn't work with any drivers.

There are other drivers that work when the PID is left intact.

[wtallis]

Well, FTDI is leaving their vendor ID intact, and given their behavior so far it wouldn't surprise anyone if they tried to interfere with third-party drivers that enabled using non-FTDI hardware identifying itself with FTDI's vendor ID.

[tmp26]

According to the thread the VID is RO?

[wtallis]

So? Does anyone actually think that fact will somehow make FTDI want to be more reasonable? They'll just say that those devices being hard-coded to spoof FTDI's VID is further justification for mistreating them.

[mortenlarsen]

There are other drivers, on other operating systems that are NOT written by FTDI.