I'm surprised that the EFF would suggest going to the level of having companies publish their code. A huge number of manhours goes into developing the software that runs a car, and a significant amount of IP is tied up in it.
Forcing vendors to release software would allow competitors to steal it outright, and open up the entire industry to a massive set of lawsuits. I don't think that's a very beneficial outcome.
As someone who works in a technical safety auditing role, I strongly doubt that NDAs would preclude the widespread release of this software. I have a hard enough time convincing vendors that the lifecycle documentation they are already mandated by law to provide, should be provided. This is just unrealistic.
Force one, force all. The side effect being that if another manufacturer steals and reuses code under NDA, that'd show up as well.
Calling it "unrealistic" is unrealistic. These companies are not anybody's pet, to be loved and hugged and cared for. We should ask them to release their code, at least to regulation agencies under NDA, because otherwise they harm the health of millions of people for the sake of passing regulations, like in this very case. Don't know about you but I'm in no mood to give them a free pass on this and on top of that, worry about "oh but those poor SOBs, what would they do if their NDA'd code would get leaked"...
Sorry, this is a bit of a hostile answer and it's not meant to be - this entire ordeal is enraging... and I don't see why we should preemptively defend their rights to make money off our own health.
Don't worry, I'm just as furious as you are! I want realistic solutions though, and I don't think forcing vendors to open their source will fly.
For one, you will never force all vendors to comply, as some are completely outside of the jurisdiction, like China. Secondly, even if you did force vendors to comply, you've just given any new startup a massive leg-up on R&D, which the existing vendors discounted for them.
I don't think it's realistic, and there are already methods by which the code has to be reviewed externally, at least in principle. I want to improve the existing processes, not move to a new model.
Maybe I misread the article, but I don't think the EFF are actually calling for car manufacturers to _open_source_ their firmware. Instead, I think they're arguing for a DMCA exemption on reverse-engineering the firmware.
At the moment, (allegedly) it's illegal under the DMCA to reverse-engineer car firmware. This obviously stops the research that might have highlighted this. The EFF are suggesting that the DMCA should not apply here, so researchers would be free to work from the compiled firmware (not the source code) to look for issues.
> Secondly, even if you did force vendors to comply, you've just given any new startup a massive leg-up on R&D, which the existing vendors discounted for them.
Real talk here: Is that such a bad thing? Why should new companies have to deal with problems humanity has already solved?
Because this completely dis-incentivises companies to spend money developing features in the first place, and makes it impossible for them to recoup the sunk cost of development over car sales, since they're competing against companies who did not pay those costs.
It seems to me what's unsustainable is relying on a system built on trade secrets. Something we quickly moved away from in the software world, which has greatly accelerated development, been mutually beneficial to everybody, and certainly hasn't been "unsustainable".
I remember someone comparing, on HN, what "closed source" is to science to what ancient guild secrets were to alchemy. Are guild secrets any more sustainable than closed source?
It wouldn't be only a beneficial outcome, it would be the best and the only morally right outcome.
Consider that before the advent of software, people actually owned the things they bought. And you could argue that it isn't fair to impose such standards on markets that haven't existed before software and you might be right, after all people have to eat, but when it comes to automobiles people have historically owned the car they paid for. And in practice what this meant is that they can get it inspected and repaired by third-parties should they want to do that, which means longer lifecycles and cheaper service, among other side-effects that come as a natural consequence of actually owning things, a freedom that is essential for the proper functioning of capitalism itself.
But now with the advent of software in these computerized cars all of that is about to change. And lets place that in the context of the never ending copyright terms, with the excruciatingly low threshold for awarding patents, with the price of IP lawsuits going through the roof, along with the fact that software leads to natural monopolies. As that's the context we live in, a context in which innovation happens only because the giants whose shoulders we stand on haven't protected their "IP".
And I get it, we are software developers, we've got to sell our labor, but nothing makes the stealing argument any less bullshit. And we could start from stating the obvious, which is that copyright or patent infringement is not stealing.
Don't get me wrong, I'm the last person to defend the overuse of software patents. Where people are genuinely creating extremely complex functionality in software however, I think they deserve some protection for their outlay.
On your point about historically owning vehicles, as a software developer you will understand that there is a very wide gap in competence between being able to tune a standard motor, and being able to inspect and modify software that controls a car safely. Currently this is protected so that only the vendor can change it, precisely because that's how we wrote the standards - vendors are responsible for their code, and responsible for the safety outcomes on the road.
If we moved to an open model where anyone could modify the software in their car - what do you think would happen to the safety and reliability of that software? I don't think any of us could imagine that it would improve.
> you will understand that there is a very wide gap in competence between being able to tune a standard motor, and being able to inspect and modify software that controls a car safely
A big part of that is because cars have been around for over a century, and there has been a huge tinkering crowd to learn and teach newcomers to the scene. The software/robotics crowd is maybe only a decade old (ignoring the hacking scene). Why wouldn't we in a hundred years or so be able to write our own car control software? Or more importantly, why shouldn't we?
I also disagree on your stance that open-sourcing it wouldn't improve anything. If anything, open-source has been the driving force behind great procedural advancements in software design: source control, code quality measurements, unit testing, metaprogramming, have all been influenced or driven by large open-source projects. If anything, I think the first thing an open-source movement for car control software would produce is testable code, probably from a greater focus on compiler-enforced design-by-contract languages.
In my mind, the only reason we wouldn't be able to progress to that point is exactly because of these anti-reverse-engineering policies, because of IP protection and litigious manufacturers. I'm firmly with the EFF on their Freedom To Tinker cause, and I think it's perfectly acceptable for the EFF to take this case as an example of why current policies are wrong.
"If we moved to an open model where anyone could modify the software in their car - what do you think would happen to the safety and reliability of that software? I don't think any of us could imagine that it would improve."
1. 99.99 percent of the owners of these automobiles wouldn't have a clue to even where to access, or what to do with the code? Most can't find their AlDl, or OBD plug.
2. Most mechanics out there don't know much about car computers, and 99.9 % know nothing about programming. When something goes wrong with the computer; they just replace it. When I was in automotive school, the failure rate of car computers were 1 in a million. I think that's low though? Mechanics just replaced the computer--hopeing they got the right one. The one in the vechicle was usually fine, but was shorted out by fat fingers, and hangovers.
In real life, when a mechanic, usually erroneously blames the automobiles computer, as the fault of the problem, he/she just replaces it. Their biggest achievement is not shorting the new computer in by installing it. Of course when they short out the computer, they blame the computer as defective, and charge the customer.
Dealership mechanics(some) can reflash their particular brand of vechicle computer/computers, but they don't code anything. They push a GUI button, and answer yes, or no questions the enginneers at corporate programmed.
As to propriatiry software, it's not about safety, and reliability. It's about customers being held hostage to the dealership. You buy a fancy car, with a bunch of do-dads on it. You can't just bring your ailing car to any independent mechanic. They don't have access to the computer system. Most wouldn't have a clue to the actual code, but they need trouble codes. These trouble codes are being held hostage. The dealer will happily fix your car, but at dealer prices.
Even if people abused the open source software(affecting emmissions), it would be caught at the bi-annual smog check? As the safety, the automobile companies would love to blame tampered with software in order to lessen their liability? (It sounds like it would be pretty easy to test for altered code, on the manufactures end?) For years now, I can buy computers that improve a vechicles performance, but it's just not worth not passing an emmission test--in my view.
So, I don't think it's about safety, It's about greed.
And maybe other factors; like they don't want the Programmers peering into their horrid code. Code that defeats smog checks. Code that reuses other manufactures patents--without payment? Code that is just terribly written, and causes numerous accidents, and thefts?
Again, I don't want much. I just don't want to essentally lease my vehicle after buying it with cash? What? Yes, because no one other than the Dealership can work on it at $170 hr. The idependents will attempt to work on my new vechicles, but they never seem to solve the problem. Why should they, they don't have the information! These automobiles have gotten so complicated, even your dealership mechanic is usually figuring out your cluster of sensors on your dime. It's gotten to be quite a racket? I forsee acres, and acres of newer automobiles that are junked because they aren't worth fixing? Give out trouble codes? Give out a service manual with every new car sale. Tell the customer up front, "I will see you again sir, for many years--let me program all our dealerships into your GPS?" "I hope you never lose that high paying job?" "Your so good looking, why would you ever want to get your cute hands dirty working on that dirty automobile?"
Give me access to my computer on my car, at least the trouble codes, and access to a reasonably priced scan tool? I'll even sign a waver--if that's the problem?
> In real life, when a mechanic, usually erroneously blames the automobiles computer, as the fault of the problem, he/she just replaces it.
For one, it depends on the repair shop you're talking about. Personally I require proof that the problem has been solved.
But anyway, for one while it may be true that most mechanics will simply replace a component when broken, replacements can also be made by anybody and that will drive the cost down and encourage local businesses.
And really, many software developers are nothing else than glorified mechanics. Right now the supply and demand curves are favoring us, but give it some time and you'll see software developers working for car repair shops. After all, the trend is always commoditization and at some point investors will stop wanting to create frontends to a database that are automating an Excel spreadsheet communicated in an email exchange.
But is that what they are saying in this article? Obviously they would prefer a future where firmware like this is open source (for regulatory reasons or whatever other reason) but all they are saying in the article here is that it's wrong that you can't tinker or reverse engineer? "Unlawful to look at the code" that is a roundabout way of saying that it's unlawful to try to decompile, right?
I agree that peeking at code or decompiling it should never be illegal, nor publishing what you find. But requiring companies to publish code openly would be something completely different than allowing decompilation.
Where is the EFF suggesting that companies should publish their code? At least in the linked article, they are merely arguing that it should not be illegal to reverse engineer it.
I've read and reread the article, and I just don't see anywhere where the EFF are suggesting companies publish their code - can you provide a quote? Maybe it's in another article?
What I see the EFF asking for is a DMCA exemption so that researchers can legally reverse-engineer the firmware.
Forcing vendors to release software would allow competitors to steal it outright, and open up the entire industry to a massive set of lawsuits. I don't think that's a very beneficial outcome.
As someone who works in a technical safety auditing role, I strongly doubt that NDAs would preclude the widespread release of this software. I have a hard enough time convincing vendors that the lifecycle documentation they are already mandated by law to provide, should be provided. This is just unrealistic.