One more small step toward the right to software repair(sfconservancy.org)
sfconservancy.org
One more small step toward the right to software repair
https://sfconservancy.org/blog/2021/dec/28/vizio-update-1/
90 comments
A lot of performance degradations are driven by external factors; increase in the prevalence of JavaScript, a larger variety of web features, higher resolution images, higher resolution video, new video codecs, new image formats, advertising etc. Some degradations are driven by fundamental physical things, for example batteries and storage devices have physical degradation. So you have to be careful how you define things.
Alot. But not all.
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.
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.
I don’t know about this take, software updates when it comes to consumer products have never been mandatory, only perceived as mandatory in order to gain some new feature. As a developer, there are times we have to compromise old logic in order to add new logic. In other areas of life we call those changes progress.
But there's no distinction between a security patch and a feature update. And it's never just an update to only get new features. It's to get bug fixes and better compatibility with new programs (I'm thinking of libraries and dependencies). And there's the case of Windows and Chrome OS, where software updates cannot be opted out of by official means.
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.
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.
[deleted]
I was intent on keeping this iPhone on iOS 14 until Apple released a statement that they had buried their plans to introduce what I see as spyware or the precursor to spyware.
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.
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.
Just off the top of my head, OS updates are mandatory if you do any mobile banking.
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.
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.
But that's the bank choosing to do that for security reasons, not the operating system developer
What about the slowdowns due to the Intel chip bug mitigations? That’s the biggest slowdown I have experienced of on Xeon based computer. It is significant.
That is something you can and always could disable. I would however not want someone with a buggy system in some of my networks which makes this choice have side-effects in some scenarios.
> That is something you can and always could disable. I would however not want someone with a buggy system in some of my networks which makes this choice have side-effects in some scenarios.
Could you expand on this? Why wouldn't you want a machine that's not running spectre mitigations on your network?
Could you expand on this? Why wouldn't you want a machine that's not running spectre mitigations on your network?
Because they want to maximize performance rather than a security patch that they believe, rightly or not, is a mitigation against something that think is a small risk for their use case.
I anticipated a response like that and you have a valid point, but it does not explain nearly all the issues. Just as an example, not only why does simple swiping home screens on an iPhone/iPad lag after a few years when nothing has fundamentally changed about that behavior, but an even greater question is why is it permissible that/if other features and expensive computations are added that are impacting performance of such fundamental and core functionality/behavior.
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.
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.
I doubt this is something you can construe as a 'right'. Pretty much everything you list is happening due to side-effects and interconnected ecosystems. What you want would also require significant continuous investments of all other interconnected parts.
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.
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.
If we could make progressive enhancement trendy again, then every site would be usable on ancient devices, but newer devices (or browsers with more features enabled) would get slightly nicer interaction methods.
https://en.wikipedia.org/wiki/Progressive_enhancement
https://en.wikipedia.org/wiki/Progressive_enhancement
A persistent downside of this is that you cannot give everyone the same experience and the cost of doing this might outweigh the commercial benefit. If you find that less than 5% of your users use crappy devices because they aren't broken enough but out of those 5% only 0.1% generate any revenue, you might simply choose to ignore them so you can focus on that 99.9% of other revenue.
You cannot give everyone the same experience anyway, because everyone has different devices implementing different sets of web features and different sets of web browser extensions disabling various user hostile things that were added to the web platform over the years.
I would be happy if updates weren't forced on users. Allow the user more granular control of when and what to update
How do you make all the updates compatible then? If you released 100 updates , which is a very small number for any software, you now have 1267650600228229401496703205376 different versions of the software that the clients can be running for releasing your 101th update.
Of course updates need to be consecutively applied, but we don't have to force them on the user when they're released. We also don't have to force unrelated updates when they only want an update for one specific package (dependencies forgiving, of course)
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.
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.
Lots of Linux distros are moving towards automatic upgrades by default, since otherwise users won't bother to apply security updates. Of course you can definitely disable that and upgrade manually.
Which distros? This is the first I'm hearing about it
Debian for example now does it, not sure about others but I expect lots of the mainstream ones are.
I might be mistaken, but at least in Europe (but I believe it's the same case for the US) reverse engineering proprietary software in order to fix critical bugs, add necessary features or port it somewhere else out of necessity is allowed, provided you don't share the modified program. Of course being able to share your fixes would be great, but in a sense Software Right to Repair already exists and is in a much better shape that the Hardware's one
The problem is that most people who would need and benefit of those changes don't have the time or skill to make them themselves. So being able to share and distribute the modified version is an absolute bare minimum for the right to repair.
Hiring your own people to branch and maintain the software for your own purposes is not "distribution". If you're a company relying on software you don't own, and you need it to do something different, you can hire coders to maintain it in your direction. That's totally different from reselling it.
When the people you are hiring are an external contractor, that probably counts as distribution though.
It only counts as distribution if you give it to them and they start using the software as well.
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.
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.
No, I don't think so. If the company has the right to edit the code, then it can contract that out. If someone paid the company to clone or use the code, that would be distribution.
From the FSF's GPL FAQ:
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...
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...
For use off-site. Hiring a programmer off-site to maintain it isn't "use". Giving it to someone to use in
a productive way in furtherance of your business or in exchange for money would be "use".
Distribution matters because it triggers legal consequences--you need a license to distribute. The FSF can't rewrite the law. So they can't say "doing X is distribution" and then claim that doing X requires a license.
So whether the FSF calls something distribution in their own FAQ is irrelevant, unless the FSF is your lawyer and giving you legal advice.
So whether the FSF calls something distribution in their own FAQ is irrelevant, unless the FSF is your lawyer and giving you legal advice.
Quite. Being allowed to fix the OS yourself, but not share the result, is like being allowed to fix your car yourself, but being forbidden to set up business as a mechanic-for-hire.
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.
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.
You made me wonder if sharing a patcher that modifies the program files would be legal under the EU law.
IANAL but sharing the patcher probably wouldn't be. Sharing the code it patched, or a patched version of that code, would be piracy.
In the EU it sounds like the modifications allowed are limited to "within its intended purpose", which could block some modifications, although it would be hard to discover modifications you made locally without sharing them.
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.
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.
In Europe, I understand it as only legal to reverse engineer to fix bugs, thats it.
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.
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.
You are allowed to add necessary features or port the software as well. Of course, what counts as a "necessary feature" is always up to debate, but if you for example own a software that only runs on Microsoft DOS and you want to port it to Windows 10, that's allowed.
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.
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.
I dont think I've ever sold software, just a licence to use said software, so I think my old dos programs will be safe.
> 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.
> 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.
> In Europe, I understand it as only legal to reverse engineer to fix bugs, thats it.
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.
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.
This is true in America as well. You stated it exactly. The recipient of a binary or a set of scripts who has a right to use them in production also has a right to repair them, just not to distribute them.
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.
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.
The article clearly states that the GPL is both a license and a contract:
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.
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.
The article asserts that in their opinion, it's a valid legal theory that GPL constitutes a contract. One hopes the courts will put a limit to what that "contract" entitles the users of GPL software to sue coders for.
Agreed with the second part, hopefully users of GPL software would only be able to sue for GPL violation and only be able to obtain GPL compliance, rather than damages of any kind. Also, at least with GPLv3 there are some ways to get the license back by coming into compliance.
They assert that it has been courts opinions too.
True. They assert it. I think as a brief, they doth protest enough to make you wonder how much is settled law and how much is looking for precedent.
They are absolutely looking to create precedent on the "third-party beneficiary of the GPL" idea, which will be great for users of GPL software if it happens.
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.
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.
I think we're on the same page, as I'm no fan of allowing intermediaries to copyright something that was copied left. But the idea that a third or even a second party can treat GPL as a contract ... doesn't that potentially create enormous liability for the creators of the original code? I mean I guess "as is" is plain enough, but...
After Log4J this was the first thing that jumped at me, not the anticapitalist argument.
After Log4J this was the first thing that jumped at me, not the anticapitalist argument.
The case is simply about giving a second way for GPL compliance to be enforced. The copyright holders (the original authors or probably their employers) have always been able to enforce the GPL against violators, but when a large portion of the electronics industry is violating the GPL on Linux, it becomes infeasible to enforce it against every company, so outsourcing that enforcement to people actually affected by that GPL violation, and possibly even opens up GPL enforcement via class actions, which makes things much more even again. I don't think the creators of the original code would have any liability and anyway as the original authors who chose the GPL as a license, they probably know how to comply with it and are already in compliance.
As an example, the home DSL router my ISP supplied violates the license of at least Linux (GPL), samba (GPL) and microhttpd (BSD).
There's really no such thing as settled law. E.g. Roe.
To see the absurd legal overreach of these laws, write "examining how it works" instead of "reverse engineering".
> [...] allowed, provided you don't share the modified program
Would it be legal to share the binary diff of the fix, provided it contained none of the original binary?
Would it be legal to share the binary diff of the fix, provided it contained none of the original binary?
As anyone who has used a Vizio TV knows, the software is really of no particular value. Input lag abounds. They should dump it all out on Github and move on as the software could not possibly be construed as any kind of moat for them.
There are many hardware companies where their embedded software is not actually a crucial moat or even value-add, compared to open source options. Look at WiFi routers: Do any of them have software that is better than OpenWRT or Tomato? Why do they even try? If I were Netgear or ASUS, I'd get rid of 90% of our software developers and just use one of the great open source options. Why is anyone spending money developing bespoke router firmware?
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.
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.
> 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.
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.
> 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
It kind of blows my mind that this is the case. Do these companies not realize that bad software can easily tank their product?.
It kind of blows my mind that this is the case. Do these companies not realize that bad software can easily tank their product?.
They don't seem to realize, nor care. I mean, my cable box's UI is horrendous. Icons that look like they were cut/pasted from a "Download Powerpoint Clipart" web page, complete with obvious aspect ratio bugs. 16x8 pixel bitmap fonts straight out of 1988, UI elements not centered, not padded/inset consistently, silly full-saturation colors (like someone literally picked 0xff0000, 0x00ff00, and 0x0000ff for their color palette), poorly translated error messages ("feature not invoke"), button presses take 1-3 seconds to take effect, channel changing takes 2 seconds. It's like a 15 year old's HelloWorldGUI project made it into production.
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!"
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!"
It is not a problem until someone comes along with a significantly better experience (eg. Apple). Until then, the mass market cares more about price.
> Do any of them have software that is better than OpenWRT or Tomato?
What about Cisco and Mikrotik?
What about Cisco and Mikrotik?
What about them? Cisco software would regularly crap the bed and the only thing I would trust mikrotik for would be l2 stuff. I remember some choice bugs where Cisco failover would constantly flap and take our external routers down when using certain gbics that were bought and labeled from Cisco. Their TAC was like, yea, we found those to be incompatible and refused to replace anything, until I showed them our new juniper routers.
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.
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.
> the software is really of no particular value
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
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
It does feel like we’re coming towards the end of the open source era, imho for several reasons.
* 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.
* 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.
> It does feel like we’re coming towards the end of the open source era, imho for several reasons.
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.
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.
I feel the opposite. Each day more and more projects are choosing to launch using truly free licences like the MIT or the BSD. Software now is more open and freer than ever.
You're free to license things however you wish, however let's not delude ourselves into thinking that permissive licenses somehow result in more "freedom" than copyleft licenses. The only freedom that you get with a permissive license is the freedom to make code non-free, which is to say, permissive licenses result in strictly less code being free.
Depends on which freedoms a given software author prioritizes.
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.
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.
I think anyone who starts to get serious about writing software quickly ends up chafing at the constraints imposed by the free-to-paid pipelines. You get to a point where you're paying $500/mo for some project and you realize, well, I might not migrate that thing but I can definitely do it a lot cheaper for the next one if I learn some new chops. And when you face a client you can tell them how much you'll save them (or you can pocket half of it). The easiest hosted solutions are always good for trying things out, but would I commit a client's software to being backed by one? I don't even know if they'll be around. At least if I know my own infrastructure I know I can chill without being updated without warning or someone going out of business.
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.
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.
This is probably harsh to say, but if a $500/mo expense is what breaks the bank, you can't seriously claim to be operating commercially successful software. Even small businesses spend $XX,000 a month on labor and transaction fees and vendors and rent...etc. If the option is $500/mo for some other guy's work or $3,000/mo to hire a new developer to work on recreating the already existing system full-time, the choice is pretty clear.
I'm not doing commercial software for end users. My projects are usually in-house apps for midsize businesses. The largest one is a local hotel chain whose entire server infrastructure I've gotten to under $400/mo. That serves their employee-facing apps (front desk and back-of-house), their reservations system (~1k bookings per day), their website (~100k uniques per month), email systems and training software. If I told them it was going to cost $3k a month, they wouldn't balk. But they've compensated me well for being able to shave it down considerably over time. It's a great company that appreciates owning their own code. If I can write software once that they would otherwise have to pay a subscription for, they'll happily shell out $100k for their own version if it saves them $2k/mo in SaS. Much of what I've saved them over time has gone into my own bank account, and they've ended up with a pretty amazing ecosystem. But also, it has to do with hard lessons I've learned from not relying too much on SaS platforms. So many have come and gone since I started writing software. In the end each one becomes a single point of failure.
Small businesses are definitely not casual about 500$ mo. It is also unlikely you need to rewrite small business shop entirely to move it or that it would take too long time.
Speaking for myself, the FOSS ideals were great while I was an university student and most of my expenses were paid by external sources, the moment I got to try to make a living out of it, I ended up like the majority, back to commercial products.
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.
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.
> Developers looking to try out new tech are increasing noisy about hosted free tiers instead of OSS.
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.
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.
> It does feel like we’re coming towards the end of the open source era, imho for several reasons.
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.
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.
> 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.
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.
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.
The copyright holders can already sue for GPL violations (and some do), so if corporate lawyers are fine with the GPL now and companies are complying now, they should be fine after the case is won. The problem will come for companies like Vizio who aren't complying.
In the argument of the SF conservancy, the contract is between a distributor of the software and someone receiving the software. If a company only writes the GPL software in question, they wouldn't be liable to their customers in the same way as in this article because they aren't on the receiving end of any code. If a company uses and redistributes GPL code someone else wrote, they could be sued by their customers to enforce the GPL, but SF conservancy argues that's a good thing.
IANAL
IANAL
> 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.
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.
If our choices are "GPL enforcement remains basically nonexistent, making the licence useless" and "GPL is enforced, but doesn't see much corporate use", I'll take the second option. If I wanted adoption above all, permissive licences exist. The GPL is a "viral" licence and should be treated as such.
I don't think GPL will help in the software repair space, at all. If they are able to get Vizio to distribute their source code for this, I forsee Vizio just doing a clean room rewrite to move away from the codebase... and even more companies will never touch anything GPL with a 10-foot pole.
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 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).
I think dual-licensing is a good solution. Customers who want to profit from your software will purchase a "shared source" license. Customers who care for Open Source will use and detect bugs in the copyleft licensed version.
"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.
"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.
"Software Repair" is a GPL and copyleft given right though, which is what the Software Freedom Conservancy lawsuit is attempting to prove.
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:
https://github.com/fossjobs/fossjobs/wiki/resources
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:
https://github.com/fossjobs/fossjobs/wiki/resources
> I think dual-licensing is a good solution.
sfconservancy lays out why they don't agree with that in https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
sfconservancy lays out why they don't agree with that in https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
That’s all cool and dandy, but I highly doubt SF Conservancy would pay my bills while riding their high horse.
For every Red Hat out there there are thousands of consultancies that have tried to be true to the copyleft ideals and failed.
For every Red Hat out there there are thousands of consultancies that have tried to be true to the copyleft ideals and failed.
It is "god given right".
If no "human" law would exist, you could repair and sell that.
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.
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.
> While Vizio's original request to “remove” the case from state court to federal court is, in the general sense, a standard litigation tactic and our response is a relatively standard response
So, nothing happened yet.
So, nothing happened yet.
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.