The device certainly is put into a reduced functionality mode but it isn't (rendered non-functional) as it still functions and you can still use it if as you said you know what your doing. FTDI does have an IP claim to the driver and a non-official device talking to the driver might get asked to go jump in a lake and while it definitely is a form of DRM the real FTDI chips say nope not jumping in the lake while the other fake one does and since they were not really evil and didn't use the actually damaging config options you can still get the clone to buddy up with the FTDI driver by locking them in a room with no lake.
If the device is put into this reduced functionality mode, and can't be used for its intended purpose until it is fixed, then it is non-functional. Period. It cannot function until fixed, hence non-functional. Yes it can be repaired from this non-functional mode, and made to function again. I'm even willing to say its not damaged, others would take the view that since its not easily fixed by the average user of the end product, then for all intent and purpose it is damaged or destroyed. Yes you are very skilled and can fix or solve this problem in the blink of an eye, but that doesn't mean it didn't exist. If I had to hire you to diagnose and fix this problem you would be looking to get paid right?
FTDI did prevent their drivers from working with it post and present. Just because security didn't exist before doesn't mean FTDI/HDCP can't block a device after the fact by revoking the numbers in hardware. Revocation lists are exactly for that (Every disc, device, ... has the latest version and they automatically update devices nearby even if that means the device should no longer advertise HDCP compliance). HDCP 2.2 is going to be even more "fun" I'm sure of that. (Given how every rev was compromised sometimes massively they are not going to play nice that is for sure)
FTDI could have prevented their drivers from working without changing the PID. It they wanted to have a revocation list, then FTDI's driver could detect a clone (restoring any EEPROM changes they made), and then store the clone's serial number and refuse to load the FTDI driver for it. Something that I believe would be legal (some people may contest this point, I will not, I think its acceptable).
You either change the driver to not function with the clone, or you change the clone to not function with the driver. I believe the former is likely legal, while the latter is likely not.
1. A change to the clone's PID for no other reason than to render clones in-operable (non-functional) for the time being or until they're fixed is likely to be illegal. I think its a fallacy to consider this a revocation, because you modified the clone in a way that in its current state it would not function with 3rd party drivers in other OS's, until either the device or the 3rd party driver is 'fixed'.
2. A change to FTDI's driver to prevent it from functioning with clones is likely legal. Such as having the FTDI driver store the clone's serial number, and refuse to work with it in the future. This would be acceptable in my mind, and I would consider this an implementation of a revocation list.
I don't think this argument is unreasonable, and I suspect many would agree. I am sympathetic to FTDI's plight, and clones do need to combated, but this should be done in the supply chain, not by involving unsuspecting end users. And at the very least, the fact that a clone was disabled (made non-functional) should be reported, not done silently.
The device is still functional and reduced functionality just means its not as easy to use, anyone can just force it to work with the driver as a workaround while they sort things out. I used the slmgr -rearm when windows activation went berserk one time on windows for no good reason and that isn't exactly command everyone knows about automatically. WGA false positives where harder to fix and wasted far more time. The FTDI driver issue is a joke to fix, their guides even tell you how to do it. Some uses don't even have the default PID/VID combination so they wouldn't even notice even if they have fake clone devices.
You wouldn't need to pay me those are so easy to fix and I always get emails from family asking for all manner of simple to fix computer problems. I charge money for support that requires me to visit onsite or write new code/... (Free level of support I provide for any previously paid work is also a given if someone uses my code I stand by it and even if an FTDI driver, windows problem, ethernet misconfiguration, and even a dumb user... affected it I can at least help point them in the right direction for free) I work on the principle that I will provide limited free support by email but if you want timely and defined support it costs money. (Any bugs that are clearly my fault I will also correct for free obviously) I don't exactly charge people after the answer is oh the cable was plugged into the wrong device or the dial was in the wrong position. The FTDI issue is remote desktop detectable/fixable so can easily be under my free support level of fixes. (So no I would not charge you as I would first ask to check remotely before spending money on a site visit which I would have to charge because it cost money to go somewhere and I can't tend to other tasks at the same time when I'm on site)
To me, obviously different than others for something to be "broken" or rendered non-functional it has to require physical repair. Software/driver issues are the norm for me and its just part of the day for me, bad drivers, mean companies, stupid users, ... (As long as I can do it remotely I don't really care). Plus I've seen CAD system say oh your license is in use by someone else I'm just going to crash now instead of letting you save your work say goodbye to those hours of work you just put in because you only have a handful of licenses on the network and for some reason I can't just tell the newest user that there is no free licenses. (The software also had no auto-recover/save feature, and after that I saved every half hour, saving too much can corrupt the file... also no undo, it was a wonderfully "fun" software to use, it was really old to be fair)
Just never let those Indian remote support "Microsoft Tech Support" people get to you. They call me every month or so and I lead them on for as long as they don't notice. I reported them a lot but there isn't much to be done short of setting up a honeypot system (which is in progress) to get more info to report to the legitimate software companies getting tarred by fake support tech call scams. (Remote desktop is powerful stuff)
1) Revocation is valid as it is a updated number that is written to flash memory. If HDCP decides a real legit device should no longer work with anything they have the ability and have in the past done so with no legal challenge. The literal system for HDCP updates is any new device or blu-ray disk has updated revoked device keys and any compliant device should commit them and enforce them even if that means the device itself should invalidate itself. (This as FTDI's driver is all automatic) The drivers do still work with non default VID/PID combinations and the fix is simple vs the very complex hoops to fix HDCP problems (Which includes replacing hardware).
2) FTDI's drivers do not work with clones (past/present) is probably what they intended (which is what the PID revoking did) but it would be far nicer to say please do not use old drivers and clones won't work anymore at all. (But allow people to use it unofficially and unsupported)
(FTDI doesn't control the serial number process for the clones how do they ensure that the clone won't cause a conflict with a real device that collides with the SN#)
FTDI also has no distribution method to ship a revoked device SN list with their drivers or update them automatically and that would just add bloat that legitimate users don't need and would be even more like HDCP. The PID change is revoking access without the need for complicated and very abuse prone revocation lists.
Illegal clones should be rooted out and in the end of all this they shouldn't exist.
I wholly agree that FTDI is very stupid for on how they handled this. And think the PID change is dumb/bad but not illegal because it works very similar to HDCPs systems where devices are subject to automatic updating, revocation, disablement.
I would have just given tools to let people check chips months ago, then inform users of their plans to counter use of clone chips with official drivers, and then provide detailed instructions on what is going to happen and what to do if your affected. Then after everyone is ready press go and everyone won't be surprised and they will know how it works, what it means, how to fix it.