Ask HN: Right to Repair for Software?
16 comments
> How would you implement a right to repair for software in 2023?
What has 2023 do to with anything? The four essential freedoms for software were written more than thirty years ago and today are more relevant than ever: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
To answer your question: any government mandated software, or software used, or bought, or promoted by, or paid for by the government should be free software.
What has 2023 do to with anything? The four essential freedoms for software were written more than thirty years ago and today are more relevant than ever: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
To answer your question: any government mandated software, or software used, or bought, or promoted by, or paid for by the government should be free software.
The world of software is larger than government related software. Even the world of effectively mandatory software is larger than government related software.
I used to work in defense, should that software be open source?
> I used to work in defense, should that software be open source?
Software that is used internally and not distributed need not be free software. That was not my point.
That said, I do work in defense now (writing software for a defense partner that finances the research of my lab) and the contract requires that all our production be published under an open source license. Only the data is secret, and we don't really get to see most of it.
Software that is used internally and not distributed need not be free software. That was not my point.
That said, I do work in defense now (writing software for a defense partner that finances the research of my lab) and the contract requires that all our production be published under an open source license. Only the data is secret, and we don't really get to see most of it.
When you say "published", do you mean released publicly on GitHub or just released to the defense partner?
Security by obscurity is the weakest form.
Everyone loves this phrase but it's far from a universal truth. Sure, it applies to shipped software, but I'm not sure that it applies to military hardware. Regardless, you really think that military hardware should be open sourced?
First of all, the GP comment was talking about software, not hardware.
Something made by the military to be consumed by only them probably doesn't need to be open sourced. Same thing as if you write a program for yourself that only you use. Once something is intended to be consumed by the public, it should absolutely be open sourced. Voting machine software, tax filing software, etc.
Something made by the military to be consumed by only them probably doesn't need to be open sourced. Same thing as if you write a program for yourself that only you use. Once something is intended to be consumed by the public, it should absolutely be open sourced. Voting machine software, tax filing software, etc.
Just because military software isn't released publicly, doesn't mean it shouldn't be open source (the OSI definition, not the "public source" definition).
What about software that simulates hardware? That's a thing.
I agree though, I just don't think it's an absolute rule. Voting machines and other stuff that the public uses probably should be.
I agree though, I just don't think it's an absolute rule. Voting machines and other stuff that the public uses probably should be.
If you mean the OSD/FSD definition of open source, yes. The military should have access to the source code for the software it is running on the devices it owns/uses. If you mean "public source" then thats a bit more murky.
Absolutely.
Could you explain your reasoning?
Taxpayers money pays for a huge amount of defense industry software development.
Sounds circular.
- All taxpayer funded sw should be open source
- what about defense?
- yes
- why?
- because it's taxpayer funded
- All taxpayer funded sw should be open source
- what about defense?
- yes
- why?
- because it's taxpayer funded
Even fully open sources software can't be "repaired" when its dependencies break. There are a wide range of programs that broke when Python 2 went away.
As for the law, any software no longer for sale, or older than 10 years old should lose all copyright/IP protection, which ever happens first. Anyone should be able to write/support a Windows XP,7 or 8 clone at this point, along with Office, Exchange, etc. up to 2012
--- Warning --
Strong message (rant) to follow
Uppity programmers calling themselves software "engineers" act in almost totally the opposite manner of a true engineering discipline. They hold "legacy" in contempt, and break things in the name of "progress" or "safety" at odds with their stated goals. They ignore the lessons of history, and keep re-inventing the same things every decade or two.
You can still plug a BC-232 radio manufactured in the late 1940s into the wall and receive broadcast signals.
You're effectively prohibited from running a web browser or telephone from 10 years ago because of planned obsolesce. This needs to stop!
As for the law, any software no longer for sale, or older than 10 years old should lose all copyright/IP protection, which ever happens first. Anyone should be able to write/support a Windows XP,7 or 8 clone at this point, along with Office, Exchange, etc. up to 2012
--- Warning --
Strong message (rant) to follow
Uppity programmers calling themselves software "engineers" act in almost totally the opposite manner of a true engineering discipline. They hold "legacy" in contempt, and break things in the name of "progress" or "safety" at odds with their stated goals. They ignore the lessons of history, and keep re-inventing the same things every decade or two.
You can still plug a BC-232 radio manufactured in the late 1940s into the wall and receive broadcast signals.
You're effectively prohibited from running a web browser or telephone from 10 years ago because of planned obsolesce. This needs to stop!
There are programs, protocols, ecosystems and programmers that favor stability. However seems to be that the closer you get to the user, the less stable and simple things are. It's ironic or maybe even hypocritical of us programmers to prefer stable tools for ourselves, but then move around and break stuff for our users every few months.
Stability is really something that we need to get a lot better at as programmers. Perhaps accesibility laws/guidelines should limit UI changes for automatic/required updates - you can always have users opt into your shiny newfangled UI if you want, but leave the old one instead of confusing your users.
> Even fully open sources software can't be "repaired" when its dependencies break. There are a wide range of programs that broke when Python 2 went away.
Can't? Like physical objects can't be repaired when the parts are no longer sold?
There is always a way to repair, just a matter of how difficult it is. Having the sourcee to the application itself is the first difficulty barrier. Source to dependencies would also be helpful, yes.
Btw, Python 2 did not go away unless you mean it went away from the default package archives of some Linux distributions - but even there it's not (yet) gone for all of them. The Python 2 sources are still the same as they have always been and while you might need older versions of a few more dependencies, if your really need to have Python 2 you can get it.
Can't? Like physical objects can't be repaired when the parts are no longer sold?
There is always a way to repair, just a matter of how difficult it is. Having the sourcee to the application itself is the first difficulty barrier. Source to dependencies would also be helpful, yes.
Btw, Python 2 did not go away unless you mean it went away from the default package archives of some Linux distributions - but even there it's not (yet) gone for all of them. The Python 2 sources are still the same as they have always been and while you might need older versions of a few more dependencies, if your really need to have Python 2 you can get it.
> There are a wide range of programs that broke when Python 2 went away.
Python 2 still exists. Those programmes will break if you try and run them on Python 3, but that's not the same.
Python 2 still exists. Those programmes will break if you try and run them on Python 3, but that's not the same.
A few distros have stopped shipping it in a usable manner in their repos.
Indeed. Additionally, people can install it themselves, or run their programs through a Python 2 Docker image.
> Uppity programmers calling themselves software "engineers" act in almost totally the opposite manner of a true engineering discipline. They hold "legacy" in contempt, and break things in the name of "progress" or "safety" at odds with their stated goals. They ignore the lessons of history, and keep re-inventing the same things every decade or two.
The reason for that is that software is much easier to change than hardware. You cannot expect every person in the world to update their radio equipment every couple years - it's too expensive - but it's somewhat reasonable to expect people to install new software, especially if it can be done for free over the internet.
It's just economics at play.
The reason for that is that software is much easier to change than hardware. You cannot expect every person in the world to update their radio equipment every couple years - it's too expensive - but it's somewhat reasonable to expect people to install new software, especially if it can be done for free over the internet.
It's just economics at play.
That's not true most manufacters can change the machine yearly but try to change sap for oracle, or your custom solution for sap, and you are spending million of dollars in multi years projects,
I'm not expecting free and cheap software to end , but having a game than breaks in 10 years isn't problematic, but pushing delicate software for no reason, that could break in 5 years, becouse is impossible to the customer to know the dependencies of the program, or how robust is under stress test and cybersecurity, means we lack engeniering discipline not economics reasons.
Software is still easier and cheaper to change than what you'd spend for changing hardware, data and users. It's every time a multi-year project for big programs because of data and accustoming users for their habits and needs.
I think this is purely economic reasons, engineers working on that project is unlikely the people suggesting such a project...
>it can be done for free over the internet.
The cost to manufacture an executable is effectively zero, so its easy to incorrectly assume that means there are no costs.
The cost to integrate an executable is NEVER zero, there are always costs.
Windows is far, FAR less reliable on Wednesday morning because of "Patch Tuesday", this is a substantial and real cost.
The same is true for any system that implements "security patches" and feature "upgrades".
The cost to manufacture an executable is effectively zero, so its easy to incorrectly assume that means there are no costs.
The cost to integrate an executable is NEVER zero, there are always costs.
Windows is far, FAR less reliable on Wednesday morning because of "Patch Tuesday", this is a substantial and real cost.
The same is true for any system that implements "security patches" and feature "upgrades".
This is the entire point of setting up an environment, to call up a known good dependency for this use case. None of those python 2 programs went away. They are still there, waiting for you to run them with python 2.
Those Python 2 programs can reasonably easily be repaired by porting them to Python 3.
This is exactly the thing.
If the difference between python 2 and 3 is so small that a program can be easily ported, then WHY did there need to be a difference at all?
If the difference between python 2 and 3 is so small that a program can be easily ported, then WHY did there need to be a difference at all?
Usually change happens because the old way was worse and the new way is better. For each individual porting change, you would have to look up the appropriate PEPs to discover why the change was made.
That's the claimed reasoning, yes.
Is that actually true though?
It may be from a pure economic perspective focused on a business that can socialize externalities. Sometimes new developments reduces development time. On the other hand, the externalities of that is that a modern computer performs worse running equivalent tasks today in the browser than a native app 15 years ago on hardware from that time. Lucky for businesses that they aren't held responsible for the ewaste they helped produce.
It may be from a pure economic perspective focused on a business that can socialize externalities. Sometimes new developments reduces development time. On the other hand, the externalities of that is that a modern computer performs worse running equivalent tasks today in the browser than a native app 15 years ago on hardware from that time. Lucky for businesses that they aren't held responsible for the ewaste they helped produce.
There's no point positing a less likely reason. Python wanted to incorporate Unicode fully. There was no way to do that that they came up with that didn't break a lot of software. You can read the documentation and see the discussion. It's not companies; it's a few people in Python leadership deciding.
> That's the claimed reasoning, yes. Is that actually true though?
yes.
one of the changes (and in my experience, the most problematic change) was the removal of the keyword "print"
it was a poor choice at the start to treat "print" like a keyword. it is a simple, breaking change to remove it, easily automated (ps: just add brackets), and now the language is more consistent and flexible.
The only reason to keep it is to not "touch" things. but it is easily mitigated, so that isnt a good enough reason imo. I much prefer a consistent language.
otherwise I'd stick with PHP.
yes.
one of the changes (and in my experience, the most problematic change) was the removal of the keyword "print"
it was a poor choice at the start to treat "print" like a keyword. it is a simple, breaking change to remove it, easily automated (ps: just add brackets), and now the language is more consistent and flexible.
The only reason to keep it is to not "touch" things. but it is easily mitigated, so that isnt a good enough reason imo. I much prefer a consistent language.
otherwise I'd stick with PHP.
Is it easilty mitigated though?
By a python programmer, sure.
By another programmer, ok.
By your grandpa that just wants to run that python script to organize his stamp collection that has worked for decades? No.
For something as popular as python there will be thousands such people. Stuff that will simply NOT get fixed.
But that cost is easily ignored by the original developers.
By a python programmer, sure.
By another programmer, ok.
By your grandpa that just wants to run that python script to organize his stamp collection that has worked for decades? No.
For something as popular as python there will be thousands such people. Stuff that will simply NOT get fixed.
But that cost is easily ignored by the original developers.
Web development isn't mandatory, you can still have a native app in 2023.
The point is that the lack of businesses being made responsible for the externalities they cause disincentives native apps, not that it is impossible.
If 90% of apps necessary for normal life are only available as poor web versions it drives obsolescence no matter what the remaining 10% do.
If 90% of apps necessary for normal life are only available as poor web versions it drives obsolescence no matter what the remaining 10% do.
Why is web app a bad thing though? Most of the apps do not require much performance and the web version can also be pretty fast, at least sufficient for users. I think the same author writing that crappy web app will produce worse native apps if forced to do so.
Web apps is better than native as they are automatically running the latest version, platform independent (windows, mac, linux, android, ios), in some sense more secure. Instead of asking people to write more native apps, I think we should rather ask them to write more quality web apps if they don't need native capabilities.
Web apps is better than native as they are automatically running the latest version, platform independent (windows, mac, linux, android, ios), in some sense more secure. Instead of asking people to write more native apps, I think we should rather ask them to write more quality web apps if they don't need native capabilities.
Try running eg. Libre Office and gdocs on a 10+ year old laptop. The difference is night and day. And that is a web app which should not be particularly demanding (essentially text entry).
E2A: Also, try running Figma on an older device. It's basically unusable. No native version, and a native version would be much better.
E2A: Also, try running Figma on an older device. It's basically unusable. No native version, and a native version would be much better.
No, google docs is not just text entry, it is much more complicated than that due to synchronization and they did not try to optimize it well IMO. Text entry, even with highlighting and rich text, can be fast with web app, see VSCode and markdown applications for example.
As an example, see Atom vs VSCode. We thought building a code editor with electron will lead to something slow like Atom, but m$ later proved that it is possible to build something fast. Perhaps not as simple as native, but it can be done.
As an example, see Atom vs VSCode. We thought building a code editor with electron will lead to something slow like Atom, but m$ later proved that it is possible to build something fast. Perhaps not as simple as native, but it can be done.
I started writing yet another rant about how most HN users don't care about the rest of the planet, but then thought better of it. Long story short: way more people on Earth are using cheap (and thus low-power) hardware then you probably think. And it isn't necessarily old.
WikidPad had (??) a fairly large user base. The Win32 executable last released still works with my personal notes from 2008 onward.
There was a breaking change in Python, followed by a breaking change in WX_Windows, so while you can, in theory, run WikidPad under Linux today, few of the dialog boxes work, effectively disabling the program. 8(
Python2-3 transition COULD have been made easier, but it wasn't. The community places far too little emphasis on backwards compatibility.
This is because there's a myth: pushing a free upgrade across the internet is zero cost
This is not true, and can't be true. The cost of manufacturing software has effectively fallen to zero. This is not the same as the cost of implementation.
--- Tangent/Analogy ---
When you get a large machine tool, there are physical installation requirements that can delay its use by up to a year. Sometimes the floor needs to be removed and replaced with a better foundation. Power, cooling, air, vacuum, networking and other connections need to be made. These may require updates to infrastructure.
Once sited, machines have to be precision leveled, and there is always some form of break in period as differences are found and accounted for in their use.
Users have to be trained to allow them to work with/around any UI or performance changes that might effect production.
---
In a very similar fashion, software requires infrastructure (dependencies, operating system support, bug fixes, user training) and new executables carry new bugs to be worked around, performance changes, etc.
Security fixes should strive to minimize changes, but to me it is entirely unacceptable that they are necessary, especially at the rate currently required.
Security should be the job of the Operating System, not the application, network, users, especially NOT the users.
Software security updates should happen about as often as automobile recalls. They should be costly to the manufacturer and infrequent.
There was a breaking change in Python, followed by a breaking change in WX_Windows, so while you can, in theory, run WikidPad under Linux today, few of the dialog boxes work, effectively disabling the program. 8(
Python2-3 transition COULD have been made easier, but it wasn't. The community places far too little emphasis on backwards compatibility.
This is because there's a myth: pushing a free upgrade across the internet is zero cost
This is not true, and can't be true. The cost of manufacturing software has effectively fallen to zero. This is not the same as the cost of implementation.
--- Tangent/Analogy ---
When you get a large machine tool, there are physical installation requirements that can delay its use by up to a year. Sometimes the floor needs to be removed and replaced with a better foundation. Power, cooling, air, vacuum, networking and other connections need to be made. These may require updates to infrastructure.
Once sited, machines have to be precision leveled, and there is always some form of break in period as differences are found and accounted for in their use.
Users have to be trained to allow them to work with/around any UI or performance changes that might effect production.
---
In a very similar fashion, software requires infrastructure (dependencies, operating system support, bug fixes, user training) and new executables carry new bugs to be worked around, performance changes, etc.
Security fixes should strive to minimize changes, but to me it is entirely unacceptable that they are necessary, especially at the rate currently required.
Security should be the job of the Operating System, not the application, network, users, especially NOT the users.
Software security updates should happen about as often as automobile recalls. They should be costly to the manufacturer and infrequent.
> You're effectively prohibited from running a web browser or telephone from 10 years ago because of planned obsolesce.
But, but, but it is for your own security. /s
But, but, but it is for your own security. /s
If you step outside of the myopic web space most well written native code (SYSV ABI) has a decent shelf life.
Python 2 didn't "go away", you can still use it without issues.
True, but not a soul is trying to steal your credit card via BC-232.
After 10 years should farmers have to give away their land for free too?
Farmers have to put in constant work to generate revenue. "IP" revenue too often entails create-once-earn-forever. However, "IP" often has a higher upfront investment attached to it, and often is not (as) "scalable", unlike farming.
What I am trying to say is that both things are very different in details where it matters, so I think this is a rather flawed analogy.
Maybe a closer analogy would be landowners who rent out land. Should a person who bought land 10 years ago be able to generate revenue from renting it to a farmer?
What I am trying to say is that both things are very different in details where it matters, so I think this is a rather flawed analogy.
Maybe a closer analogy would be landowners who rent out land. Should a person who bought land 10 years ago be able to generate revenue from renting it to a farmer?
Farmers pay property tax and use the land productively. Property tax is an incentive to use the land productively.
If land could be replicated with a click of a button with close to zero cost, then sure.
If you're implying that the farmer would still have an income then it's not a valid analogy.
If I open sourced my software that I've been continuously developing for more than 20 years my income would drop to almost zero, immediately.
Your changes made in the last ten years would still be your exclusive monopoly so your revenue would probably not change much if you really have been continously developing it.
But even if this would destroy your business model, that doesn't mean it would not be a good idea for society as a whole. Business models become obsolete all the time. If there is enough demand for your software, you will be able to fund the development of it even without might-as-well-be-perpetual exclusive control.
But even if this would destroy your business model, that doesn't mean it would not be a good idea for society as a whole. Business models become obsolete all the time. If there is enough demand for your software, you will be able to fund the development of it even without might-as-well-be-perpetual exclusive control.
Farmers will keep generate revenue with their lands 10, 20 years later.
But Microsoft won't generate revenue with Office 2003.. This is whole different.
If it is imaginary land that they have thought up, yes.
Meaning you don't value the time that someone puts into building software as highly as the time a farmer puts into paying his mortgage.
Ten years is an eternity when it comes to software. But yes, software developers (and other people creating things covered under copyright) are overvalued compared to those creating physical things. And that valuation is created entirely due to IP law. How is that fair?
>And that valuation is created entirely due to IP law.
In that case, the value of land is created entirely by property law.
A farmer has the exclusive right to land from the existing fixed supply that the entire world has available to it. He didn't create it and no one else can use it. Whereas a software developer makes something new. Nobody else was deprived of anything pre-existing. Less justification for taking code from a developer than land from a farmer.
In that case, the value of land is created entirely by property law.
A farmer has the exclusive right to land from the existing fixed supply that the entire world has available to it. He didn't create it and no one else can use it. Whereas a software developer makes something new. Nobody else was deprived of anything pre-existing. Less justification for taking code from a developer than land from a farmer.
At the very least DRM and the DMCA shouldn't prevent people from creating and distributing their own fixes where they can. Patching/debugging/decompiling/modifying should be protected.
I love the idea of source code escrow as a requirement for copyright protection. If it were up to me, a DRM free copy of every work would need to be submitted to the copyright office for full copyright protection and that agency would publish and make available every work at copyright.gov automatically the moment the copyright on that work lapsed (ideally something that should happen in less than 10 years) while the works still protected would display a countdown clock showing the time until it's released to the public domain along with a list of reachable contacts for the copyright holders so people know who to contact if they don't want to wait.
I love the idea of source code escrow as a requirement for copyright protection. If it were up to me, a DRM free copy of every work would need to be submitted to the copyright office for full copyright protection and that agency would publish and make available every work at copyright.gov automatically the moment the copyright on that work lapsed (ideally something that should happen in less than 10 years) while the works still protected would display a countdown clock showing the time until it's released to the public domain along with a list of reachable contacts for the copyright holders so people know who to contact if they don't want to wait.
So I guess anything requiring significant R&D will on success become part of Microsoft Teams or AWS after <10 years (seven? six?), providing them with essentially free R&D and incentivising smaller companies to lock in users and abandon products frequently.
It means all the copyrighted code used in Teams and AWS will also become free for everyone to benefit from.
That's the entire deal. It's better for everyone, better for art, and better for tech when information and culture is freed and people can incorporate it into their own works as well as learn from and build on what came before them.
Copyright only protected those works for a limited time to encourage the creation of new works by making financial success possible but not perpetual.
In a world where we can publish globally in an instant and at near zero cost, seven years or so is plenty of time to make investment worthwhile, no matter if that investment is in time, talent, or R&D. It's not as if the copyright owner (which for commercial works is almost never the same person as the creator) can't make money on something just because it's in the public domain either.
That's the entire deal. It's better for everyone, better for art, and better for tech when information and culture is freed and people can incorporate it into their own works as well as learn from and build on what came before them.
Copyright only protected those works for a limited time to encourage the creation of new works by making financial success possible but not perpetual.
In a world where we can publish globally in an instant and at near zero cost, seven years or so is plenty of time to make investment worthwhile, no matter if that investment is in time, talent, or R&D. It's not as if the copyright owner (which for commercial works is almost never the same person as the creator) can't make money on something just because it's in the public domain either.
If something fits either Microsoft Teams or AWS and is successful for some other product they will copy it way before any competing closed source opens up. Not doing so will be bad for business.
If you're in the EU, you could use EU Directive 2009/24/EC. Someone with a better grasp of the law should check this, but you should be allowed to decompile & fix parts of the program which causes "interoperability" problems. It doesn't matter what EULA says or if it's copyrighted code.
EDIT: appartently there was a ruling in the Court of Justice of European Union on this
https://www.lexology.com/library/detail.aspx?g=f5b1193c-f423...
EDIT: appartently there was a ruling in the Court of Justice of European Union on this
https://www.lexology.com/library/detail.aspx?g=f5b1193c-f423...
If I were dictator for a day, here's what I'd do:
1. Software would become entirely non-copyrightable
2. Software that infringes on a patent claim would be prima facie evidence of the claim's invalidity
3. Distributing any software in a way that would violate the AGPLv3 would be illegal (with the exception that if you had access to binaries but not the full corresponding source for a program prior to this change, you could still freely distribute everything you do have afterwards), and both upstream authors and downstream recipients would have standing to sue over it
1. Software would become entirely non-copyrightable
2. Software that infringes on a patent claim would be prima facie evidence of the claim's invalidity
3. Distributing any software in a way that would violate the AGPLv3 would be illegal (with the exception that if you had access to binaries but not the full corresponding source for a program prior to this change, you could still freely distribute everything you do have afterwards), and both upstream authors and downstream recipients would have standing to sue over it
This is an already solved problem:
https://en.wikipedia.org/wiki/Gpl
https://en.wikipedia.org/wiki/Gpl
FOSS licenses are the equivalent of some hardware manufacturers voluntarily allowing repair. OP is asking for an equivalent of a guaranteed right to repair from all manufacturers.
Well you can do that by mandating by law that all software (including the one only provided as an online service) have to be released on a FOSS license.
The GNU GPL doesn't solve the problem for software that isn't licensed under the GNU GPL.
True, but licensing the software under the GPL does provide for "right to repair".
If your plan is to change copyright law, then just require all software be GPL licensed.
If your plan is to change copyright law, then just require all software be GPL licensed.
GPL does not prevent a company from architecting their system to use an online component such that you wouldn’t have any practical right to repair the system as a whole.
AGPL does, though.
The GPL goes further than just the right of an individual to repair software on their device or that they use online.
the GPL is not the only solution to this problem
Now how do we force vendors to use it?
Abandonware should not be copyright-protected. The process of business dissolution should require sending a copy of all proprietary source-code to customers (assuming the business was not acquired / there is no new owner of the source code), and businesses that refuse to support legacy software with no upgrade path should be liable to provide the source code to such customers.
I don't think right-to-repair for commercially supported software makes sense. If you care about the right to modify and rebuild, put source access into the contract. But you have a commercial relationship, so the vendor is supposed to listen to your feature and bugfix requests. If they're unwilling to consider source access or feature/bugifx requests, don't buy from them, it sounds like they don't care about your business.
I don't think right-to-repair for commercially supported software makes sense. If you care about the right to modify and rebuild, put source access into the contract. But you have a commercial relationship, so the vendor is supposed to listen to your feature and bugfix requests. If they're unwilling to consider source access or feature/bugifx requests, don't buy from them, it sounds like they don't care about your business.
[deleted]
1. When a company goes out of business, stops selling older versions of their hardware/software for a period longer than 12 months, they should be required to release their source code under a FOSS license. "Use it or lose it".
2. Mandate release of software developed using public funds under AGPL (e.g. government portals) or GPL, with obvious exception carved out for defense projects
3. Mandate implementation of manual overrides that allow owners to flash unsigned firmware/software on their devices, similar to Android phones
4. Legalize and ban EULA prohibitions against reverse engineering
5. Legalize and ban EULA prohibitions against unauthorized changes, carve out exceptions where strictly necessary (e.g. medical equipment and equipment critical to public safety, online games?)
2. Mandate release of software developed using public funds under AGPL (e.g. government portals) or GPL, with obvious exception carved out for defense projects
3. Mandate implementation of manual overrides that allow owners to flash unsigned firmware/software on their devices, similar to Android phones
4. Legalize and ban EULA prohibitions against reverse engineering
5. Legalize and ban EULA prohibitions against unauthorized changes, carve out exceptions where strictly necessary (e.g. medical equipment and equipment critical to public safety, online games?)
I think a start is in ensuring proper rights to browser extensions.
The Garmin Connect cookie banner was broken. It kept showing up on all reloads despite acceptance. In the end the add blocker fixed the problem by entirely removing the cookie banner.
I would say that is the first level of right to repair for software.
The Garmin Connect cookie banner was broken. It kept showing up on all reloads despite acceptance. In the end the add blocker fixed the problem by entirely removing the cookie banner.
I would say that is the first level of right to repair for software.
I currently have subscription payment fatigue. I'd really like a list of "One Time Payment" software. Are there app bundlers who resell subscriptions? Like if I just want to use an app only a couple of times?
I think it's less about copyright than the lack of nuance with copyright, in that copyright is given to whoever "owns" the right nit the creator(s), nor is there a way for the owner to automatically sell licenses and get royalties automatically.
Nir is there licenses for specific purposes, such as companies wanting to create their own franchise or a content creator wanting to use said copyright once in their work (even if you got permission you can be liable).
Nir is there licenses for specific purposes, such as companies wanting to create their own franchise or a content creator wanting to use said copyright once in their work (even if you got permission you can be liable).
Nah, I wouldn't try that stuff. The paradigms are different.
You repair physical stuff because parts wear out. Software doesn't wear out.
In my opinion, it would be better to set a support window where a company must provide updates to fix flaws or security issues based on the type of device. OSes could be 5 years, safety recalls for vehicles are already covered. I'm not sure any action is really necessary on this.
You repair physical stuff because parts wear out. Software doesn't wear out.
In my opinion, it would be better to set a support window where a company must provide updates to fix flaws or security issues based on the type of device. OSes could be 5 years, safety recalls for vehicles are already covered. I'm not sure any action is really necessary on this.
Software doesn't wear out?! The landscape changes constantly and updates are often necessitated by changes in the security landscape.
I don't expect the manufacturer to do the maintenance work indefinitely, but don't understand why perfectly good hardware should be turned into e-waste after a short number of years despite there being people who are willing to do all the work.
I can imagine a future in which a company has to guarantee a certain time frame for security updates and, once that time span ends, allow third party access. This would at the very least involve unlocking the bootloader so that reimplantations can be installed.
I don't expect the manufacturer to do the maintenance work indefinitely, but don't understand why perfectly good hardware should be turned into e-waste after a short number of years despite there being people who are willing to do all the work.
I can imagine a future in which a company has to guarantee a certain time frame for security updates and, once that time span ends, allow third party access. This would at the very least involve unlocking the bootloader so that reimplantations can be installed.
Often times the hardware is obsolete and has security issues by the time the software is. I don't see any real benefits. What hardware gets turned into waste due solely to software standing in the way?
Software is limited to IP. You can’t really compare hardware right to repair with software. If you use OS software then you can chop and change as you want as long as you merge back changes to the original code. I doubt however that companies like Microsoft would allow you to update the Operating System just because you don’t like the way something works.
I recently read a post where a company didn't release a 64-bit driver for their scanner.
This should absolutely be banned. Either release the source code, or build the code yourself.
There is no need to throw away a perfectly good scanner, which you can still get repaired, simply because the company prefers to sell you a new one.
This should absolutely be banned. Either release the source code, or build the code yourself.
There is no need to throw away a perfectly good scanner, which you can still get repaired, simply because the company prefers to sell you a new one.
Surely the 32-bit driver would still work on 64-bit systems?
How would that apply to SaaS, where everyone seems to be heading?
Perhaps you could change copyright law to require either public source code or source code escrow before software could be eligible for copyright protection. Plus some default rights, like right to modification, rebuild and reinstallation for individuals.