Can we be sure that FTDI has programmed their driver with malicious intent? It may be that this an accidental side-effect of using counterfeit hardware with a genuine driver.
Without access to the source code or a well-reversed disassembly of the FTDI driver, and a good grasp of the logic used in the counterfeit chip, one cannot be certain about this. And surely not to the extent of urging Microsoft to revoke driver signatures.
"Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT."
Even though their TOS might state that, it's extremely poor PR to go after the end user rather than the distributor. Most people won't even know that they have a counterfeit chip. Even though it may be well within their rights the customers will eventually find out what they have done and bear a grudge.
A statement being in a license does not imply intent, it is there to protect them if they accidentally do damage. "may damage rip-offs" doesn't mean "will intentionally damage rip-offs", it means "we won't care if it accidentally does damage rip-offs, we can't test out code against every rip-off on the market, you paid your money you took your choice".
Of course if they have deliberately broken people's hardware that is a different matter, that clause in the license does not give them permission to in any way (either by my reading of the wording, or my understanding of how the law usually works in such cases).
Of course they should roll back the drive and investigate, but what if the problem is due to a new feature that can't be implemented some other way, and there is no way to detect a "genuine" chip? Should users of their chips do without a feature (or have to mess around opting in) because some other manufacturer's chip has a problem with it?
It shouldn't matter what their intent was. If the new version of a network driver accidentally started DDOSing servers, it should also be pulled, regardless of whether the vendor did it on purpose.
If the counterfeit FTDI chips are using FTDI's registered USB vendor ID (I assume they are, otherwise the driver wouldn't recognize them?) I think the blame falls solely on the counterfeit chip makers.
Why? The counterfeits aren't seeking USB compliance certification, they're just trying to provide 100% compatibility. Are you saying that reverse engineering and spoofing for the sake of compatibility is wrong? Or do you think that USB vendor IDs are covered by some trademark?
Seems like there's a few people who don't seem to understand the difference between copyright, trademark, criminal and civil law (op above you included).
The only law broken by the counterfeiters is trademark violation for printing the FTDI logo on their chips. That's it! Everything else they did was legal. Otherwise, Intel and AMD would be bricking CPUs right now.
Reverse engineering is legal.
Emulation is legal.
Creating hardware that's compatible with another vendor's software is legal.
Flashing your hardware with another vendors firmware is legal.
Modifying hardware you purchased from a vendor is legal.
Modifying software you purchased from a vendor is legal.
Going with your example, if AMD uses "Core" or "Xeon" in the name of their chip, it is most likely infringing the trademark of Intel. But in this case, it's more like AMD is simply branding their chip with exact Intel product name and sold as if it's from Intel. I don't think this is a trademark issue any more, it's more like fraud.
Does anyone even know what entity designed and made the fake FTDI chip?
I find many people don't seem to understand what making compatible chip means. It's very common to have legitimate, drop in replacement for popular ICs. But this fake FTDI chip is certainly not the case here.
No, it's trademark and trademark only. Generic medicine puts on the label of their products "compare to brand name XXX." There's nothing wrong with this. As long as you don't impersonate another companies mark. Is it a flagrant violation? Sure. Doesn't change that this is still (only) a civil matter.
Only the distribution, and even then only if the firmware is eligible for copyright protection. Purely functional configuration data like vendor and product IDs aren't copyrightable.
(I'm speaking more from a moral standpoint than a legal standpoint. IANAL)
It doesn't matter if it's trademarkable. The entire purpose of VIDs is to distinguish between different vendors' devices. If I'm allocated a VID it's not my responsibility to ensure my drivers interoperate with other vendors' products.
How many products using counterfeit FTDI chips don't advertise USB compliance?
Intent doesn't matter if the patch is causing damage.
There are legal routes available to FTDI that don't involve bricking devices. I'm guessing that FTDI didn't talk to internal counsel before making this change.
I'll be quite surprised if Microsoft doesn't pull this patch.
marcan:
"In case anyone was still wondering if this is intentional and malicious...
Straight out of their driver. Function/variable naming and comments mine.
I figured out what's going on with the real chips: turns out their EEPROM is written in 32bit units. Writing to even addresses is ignored; the value is buffered and the address discarded. Writing to odd addresses writes the entire 32bits, using whatever value was last buffered for the other half. So both the PID write and the checksum write are ignored on real FTDI chips, as they are both written to even addresses. I still don't know why it works on clone chips though, since the checksum is written to the wrong place (it should normally be on an odd address); presumably they don't check it."
Basically driver is fuzzing 'chips claiming to be FTDI' with illegal instructions. Want to play clone games? better emulate me completely, otherwise tough titties. I like it. Might not work to well for FTDI in the end due to PR nightmare, but from engineering standpoint its quite brilliant.
So, definitely intentional then. They went to quite some effort to fix up the checksum by calculating and writing a suitable value to the address before the checksum location (updating the checksum would cause a write on genuine FTDI chips because it's an odd address). If they'd just written the VID as zero, presumably the checksum would fail and the device would revert to a default, non-bricked configuration.
Without access to the source code or a well-reversed disassembly of the FTDI driver, and a good grasp of the logic used in the counterfeit chip, one cannot be certain about this. And surely not to the extent of urging Microsoft to revoke driver signatures.