One more small step toward the right to software repair
sfconservancy.org
sfconservancy.org
A related issue that is somewhat the inverse, which has always bothered me, is the seemingly intentional sabotage of performance and hardware by way of software updates, essentially building in incremental sabotage and obsolescence.
What I am referring to is that fundamental performance is negatively impacted by OS updates that are usually mandatory, e.g., an iPhone or windows computer cannot load a basic website as fast as it could in the past, a basic function of the device, due to imposed software updates.
There should be a legal requirement that the basic functions and performance of a device cannot degrade without justification over time. Imagine if your car required mandatory computer updates or maintenance that resulted in things like losing 100hp over 5 years, or it took longer and longer between hitting the unlock button and the locks actuating, or the brake responsiveness got worse and worse with every update; and then being told you have to buy a new car to get all those features back.
I understand that there are certain things that cause preference degradation, but when it is imposed without real choice and there is no incentive for developers to actually prevent degradation, then there is also San incentive to intentionally sabotage customers.
If anyone remembers the push and emphasis on performance that Steve Jobs imposed on apple engineers after using an older apple device, it is clearly possible. I clearly recall that when that update went out, it majorly improved the performance and UX of older apple devices.
Every CPU cycle used by software, including an Operating System, depletes a limited pool of immediate resources.
If the same device and functionality I enjoy have not changed, then the room for concern arises.
When I think of planned obsolescence and sorta-unintentional performance regressions on desktop operating systems, I'm instantly brought to YouTube's Polymer website and UWP. Two complicated things but they largely only benefit the developers of the software and have not actually delivered any features. Google is a huge part of the desktop world and they're not so "external" as pabs3 says and to me it's just part of the software right to repair movement.
Now 14 suddenly isn't an option anymore. Exploits are still found and the only way to patch them seems to be to go to iOS 15.
Luckily the latest Nokia clamshell phones have good mobile broadband support and also support Telegram and Signal it seems. With the price difference between a brand new iPhone and a brand new Nokia clamshell I can also buy a really good camera and then I think I got it sorted mostly.
Banking apps have mechanisms to check if there's an update available and not give access unless you install it. You then can't install the app update unless the OS is sufficiently new.
There should be no right that barring some major security changes, that core functionality is not only impacted, but that added features impact performance or that a user should have the right to choose performance over features.
I reiterate my example, would it be ok with you if your car lost 100 hp or 20 mpg fuel economy over 5 years because there were things added to your car that weigh it down so much or due to a roughshod rebuilding of your engine every time you changed your oil?
It is really a clear case of fraud and destruction of property when, e.g., a phone becomes so laggy that it is unusable over 5 years solely due to updates that were imposed and required by manufacturers even if they try to justify it by adding things you did not request or need or want.
I am actually surprised that an enterprising technology aware lawfirm has not latched onto this issue. It seems to me to be a rather simple case of proving at the very least the negligence and willful destruction and degradation of others' property.
To simplify the concept, e.g., we are constantly told by phone makers that next-phone is N times faster/more powerful; so how is it that the phone I was told is 5 times more powerful than the predecessor, all the sudden lags when swiping between home/app screens or launching a dialer, a core functionality that hasn't changed in years and like it never did before?
At best, we are facing an immensely sloppy industry that damages our products and property through forced updates; at best.
Could you expand on this? Why wouldn't you want a machine that's not running spectre mitigations on your network?
It would for example mean that your webserver needs to find out if the client has the bandwidth, CPU, memory and GPU resources available for a full site, a self-degrading site or a minimal site. And then users would complain that their experience is different from their friends and family because they have a different device and people will claim segregation or come up with a 'right to be treated the same on the internet' or something like that.
Your device is essentially frozen in time as soon as manufacture is complete. The world around it keeps changing. Some of those changes are new insights, such as knowledge that power management needs to be adjusted to prevent brownouts, and hardware-level bugs that need to be mitigated to not break the interconnected world we live in.
Is this not how things are managed on basically every Linux distro?
That's just concerning OS updates but it sounds like you're asking about a piece of software that is something entirely different. From my understanding, a good practice is to have all minor updates be compatible and only break that on a new major release. So don't make evey update a major release, doing that is actively hostile to users.
If you send them the software, they reverse engineer it and fix bugs that's not distribution.
If you send it to them, they fix bugs and then start using it themselves that is distribution.
However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.
https://www.gnu.org/licenses/gpl-faq.html#InternalDistributi...
So whether the FSF calls something distribution in their own FAQ is irrelevant, unless the FSF is your lawyer and giving you legal advice.
I used to be able to fix a Morris Minor; but I wouldn't dream of trying to fix anything but the bodywork on a modern car.
https://en.wikipedia.org/wiki/Computer_Programs_Directive
Wikipedia says that software ToS can override the legality of reverse engineering in the USA:
https://en.wikipedia.org/wiki/Reverse_engineering#Legality
It also sounds like in the US the modifications allowed are only for circumventing DRM, and only for interoperability, not for adding features or fixing bugs.
I don't understand what contract law has to do with this case. I was actually mildly alarmed to hear that they think using GPL software somehow enters them into a contract. If I read it correctly. That could become quite nasty and be very bad for FOSS if a court upheld the idea, since it's often corporations relying on FOSS and not the other way around.
But many lawyers have advised us that contract law is a useful parallel avenue. This approach has the advantage of empowering users of the software who are not necessarily copyright holders. The mantra of “the GPL is not a contract” is a mistruth that has been so often repeated that it became widely accepted and typically unchallenged. (We expect you'll hear this theory repeated even more loudly now that the our Vizio lawsuit brought the question to the forefront in a federal court case.) Yet, prominent legal experts outside of FOSS social circles have long scoffed at the assertion. Indeed, case law in the USA has held the opposite. In multiple cases, courts have been convinced, specifically, that the GPL operates as both a contract and a copyright license. The law appears clear on this, and this is among the reasons why we believe our motion to remand will succeed. In short, we'll say it plainly here and now for everyone: the GPL operates both as a copyright license and as a contract; litigation can proceed under either of those legal theories. Our motion to remand in the Vizio case explains the legal details as to why that's true.
As IANAL, I'm unable to judge if the cases they cite in the motion back up the "GPL is a contract too" idea though.
After Log4J this was the first thing that jumped at me, not the anticapitalist argument.
Now Copyright is a bit more difficult, because the process of reverse engineering code to fix a bug can also mean copyright can be discovered, ie learning how something works, like a driver for some hardware to work in an operating system or app.
Also, as far as copyright/patents are concerned those aren't a Problem with reverse engineering. If you reverse engineering something and you then discover copyrighted code while fixing a bug that's not a problem. Knowing of that code is not copying it.
If you were to copy that code or use knowledge you gained by reverse engineering to build your own product that would be an issue though.
> If you were to copy that code or use knowledge you gained by reverse engineering to build your own product that would be an issue though.
And thats the hard part, how do you prove a thought process existed before you had your thought confirmed by seeing it used in some code that you are reverse engineering? Even if I had written such thought down, proving the date & time on the piece of paper isnt back dated is also tricky.
Yep. AIUI doing such things as reverse-engineering to analyze malware (or to detect otherwise malicious behavior, such as breaches of GDPR) is not permitted.
Would it be legal to share the binary diff of the fix, provided it contained none of the original binary?
I've worked as a software engineer writing embedded code, at several hardware companies, and nearly all of them see software as just another line item on the BOM, like a bolt or a screw, to make as cheap and quickly as they can. "We need to source 32 screws, 50 resistors, 45 capacitors, a waterproofing gasket, oh, and this 'software' thing. Make some 'software,' and ensure we fasten it to the product at station 25 on the assembly line." That's almost certainly how Vizio thinks of its software.
Yeah to my knowledge that's exactly right, that is how they think about software. In Japan especially, outside of some places like Nintendo, that is how they think.
It kind of blows my mind that this is the case. Do these companies not realize that bad software can easily tank their product?.
At some point during development, some non-software person at the subcontractor looked at the software, checked some checkboxes and said "Yup, this horrible thing our devs cobbled together in a frantic rush meets the minimum criteria that were spelled out in the contract we signed with TvManufacturer. Ship it!"
What about Cisco and Mikrotik?
It’s been a couple years since I have used Cisco but have a bunch of friends that manage large deployments and it doesn’t seem to have improved since I was doing my deployments.
Agreed. They probably only want to hide how they use Open Source software to spy on people. https://pluralistic.net/2021/11/14/still-the-product/#vizio
* Developers looking to try out new tech are increasing looking towards hosted free tiers instead of OSS. It’s just easier not having to figure out how to run a backend.
* The well documented (in this article) push away from copyleft licences due to the selfish and non-participatory approach of major cloud providers to OSS.
* The reduced incentive to contribute to OSS as hiring trends have drifted away from positive contributions towards leetcode etc.
OSS in the end is not less technical debt, but it's less urgent and less centralized and better to monitor. Less volatile than any end to end solution.
I disagree. It takes time for open and free alternatives to newer software to emerge. Sometimes they never do. What is going on is that a lot of software is niche, and doesn't have the huge, horizontal utility of say, the Apache web server. At this moment, commercial clouds are at the center of a lot of applications, and the cost of cloud computing may require significant revenue to support operating the software. As open source, self hosted clouds become more popular, things will change.
>The well documented (in this article) push away from copyleft licences due to the selfish and non-participatory approach of major cloud providers to OSS.
I'm not sure they are non participatory. I do see where some creators of open source end up having to compete with AWS, but this literally has been the case forever. For example, many early mailserver and mailing list publishers ended up competing with the neighborhood ISP for email and mailing list hosting. It's the same old same old, just the names are different.
>The reduced incentive to contribute to OSS as hiring trends have drifted away from positive contributions towards leetcode etc.
This isn't true, either. Most companies jump when they see an open source developer, because we know very well what that developer is capable of. There's more to a developer than ability to write software, and I suspect a lot of the weird hiring processes out there are biased towards non-development skills. For larger companies, there's ability to adhere to policy, political/people skills, ability to produce under absurd levels of pressure, ability to tolerate incompetence, and your ability to be a good non-squeeky cog in the machine. A lot of open source developers don't have those skills, and probably would not stay very long at a company that interviews for those skills.
The trend towards skills verification (leetcode is one of the many ways to do this) is a counter to the number of people who are simply unskilled or lack sufficient practice to work as a professional developer at the level they are applying for. When I advertise jobs, 84% of the applicants are either flat-out unqulaified (missing required items on their resume) or fail a very simple "write a function that does a and b and returns c.
As the usual security exploits in FOSS prove, no one, including big corps is willing to make it work as per ideals.
So in the end we get back to the shareware and public domain that dominated the 16 home computers, we just call it dual licensing, or put it behind SaaS walls.
For authors who want to maximize the freedoms of developers who directly download their software to make and redistribute derivatives and reverse dependencies and to redistribute the whole stack of their application under their choice of license with no obligations other than a notice requirement, yes, MIT and BSD style licenses maximize those freedoms.
For authors who want to maximize the ability of indirect downstream end users of their code, even those who are unaware of the origin of the code running on their system, to make sure they can fix it or have it fixed to remove bugs or better meet their needs, copyleft licenses such as the GPL do better protect those freedoms.
For the user-style freedoms in the above paragraph as applied to direct (rather than indirect) downstream users of the software author, either license is equally protective.
All of these licenses protect software freedoms, but they differ a lot in the details.
One of the reasons it feels that way is that there is way more software out in the wild than before. Because there is just more of it, you can draw potentially false conclusions based on where you look.
From my perspective (I work in Javascript land), OSS is going through a renaissance. There is so much high quality OSS software out there is kind of blows my mind.
Fixed that for you.
Don't underestimate the silent masses who still depend on doing things "the old fashioned way". The internet can provide us with a very distorted view.
I think that if this case succeeds, it would actually be a huge blow for the GPL. We are actually just now starting to get over all the FUD about the GPL and convince corporate lawyers to allow using GPL. However, if they win this case on those terms, I expect every corporate lawyer to to have major heartburn about GPL. If for example, they successfully are glue that GPL gives every user of the software the right to sue, doesn’t that massively increase liability for the corporation? I can see many lawyers pushing to completely ban copyleft licensed software use.
That's obviously not the best possible outcome, but I feel it would be preferable to corporations flagrantly violating the license and getting away with it. They should really understand that it's a trade-off: use GPL software and release the source (thus avoiding this liability), or pay the cost of developing proprietary software.
IMHO they already are liable here, some of them just haven't realized it yet.
IANAL
Software repair will come from different kind of regulations, not from bullying companies for not being careful with software licenses.
(Sidenote: if you use GitHub, the Insights page can help you find out whether one of your dependencies use GPL, so that you can seek alternatives).
"Software Repair" is a feature, not a God-given right. And isn't it always better if the maintainers of the software do it for you so you don't have to do it yourself? If they do it it will benefit others besides the single do-it-yourself software repairer.
In practice I think only the maintainers of an open sourced software will actually fix bugs in it, although many users may report bugs.
Therefore there needs to be some mechanism which promotes the flow of financial incentives to the maintainers of open source software.
Dual-licensing would seem to be a solution. Give the bug-fixes and improved features, usability and performance improvements to paying customers first. If there are security problems those should of course be expeditiously shared with everyone.
It isn't always better for the maintainers to repair software, since they could refuse to do it, take years to do it, require more money than you have to do it, or require signing unacceptable agreements to do it and also since maintainers are overworked already, so preparing a good patch and sending it back to them helps reduce their workload. I personally have fixed many bugs in open source software I am not maintainer for, including a couple in the Linux kernel. There are many software developers and other technical people who are in this position.
Dual licensing can lead to the downstream customers of the customers taking out the non open source license being stripped of their right to repair the software. Personally I think it would be better to keep all copies of open source software under an open source license. There are many different ways to fund open source other than dual licensing, many of them benefit the maintainers too:
Copyright iteslf is fairly new (I belive from 1710 "Statute of Anne" for firs limited kind of copyright).
For much of human civilization, and some of greatest works of art were done before idea of copyright existed.
sfconservancy lays out why they don't agree with that in https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
For every Red Hat out there there are thousands of consultancies that have tried to be true to the copyleft ideals and failed.
So, nothing happened yet.