3 ms·

>I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that

>I personally feel that companies should be required to go one step further and be compelled to release their embedded keys and source code for any product that they no longer provide complete support for. The embedded team where I work struggles with the same thing. Frankly this should be included with the first delivery of any industrial system. Under NDA if they absolutely must, though I don't like it. I also don't like consumer systems being locked up, but at least it's somewhat defensible. But treating farmers as dumb, inbred "hold my beer and watch this firmware hack" hillbillies and not the educated industry professionals that they are is beyond condescending, disrespectful and is completely indefensible. Exactly who is deemed qualified to hack farm equipment firmware is something for the farming trade associations and their insurance companies to work out, but as far as John Deere and the regulators are concerned, we're talking about professional embedded developers writing code to run on their equipment to support an industrial process, something that is completely uncontroversial in many other fields. That you're not supposed to intentionally or inadvertently convert your combine into a man-eating killbot is surely already covered by insurance policy clauses, labour laws and public safety laws.

mikepurvis 9y ago
I completely agree with you, but I am a little sympathetic to the "bad PR" angle. It's really, really not that hard to imagine a scenario where a well-meaning farmer (or their contractor) loads something onto the embedded processor that does cause a malfunction, and before you know it there's a splashy news story featuring pictures of a big green tractor not living up to its brand. I work for a robotics company making indoor self-driving vehicles, and we worry about exactly this issue— from an ROI perspective, our product is a slam dunk, so it's safety and reliability are the first and second most significant questions which have to be answered during the sales process. When we invest substantially in associating our brand with those values, we really can't afford the possibility that an unauthorized user modification compromises them in a way that's outside of our control. Hence closed source, FDE, and all the rest of it.
- squarefoot 9y ago
  That is a very specific scenario, but agreements can be made to release software in exchange of loss of warranty and liability protection: I give you the code and from that moment (either if you use/modify it or not) you lose all warranties and can't sue me even if the product burns your house and kills all your kittens.
  - ouid 9y ago
    you can't release all liability.
  - mikepurvis 9y ago
    Losing the warranty is a given once it's been modified. And obviously before electronic control, there were still a hundred ways you could break any given device and have it generate undeserved bad press for the manufacturer. But I contend that the scope of things that can go wrong when you mess with the software, and the degree of damage that can be done, are both worse than with purely mechanical modifications. There's huge potential for unintended consequences, and bad press puts the original manufacturer in the awkward position of having to disavow their own product, bearing their symbol, because "the user modified it in an unsupported manner." All this gets even worse if the manufacturer actively supplies source code and an SDK for making such modifications. How do you delineate supported vs. unsupported mods?

mikepurvis 9y ago

I completely agree with you, but I am a little sympathetic to the "bad PR" angle. It's really, really not that hard to imagine a scenario where a well-meaning farmer (or their contractor) loads something onto the embedded processor that does cause a malfunction, and before you know it there's a splashy news story featuring pictures of a big green tractor not living up to its brand. I work for a robotics company making indoor self-driving vehicles, and we worry about exactly this issue— from an ROI perspective, our product is a slam dunk, so it's safety and reliability are the first and second most significant questions which have to be answered during the sales process. When we invest substantially in associating our brand with those values, we really can't afford the possibility that an unauthorized user modification compromises them in a way that's outside of our control. Hence closed source, FDE, and all the rest of it.

squarefoot 9y ago
That is a very specific scenario, but agreements can be made to release software in exchange of loss of warranty and liability protection: I give you the code and from that moment (either if you use/modify it or not) you lose all warranties and can't sue me even if the product burns your house and kills all your kittens.
- ouid 9y ago
  you can't release all liability.
- mikepurvis 9y ago
  Losing the warranty is a given once it's been modified. And obviously before electronic control, there were still a hundred ways you could break any given device and have it generate undeserved bad press for the manufacturer. But I contend that the scope of things that can go wrong when you mess with the software, and the degree of damage that can be done, are both worse than with purely mechanical modifications. There's huge potential for unintended consequences, and bad press puts the original manufacturer in the awkward position of having to disavow their own product, bearing their symbol, because "the user modified it in an unsupported manner." All this gets even worse if the manufacturer actively supplies source code and an SDK for making such modifications. How do you delineate supported vs. unsupported mods?