Everyone that wants a few extra horsepower or MPG will do the same exact thing that VW did. Or rather one or two enterprising combination gearhead-coders will do it and cheaply replicate it a million times over. This will end up being the worst possible option for emissions because it will be available for nearly every model. You don't even need to buy anything -- just pull into a gas station and pay some kid $20 to "unlock" your car. He'll probably charge you $20 to reset it before the smog test (every 2 years) and another $20 to set it back, but you'll make it back on gas. And this is way cheaper than most legitimate performance enhancing modifications.
[ Emissions testing? Well I'm sure the enterprising folks will have a very easy way to flash the right thing back on before pulling into the shop and then switch it back later. Well maybe the ECU keeps a history of versions -- oh wait, the entire thing is open source so I can just go modify the function that returns the history. OK, I'll have roving police officers querying firmware versions -- hahaha, the firmware can return any version it wants. OK, we'll have roving police officers downloading the entire firmware and analyze it -- besides being ridiculous, we can just modify the functionality that returns the firmware image to return a different one than the one loaded. There's no way to win this war. ]
Conceptually, there are 3 differents sorts of code Free-as-in-Speech that I can distinguish here:
(1) The right to inspect the code. Totally uncontroversial, I have no philosophical objection. Practically most automotive security is so bad that code inspection would very quickly yield vulnerabilities that lead to (2) or (3) but that's not a conceptual problem.
(2) The right to modify the code. Somewhat controversial, at least when the code implements functionality that is adverse to the individual but in the interests of the collective such as pollution control at the expense of performance/efficiency. This directly costs the individual more money in gas. This is a good test-case for the tension because most software freedom folks are also strongly in favor of environmental controls.
(3) The right to modify the code but also falsely attest to its authenticity. It's one thing to declare that your device is yours and can run whatever code you want (and see #2, this is not always ethically correct). That's distinct from the right to lie to an external observer and attest that you haven't modified it from the original. This becomes a major issue both in the context of governmental controls (especially easy when we believe they are legitimate, given that particular emissions causes additional deaths) but also in the context of corporate BYOD policies.
For an example, I support 100% everyone's right to modify your Android kernel and userspace. I also support 100% an IT department saying that access to internal corporate resources is restricted to some particular Android versions (whether they are AOSP-original or Cyanogen or home-roll). Access & ownership of those resources belongs to the company, they have the right to set policy on how they are accessed. One can enforce this as a matter of rules, but technologically one can also imagine a solution in which there is a trusted boot component that never restricts what the user can load, but at the same time will not attest to the authenticity of the software stack if the user has modified it. The application of this system to the automotive case is left as an example for the reader.