Thanks for the explanation, very helpful.

Are there any issues with silicon solar cells that make them (protected against visible light, obviously) unsuitable? Compared to power silicon or anything for computation you can get enormous area for relatively little money.

Does radiation detection(with actual accuracy, linearity, and repeatability, not just a quick demonstration that you can add some noise to a webcam by pointing a small sealed source at it) have currently good, or at least promising for the not too distant future, solid state options?

I'd imagine that for cost, robustness, and duration on battery power, the presence of little gas filled tubes, some with fairly delicate internal structure, that require a high voltage power supply is a necessary evil at best. In the case of a scintillation counter, the photomultiplier tube would be a similar headache.Are there better behaved options?

FTDI didn't choose that specific value(though, thinking back to Intel's amusing choice of '8086' as their PCI vendor ID, you probably can choose a VID if you push hard enough or have a cute reason); but there are still some commonalities(though arguably some differences as well):

The USB spec (and, probably more importantly, USB as implemented on basically all commercially relevant systems) supports essentially two mechanisms for telling the OS what driver your device requires:

If supported by a generic class driver; your device descriptors include a bDeviceClass field containing a defined USB device class code; but isn't 0xFF(which is valid; but means 'vendor defined'), a bDeviceSubClass field with a valid subclass code, and a bDeviceProtocol field with a valid protocol code.

If your device is supported by a specific driver(or one of the hybrid arrangements, not uncommon, where a versatile device class like USB HID will be used to do most of the low-level work; but a vendor-specific driver will implement whatever device specific behavior is offered on top of that), then you need to supply the correct VID/PID combination.

Now, let me be clear, I see absolutely no reason why FTDI should need to provide driver support for clones, so even if Windows(correctly, as an OS) responds to a USB device with an FTDI VID/PID by loading the FTDI driver, it is fully within their rights to have a driver that detects and ignores non-FTDI parts.

However, (and this is where the analogy to consoles and trademarked-but-technically-necessary really comes in), the USB spec does not offer a 'compatible with VID/PID' device description option. Either you specify the appropriate generic class, or you specify a VID/PID and a vendor-specific class. There is no other way (barring atypical configurations and kernel hacker tricks that aren't of much use in the wider world) to do it.

If you want a Game Boy or whatever to load your cartridge, you need that logo to be present at the appropriate address. If you want to specify "I need the driver that supports device X", you have to supply device X's VID/PID. There is no 'compatible with device X; but actually made by me' mechanism.

If you are buying fake FTDI gear to take advantage of FTDI's driver devs, then I have no pity. Not FTDI's problem to support you. However, there are 3rd-party FTDI-device-supporting drivers (notably on Linux and BSD, maybe somebody has ported one to Windows or OSX, maybe you plan to implement your own, whatever) that it would be perfectly legitimate for an FTDI-compatible device to request, and (so long as it doesn't involve copyright or patent infringement, or fraudulent misrepresentation) there are perfectly licit non-FTDI chips that implement FTDI-compatible behavior. The USB-IF certainly doesn't have enough power over short hex values to stop that; and I'm not convinced that we would want them to.

A large number of now standard or semistandard devices, protocols, and command sets we don't even think about today started life as dirty clones of the more popular brand: The PC BIOS, the (still spoken, in extended form, by a moderately alarming number of things) Hayes command set, the 16550 UART (originally a National Semiconductor model number; now register compatibility with those is practically a standard in itself, thanks to about a zillion clones), the NE1000/2000-compatible NICs that helped make ethernet ubiquitous and cheap...

Again, FTDI has every right to make the use of their drivers contingent on the use of their ICs (or some other licensing terms, if that amuses them). Also, non-FTDI parts being sold (with varying degrees of sophistication, from pure nonsense to nearly perfect fakes) as FTDI is a bad thing. For FTDI, for the buyer being defrauded, for the electronics supply chain generally.

However, we would not be well served to be blinded to the (generally desirable and helpful, as much as incumbents dislike them) history of 3rd-party interoperable parts by lumping all of them in with 'counterfeit' parts and taking measures that make it easier to suppress them, and easier for 'counterfeit' to mean 'compatible with someone who doesn't want you to be compatible with them' rather than to mean 'based on illicitly copied designs and/or sold under fraudulent label'. These are two very different things.

They could make the argument; but I'm not sure that they could win it.

It is widely accepted that you can use a protected mark, so long as you don't do so deceptively, to provide information about your product(the usual formulation is "Store brand product, compare to Product(tm) active ingredients). Not a trademark violation, even if the trademark holder might not like it; just telling the customer what your product is intended to be compatible with.

In computing applications, since the data are usually being sent to an (often inflexible and buggy) program rather than to a human, and since identifying information is often necessary for operation, even more blatant use is often accepted. Most browsers still claim to be "Mozilla/5.0" followed by a bunch of other stuff, often equally trademarked and equally false, because that particular string was the only way to get the correct output from assorted crufty HTTP servers. In more adversarial cases, like Lexmark's battle with Static Control Components over toner lockout chips, SCC ended up being allowed to duplicate an even larger chunk of Lexmark's firmware, over Lexmark's objections; because that was deemed a technically necessary part of producing an interoperable toner cartridge.

The USB VID/PID is conceptually in a similar position to the browser UA: it's not hard to find; but not really there for human readers and subject to fairly specific technical limitations if you actually want it to work. "0x0403" is a valid VID. "0x0403 (compatible; China Cloneshop)" is not. It won't even work, much less request the correct driver. USB does provide for purely descriptive, human readable, information fields ('Manufacturer String Descriptor', 'Product String Descriptor', and 'Serial Number String Descriptor') and those aren't subject to technical constraints.

I certainly wouldn't want to be on defense if I were selling a product with somebody else's trademark misused in the string descriptor fields; but the VID/PID would be much more defensible.

Why not? The USB IF won't be happy about it, and not being able to trust VID/PID pairs makes driver devs sad and prone to resort to ugly fingerprinting heuristics; but none of that establishes a legal monopoly on "0x0403" for FTDI.

That isn't actually so clear:

According to the die shots, the clone chips' implementation is more or less entirely different from the FTDI implementation. Intended to be pin-compatible, and exhibit the same behavior; but totally different silicon, not a cut and paste job.

The clones that are then labelled and sold as 'FTDI' are, certainly, in all kinds of violation of trademark law; but what of any that are just blob-topped or generically packaged and not represented as being actual FTDI? Not something FTDI likes, or is obliged to provide driver support for; but neither was the Compaq 'IBM PC compatible' BIOS.

Even if the (typically very harsh, though widely unenforced) laws regarding trademark infringing goods do actually allow FTDI to brick them in the field, they haven't actually established that a given chip is a counterfeit, rather than a mere clone, before bricking it. Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.

I can only imagine that the lucky guy who picked up the call from Redmond about 'so, we understand that you...made a few changes...to the behavior of your WHQL drivers that frankly don't make Windows Update look very good...' got quite an earful.

Even if MS thinks FTDI is on the crusade of the righteous, it certainly isn't to their advantage to have Windows Update involuntarily pulled into the fiasco.

Why keep it civil? Seems only fair for whoever came up with this plan to spend some time stamping out license plates for Uncle Sam.

Unless you are the sort of disconcertingly disciplined and organized person who sets up a monitoring and alerting system for their dinky little desktop, you probably aren't talking about 'the hard drive'. At a minimum, you are probably dealing with some flavor of RAID, or ZFS, or an iSCSI LUN farmed out by some SAN that does its own mysterious thing behind the expensive logo, or some other additional complexity. Flash SSDs are also increasingly likely to be involved, quite possibly along with some RAM caches in various places.

According to the eevblog report, the newest driver behavior involves reprogramming the USB PID of the target to 0, not merely refusing to do useful work with it.

Quite likely recoverable with some knowledge, unless it managed to close the door behind it on any future PID modifications; but munging a USB device's PID is definitely a step above simply refusing to talk to it.

It is quite likely that the counterfeiters(at least the ones that actually stamp 'FTDI' on their products, or represent them as FTDI parts, I'm unconvinced that a VID:PID pair is a trademarkable thing) are committing 36 flavors of trademark infringement; but that still doesn't make it obvious that FTDI can just go all vigilante justice on them(much less on random people who may or may not know they were even using counterfeit chips).

Even when something is clearly recognized as a crime, the courts tend to take a somewhat dim view of those who go and dish out some extrajudicial punishment for it (typically with exceptions for things like self defense). Even when the law specifically defines transgressions that create a private right of action, the 'action' usually involves getting to sue the target, not take matters into your own hands.

A certain amount may end up riding on the meaning of 'component' and 'that component', as well. Sure, for a basic USB -> serial dongle the FTDI chip is practically the only component, with just a couple of cheap connectors and a passive or two; but there are some fairly expensive devices that are 'USB' because the manufacturer shoved a converter IC onto the previous generation serial design.

Even if FTDI finds a court that buys their right to destroy cloned chips by vigilante action(rather than by a copyright, patent, or trademark judgement in the appropriate venue), will they find one that is sympathetic when the device ruined is some fairly expensive bit of gear sold by a third party to a customer who didn't even know a USB bridge chip was involved?

Even if you happen to think that FTDI's approach is morally justified and hilarious, it'd still be worth considering avoiding them: some counterfeits don't even bother to pretend; but there are some very, very, convincing fakes that manage to sneak into more respectable parts of the supply chain. It's bad enough that you might get slipped counterfeits that don't meet spec, worse if you might get slipped counterfeits that appear to work and then get destroyed once in the hands of your customers.

To pretend that the governing behaviors have a substantial correlation with the alleged governing philosophies is...empirically tenuous at best.

I imagine that it also helps (at least in terms of customer acceptance) that most of these RFID tags are probably replacing something that was as bad or worse. Keys are clonable, provide no record of use(much less timestamped logs of individual users) and if one gets into the wild re-keying the place is Not Fun. Magnetic stripe cards are trivially clonable; but on the same level as most RFID tags in terms of access logging and enabling/disabling access. Adequately rugged optical sensors have historically been pretty expensive, so bar codes, hand scanners, and any other biometric gimmicks are likely niche players.

I'd be pretty annoyed if some salesweasel lied to me about it; but it's unlikely that an RFID installation replaced something that was harder to clone, and it's still easier than keys, slightly more robust than mag stripe readers, and reasonably cheap per tag. In some ways that makes it even more obnoxious to harass the researchers, though.