Ubuntu 25.10 will replace the sudo command with sudo-rs, a new Rust rewrite designed to improve memory safety and security. What does this mean for users?
I don’t see a problem. If someone forks it and changes the license to some proprietary, then their fork is proprietary. The original software is still Open Source. People act like as if the original license changed.
The issue is big companies.
Google/Amazon/Microsoft can now fork sudo-rs and not have to upstream their changes.
So then Google fixes an exploit for their sudo-rs implementation (or whatever software) and patch it under a different licence. Now the upstream, Amazon and Microsoft forks don’t know if that exploit is also in their implementation, is related to their implementation, or how to potentially fix it.
The only way it works is if sudo-rs is implementing new features in a way that it benefits Google/Amazon/Microsoft to contribute back to upstream so they don’t have to keep merging/fixing their exploit code.
For something as stable as sudo, it actually benefits Google/Microsoft/Amazon NOT to share their changes.
If they are rolling and recommending their own distros (which I’m sure they already are) that include their forked changes, then they can say that their software is more secure than other brands.
It benefits them for their competition to suffer security breaches, especially if they trace back to these kinda changes.
@towerful@thingsiplay This entire reasoning is based on assumptions, and frankly quite flaky ones at that.
Forking software is a lot more effort than upstreaming fixes, and any company I’ve worked with was very hesitant towards forking. Surely big companies have more resources to do it, but they need very good reasons to spend those resources.
@towerful@thingsiplay Maybe some of these companies are maintaining internal distros, I don’t know, but we do know they are not sharing those publicly. So the argument that they can say their software is more secure doesn’t work, since there’s no public audience for these internal distros to be promoted to.
And it the fork gets adapted the user base doesn’t use an open source project anymore.
Changes which aren’t synced get shipped and you can’t substitute anymore.
Permissive licenses are bad: Someone can take your entire code, build upon it, get hand of the userbase and then make weird changes. They don’t protect the users in any form.
Just imagine someone changed the tools you use daily in such a way that none of your workflows are executed in the same way prior.
You just learn this once you are truly affected. And trust me - This sucks hard.
I don’t see a problem. If someone forks it and changes the license to some proprietary, then their fork is proprietary. The original software is still Open Source. People act like as if the original license changed.
The issue is big companies.
Google/Amazon/Microsoft can now fork sudo-rs and not have to upstream their changes.
So then Google fixes an exploit for their sudo-rs implementation (or whatever software) and patch it under a different licence. Now the upstream, Amazon and Microsoft forks don’t know if that exploit is also in their implementation, is related to their implementation, or how to potentially fix it.
The only way it works is if sudo-rs is implementing new features in a way that it benefits Google/Amazon/Microsoft to contribute back to upstream so they don’t have to keep merging/fixing their exploit code.
For something as stable as sudo, it actually benefits Google/Microsoft/Amazon NOT to share their changes.
If they are rolling and recommending their own distros (which I’m sure they already are) that include their forked changes, then they can say that their software is more secure than other brands. It benefits them for their competition to suffer security breaches, especially if they trace back to these kinda changes.
Which makes everything worse for everyone.
@towerful @thingsiplay This entire reasoning is based on assumptions, and frankly quite flaky ones at that.
Forking software is a lot more effort than upstreaming fixes, and any company I’ve worked with was very hesitant towards forking. Surely big companies have more resources to do it, but they need very good reasons to spend those resources.
@towerful @thingsiplay Maybe some of these companies are maintaining internal distros, I don’t know, but we do know they are not sharing those publicly. So the argument that they can say their software is more secure doesn’t work, since there’s no public audience for these internal distros to be promoted to.
And it the fork gets adapted the user base doesn’t use an open source project anymore. Changes which aren’t synced get shipped and you can’t substitute anymore.
Permissive licenses are bad: Someone can take your entire code, build upon it, get hand of the userbase and then make weird changes. They don’t protect the users in any form.
Just imagine someone changed the tools you use daily in such a way that none of your workflows are executed in the same way prior.
You just learn this once you are truly affected. And trust me - This sucks hard.
Right, but the other fork became its own project. I have no problem with it. As long as the original code license is not changed.
Good luck picking another license than GPL for this requirement.