I think Right to Maintain should be a better term for what we need. When you buy a device that is proprietary, you have no right to maintain the software and once the vendor decides they don’t want to maintain it (usually though planned obsolescence) it is quickly e-waste.
We need to have the boot loader unlocked and all the hardware schematics made available. Better yet, force the vendor to release the source code once they stop supporting the device.
While I agree with you, this is an inherently political discussion. Having a phrase thats easier to remember (due to alliteration) and easier to conceptualize (of course I should be able to repair something!) might give it ever so slightly more of a chance to get past the collective apathy.
I would love a software right to repair. Companies are using software to block customers from repairing their automobiles, computers, smartphones, washers, dryers, refrigerators and many more devices. Not only is this an immoral hijacking of your property, but it is TERRIBLE for the environment. Any device with minor issues has to be thrown away.
Repair also serves companies better in the long run because one of the big results is that it ends up training the next generation of builders. If you talk to engineers it's pretty common to hear about how they loved to take things apart as a kid and learn how things worked. You don't get the equivalent of a child restoring a classic car or fixing the plumbing with their parent with software. Not to mention that companies themselves will get bug fixes or upgrades from the community who are doing things with the product that the creator never thought of.
Not having the software open and right to repair just seems to me like a classic benefit in the short term, detriment in the long run. And like you say, worse for the public at any timescale. I do want to protect developers, but I think we can do this in a way that doesn't produce so much fucking junk.
> Repair also serves companies better in the long run because one of the big results is that it ends up training the next generation of builders.
While I totally agree, this benefit is impossible to quantify on a quarterly report, so I expect it will not move decision makers. That's not to mention that MBOs and not engineers run many modern companies so their conception of engineers is "that cost centre I want to minimize", not a resource that needs to be nurtured.
> this benefit is impossible to quantify on a quarterly report
Well I think this is a more precise version of the short term long term dichotomy I expressed. So much of our world is dictated by quarterly reports and it's incredibly destructive. Isn't one of the key things that makes humans unique is our ability to do future planning? I guess quarterly is more than most animals, but it still seems incredibly short sighted considering we learned to prep for winter millennia ago.
The concept of limited liability is the source of many of America's societal ills.
If people were liable forever for the actions and could not contract it away, especially when concerning actions that can harm the public, you would see executives and boards of directors behave very differently do today.
Limited by ability socializes risk and harms and prioritizes profits. They both should be privatized.
You could say that it serves the industry better in the long run, however, for each specific company arguably it's not a benefit - there's no competitive advantage if the same new builders are available to their competitors, and they already have some builders and capacity for making more, so if it's more difficult for new ones, well, that's just a higher barrier for entry that allows them to extract higher margins; having higher costs doesn't necessarily mean lower profits if you can just raise prices as no potential competitors have lower costs.
I'm not sure this is true. Meta seems to be doing pretty well with everyone hacking on LLaMA. Same with Stability and Stable Diffusion. Plus there's the whole set of jobs that are not software based, where they are naturally "open source".
I think it’s long past time for OSS supporters to at least acknowledge the fact that, to adapt a common phrase:
Commercial software can travel half way around the world while the Open Source version is putting on its shoes.
Open source is slow, and it’s simply not feasible to live a life where everything is 100% tech freedom without making enormous sacrifices. For example the only way to avoid software in cars would be to drive something 20+ years old, which just isn’t realistic for (mostly) everyone.
The incentives for companies are so strong that in most cases you don’t even have an option, as every available product has the same type of lockdown.
If you want a car without software you have to go back to the 1970s. By 1984 almost everything was fuel injected (and the last hold outs had very complex computers controlling the carburetor). there are open source fuel injection computers, but they are very limited as to what they support and often when you look close don't look very open.
Nothing is perfect, and OSS certainly isn't an exception to that. But, personally, I've had much more trouble and strife on the whole with proprietary software than OSS.
I'm a proponent of right to repair because it leads to asking the same question about software. It's the first domino in a line of reasoning that leads to more software freedom.
I believe the point of this post is to introduce their "Use The source" mailing list[0] where they publicly track and encourage compliance with the GPL from vendors who release products containing GPL'd software. It's a spiritual successor to the old gpl-violations.org mailing list.
The security angle is because fixing a vulnerability is a fairly compelling reason why someone might want to update the software in a device they've purchased. Vulnerabilities found in Linux and other GPL'd software often get fixed fairly quickly, but random Linux-based IoT devices and whatnot often ship with ancient versions of GPL'd software and never see any security fixes. ("The S in IoT stands for security.") If the vendor complies with the GPL, then end-users can patch it themselves. But, many vendors don't, hence the need for the new mailing list.
The submitted title was "Without software right to repair, your devices are not secure". We've changed it now, in keeping with HN's title rule: "Please use the original title, unless it is misleading or linkbait; don't editorialize." - https://news.ycombinator.com/newsguidelines.html
If it had been a sentence from the article itself, we might have kept it, because "Prioritizing software right to repair: engaging corporate response teams" doesn't say much. But I couldn't find that language in the article, and it seems you couldn't either, so it's probably best to stick to the rule in this case and revert it.
Huh, I copy-pasted the title when I submitted it, but it looks like the article has since been edited. (There was also an example in the article about updating an insecure baby monitor that made the title make a bit more sense.)
Oh well, the new title is probably more clear anyways.
Ah thanks and sorry for guessing wrong! - this does happen sometimes. Usually not with smaller publications; more often with NYT, BBC, etc. who frequently change up their titles.
Agreed. The article has almost nothing to with the headline. The article is about copyleft compliance. It is not about "Without software right to repair, your devices are not secure". That is a much larger topic than the article itself which is about auditing that if you're using copyleft software that you're complying with the license. The article itself is not calling for a right to repair all software in all devices.
"Copyleft compliance". Some argue the GPL and other copyleft licences help ensure the right to repair by helping to enforce the availability of source code.
> We recently launched Use The Source (alluded to above), which helps device owners and companies see whether source code candidates (the most important part of copyleft compliance) are giving users their software right to repair, i.e. whether they comply with the copyleft licenses they use.
Sure, but that only applies to devices that aren’t being maintained by someone else, and frankly, it’s not obvious to people who have to maintain their own devices and do a better job, so it’s not clear that there’s any particular argument associated with security here.
Just to be clear, I believe that copyleft compliance is important simply because it is the conditions under which the authors made their code available. I just don’t think the headline is honest.
We need to have the boot loader unlocked and all the hardware schematics made available. Better yet, force the vendor to release the source code once they stop supporting the device.