As a counter argument: I was just looking at a small open source utility. As I was going through the code I found cases where certain arguments could be set to magic values that cause useful, but undocumented behavior. Should the developers be forced to document these options?
I don’t think a manufacturer should be able to lock you out of reading diagnostics on your own devices, or that anyone should be prevented from reverse engineering what those values mean. But I also don’t think there should be any requirement that they are forced to do additional work. That seems just as immoral.
But they do do that. Also what’s the difference between a lot of obfuscation and prevention and how will you enforce that without lawsuits and discovery?
Also, what is those values have the ability to do damage and cause safety issues? Like losing your own software onto a control by wire car? Then you can rent a car and install your own software surreptitiously.
>> don’t think there should be any requirement that they are forced to do additional work
At one time seatbelts, airbags, emission controls, etc were all viewed in this category. Now we have regulations enforcing aspects of all of these. Why would diagnostics be different?
If you’re starting up a small business, selling at-a-loss widgets to gain market share do you want to be forced to publish a diagnostic manual that not only increases your work, but may also increase your liability?
Seatbelts and airbags are safety, but if you talk to anyone at a body shop, they will tell you there are significant regulation changes in the past decade that have made cars more expensive to fix while not necessarily safer.
I just don’t think it’s as cut and dry as everything must be forced to be documented. What is everything, at what size or industry is this documentation required, why this industry and not that one, is it just OBD or _everything_ including all CAN bus communication, etc. Minimally the end result is increased cost for everyone.
If it’s already published, perhaps libraries should start collecting the service manuals.
The right to repair cases that bother me most is where the company goes out of their way to prevent end-user repair (cryptographic pairing of modules!?), or where service manuals/information exist but are only available to dealers.
There's documentation, and then there's documentation. What passes for documentation in the modern era is scattershot over thousands of JIRA tickets and Confluence pages. Most outdated.
Resetting the oil/maintenance light, recoding key fobs, resetting the battery stats upon replacement, etc.
I want independent mechanics to be able to do that. I also want to be able to do that myself, if I’m so inclined.
I’m absolutely in favor of being able to repair my own stuff and voiding any warranty or liability in the process. I absolutely support reverse engineering and preventing companies from issuing copyright strikes on uncopyrightable facts about their products. I’m mostly OK with the idea that unqualified people can make potentially life threatening changes to their 2-ton vehicle barreling down the road at 80mph.
Would I like documentation for all these things? Absolutely! Should it be enforced by law? I don’t think so.
Yes. Network services and client software should be considered two separate products/markets, and tying between them should be seen as anti-competitive behavior worthy of anti-trust enforcement.
That the software industry has been able to develop some brazenly anti-competitive pratices does not constitute an argument that it should be allowed to continue.
I’m fine with Google Workspace owning the client and the service, same with Zoom, Slack, Teams, Box, Dropbox, etc.
I don’t think we’d have better games (pretty much for certain), and I don’t know that we’d have as good online productivity tools either.
The multi-user productivity apps you listed would most certainly be better off as separate clients and services! The entire point is that you shouldn't be forced into using one (often terrible) piece of proprietary client software simply due to the network effects of other people using it. Wouldn't it be nice to use the Slack client in a Teams environment (or vice versa if that's your thing) ? This would produce more competition because companies would have to develop the client software to be compelling itself, rather than relying on the pull of installed deployments with captive victims^wusers.
You were able to do that because it was open source. If a car mfr was willing to do that, it would be plenty enough for me. They shouldn't be forced to do any additional work beyond the 5 seconds it takes to type `git remote add origin github.com/honda/civic`. Then the community would have everything it needs to carry things forward.
Failing that, yes, I do think everything should be documented.
You want to force companies to publish and maintain repositories using your preferred toolset?
Ghidra exists. That doesn't mean all software is open source.
> You want to force companies to publish and maintain repositories using your preferred toolset?
Nope. Anywhere will do, whatever is easiest for them, as long as device owners can access it.
https://github.com/Konik-ai/j1939_dbc/blob/main/dbc/j1939.db...
There are a ton of dbc files floating around like this. Almost any car with a turbo has a kit to flash the ecu for more boost, so even the proprietary signals have been reversed.
The reason there is an opaque number in that open source utility is precisely because of a lack of open documentation for that register definition. Independent black box analysis of the messages only got as far as "write this value to do effect X". Whomever developed that utility would have loved to spell that bitfield out, but not at the cost of more days reverse engineering.
But manufacturers aren't reverse engineering register definitions, they're working off of vendor datasheets or protocol definitions they themselves created. All of this documentation has already been produced, as it was used to develop the tractor from its various subsystems. It just needs to be published!
At any rate, for things a manufacturer doesn't consider important enough to document themselves then there can be a clear alternative requirement - release whatever upstream documentation they did use to create it, plus the software source code they developed on top of it. If it's not important enough to have been documented as its own product, then it also isn't a significant part of the value they're actually selling, right?
You're talking about things that by definition have to be documented and internally published in order to design and build the powertrain in the first place. You can't design a computer-controlled automatic transmission without documenting the shift points.
The cost is therefore essentially nothing, because the information already exists. Just copy paste it into a PDF and put it on your website.
Intentionally obfuscating the data¹ also requires time effort and costs.
I think that if you want to sell to the public, it is entirely moral to force manufacturers to do additional work. The trivial example is that we already force restaurants to do additional work to follow food safety and hygiene regulations. That is additional work they don't really have to do. If that's not amoral in the food industry, why would it be immoral for cars?
I'd love to move towards a world where owners can access everything, flash the firmware in the headlamps, etc. But all I can do as an individual is vote with my wallet and avoid the 2020s computers-on-wheels.