If you buy a crippled processor and hack it, I'd guess that Intel has no cause to sue you, precisely because you own that processor. But they don't have to make it easy to hack.

Until Intel distributes a EULA with the processor. If the courts will hold up the validity of a software EULA, why not one that applies to hardware?

...not that I think that this is an agreeable situation. But I am hardly surprised to see things evolve in that direction.

>Until Intel distributes a EULA with the processor. ... written with a very tiny font in silicon.

Just because it has a restriction built in doesn't necessarily mean it comes with an EULA, or that finding a way to enable or otherwise modify the hardware to your whim is illegal in any way (although I'm sure Intel would take a run at the first grey-market unlocks)

As long as they are up front about the cost & features of the product I'm buying I don't care. As a consumer, I don't like this practice, it smells bad - but it's supply and demand. Intel can price their chips however they want, it's up to them to price them in a way that's the most profitable for them - it's not like they have no competition.

Physical goods come with EULAs already. They should be legally worthless, of course, but they do exist.

As long as the manufacturer doesn't cripple your product after you bought it (think PlayStation 3) this should be perfectly OK.

Modern processors could be considered software as much as they're hardware.

Further, it delivers what the customer expects. It just turns out that Intel nicely provided additional functionality that you can unlock if you pay for your part of the R&D cost of it (which is the real cost of processors).

There is nothing wrong with this practice.

I'm more concerned with functionality being disabled at a later time.

For all we know, every modern appliance is counting down the days until the warranty expires at which point it self immolates, forcing you to buy another.

That isn't the case in this situation, though. The expectations of the device were entirely up front and this was more of an "aha!".

As an aside, my auto has a built in system that monitors car telemetrics, has GPS functionality, a built in cell phone and "lojack" system, etc. I paid for this as a part of the car. It is completely useless the moment I stop paying a monthly service fee.

That's more in line with what I fear, if your "lojack" system has remote disable.

What is to prevent a rogue employee, system error, or virus from disabling your vehicle at the most inopportune time?

"Sorry, your [phone|cpu|car] is bricked. Just have it towed, and I can JTAG it."

Someone has already analyzed the security aspects of this.

http://www.autosec.org/pubs/cars-oakland2010.pdf

Short excerpt: Even at speeds of up to 40 MPH on the runway, the attack packets had their intended effect, whether it was honking the horn, killing the engine, preventing the car from restarting, or blasting the heat. Most dramatic were the effects of Device Control packets to the Electronic Brake Control Module (EBCM) — the full effect of which we had previously not been able to observe. In particular, we were able to release the brakes and actually prevent our driver from braking; no amount of pressure on the brake pedal was able to activate the brakes. Even though we expected this effect, reversed it quickly, and had a safety mechanism in place, it was still a frightening experience for our driver. With another packet, we were able to instantaneously lock the brakes unevenly; this could have been dangerous at higher speeds.

Already happened before: http://www.pcworld.com/article/191856/exemployee_wreaks_havo...