69
Ubuntu 25.10 Switches to Rust-based Sudo (www.omgubuntu.co.uk)
submitted 1 year ago by to c/rust@programming.dev
30 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (2 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 5 points 1 year ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 year ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    So, you had to choose between the code that was still Open Source and the code that was now proprietary.

    If you stick with the Open Source, what you describe does not happen.

    If you moved to the proprietary, well, there you are. You clearly decided that the new features were more important than it being Open Source.

    Remember, it is only the new features. All the old code remains as open as it ever was.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago

    So, you had to choose between the code that was still Open Source and the code that was now proprietary.

    You are skipping ahead. The code the userbase follows may become the proprietary one.

    If you stick with the Open Source, what you describe does not happen.

    And this isn't guaranteed with a permissive license.

    If you moved to the proprietary, well, there you are. You clearly decided that the new features were more important than it being Open Source.

    If this change happens without the knowledge on the userbase now the Open Source solution needs to advocade for it. And its competition supports all of its features and more. And will clearly upstream any features it adds as well.

    Don't get me wrong - I don't mean to abandon all projects done by corporations. But a better license gives safety to all users.

    Remember, it is only the new features. All the old code remains as open as it ever was.

    You are not considering vendor lock-in, upstreaming open source changes, less transparency in regards of security, attributions, changes to contributer license agreements, conflicts of interest and probably more things.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 1 year ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 1 year ago (1 child)

    The original code remains available under the original.

    Any proprietary code would have to be code that was added on top of that.

    You always have the ability to keep using the Own Source code. That is a freedom you have.

    If you decide that proprietary version is “better” and choose to use that, well that is a freedom you have. But now you have accepted a proprietary license. Your choice.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago

    Any proprietary code would have to be code that was added on top of that.

    That generalization is wrong. If the license does not state that freedom one can revoke said thing. The author(s) can change the entire license.

    If not stated you may be able to fork off a previous version. Depending on the CLA (or its absence) you may have to speak with any contributor prior to publishing your fork!!!!

  • permalink
  • fedilink
  • source
  • parent