• franpoli@lemmy.ml
    link
    fedilink
    arrow-up
    126
    arrow-down
    2
    ·
    1 month ago

    While shifting to Rust might be a good idea for improving safety and performance, adopting the MIT license represents a fundamental change that will enable large tech companies to develop and distribute proprietary software based on the new MIT-licensed Core Utilities. This shift moves away from the original vision of the project which was to ensure that the software remains free and open as enshrined in the GPL’s copyleft principles. The permissive nature of the MIT license also will increase fragmentation, as it allows proprietary forks that diverge from the main project. This could weaken the community-driven development model and potentially lead to incompatible versions of the software.

      • franpoli@lemmy.ml
        link
        fedilink
        arrow-up
        28
        arrow-down
        3
        ·
        edit-2
        1 month ago

        Yes, they do. The GPL’s copyleft clause requires companies to release the source code of any modifications they distribute, ensuring contributions back to the community. The MIT license, however, allows proprietary forks without this obligation. In other terms, the MIT license is effectively permitting companies to “jump out” of the open-source ecosystem they make use of.

        • pmk@lemmy.sdf.org
          link
          fedilink
          arrow-up
          6
          arrow-down
          7
          ·
          1 month ago

          I know, but do they? Has big tech contributed to the code base significantly for coreutils specifically? sed and awk or ls has been the same as long as I remember, utf8 support has been added, but I doubt apple or google was behind that.

          • franpoli@lemmy.ml
            link
            fedilink
            arrow-up
            13
            arrow-down
            1
            ·
            1 month ago

            As far as I’m aware, contributions from major corporations to GNU Core Utilities specifically (e.g. sed, awk, ls) have been limited. Most development has historically come from the GNU community and individual contributors. For example, UTF-8 support was likely added through community efforts rather than corporate involvement. However, as these corporations increasingly back projects moving away from GNU and the GPL, their intent to leverage the permissive nature of the MIT license becomes evident. Should ‘uutils’ gain widespread adoption, it would inevitably lead to a significant shift in governance.

          • crimsonpoodle@pawb.social
            link
            fedilink
            arrow-up
            5
            ·
            1 month ago

            Intel does a lot, by which I mean they sponsor people to do it. Changing user facing utils is a bad idea as it breaks things. Although I don’t really keep up with it I know they’ve been changing things like the number of levels of pages etc, over time moving to sysd instead of init and stuff but the latter was a decade ago now. You can probably trace the maintainer to who sponsors them from here: https://en.m.wikipedia.org/wiki/Linux_kernel_version_history

    • InvertedParallax@lemm.ee
      link
      fedilink
      arrow-up
      7
      arrow-down
      3
      ·
      1 month ago

      This is stupid, businesses just use busybox and move on.

      Nobody is freaking out that their smart toaster doesn’t have the full version of troff.

    • Abnorc@lemm.ee
      link
      fedilink
      arrow-up
      3
      ·
      1 month ago

      If this happened, would Ubuntu based operating systems be impacted as well? I might start to learn Debian or LMDE if so.

      • MrMakabar@slrpnk.net
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 month ago

        MIT license is still open source, so Ubuntu based operating systems can still be open source. The problem is that this makes it less needed that they have to be. However most current projects will probably stay proper open source projects and likely continue to use a better license.

    • LeFantome
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      That explains all the fragmentation with Xorg, Mesa, libxml, and Haiku OS.

  • Leaflet@lemmy.world
    link
    fedilink
    English
    arrow-up
    99
    arrow-down
    2
    ·
    1 month ago

    Clickbait. The VP Engineering for Ubuntu made a post that he was looking into using the Rust utils for Ubuntu and has been daily driving them and encouraged others to try

    It’s by no means certain this will be done.

    • lengau@midwest.social
      link
      fedilink
      arrow-up
      22
      arrow-down
      1
      ·
      1 month ago

      Yeah this particular guy also loves doing insane things to his machine. He’s absolutely mental in a wonderful way.

      My personal take on anything Jon does based on my experience with his delightful antics is that the only thing we can say for sure is if it doesn’t work for him it’s just not going to happen. His blog is pretty great to follow.

    • 0_o7@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      20
      arrow-down
      3
      ·
      1 month ago

      Clickbait

      With mental outlaw, it’s usually that or ragebait, to rile up his audience.

    • Arthur Besse@lemmy.mlM
      link
      fedilink
      English
      arrow-up
      12
      ·
      1 month ago

      Clickbait. The VP Engineering for Ubuntu made a post that he was looking into using the Rust utils for Ubuntu and has been daily driving them and encouraged others to try

      It’s by no means certain this will be done.

      Here is that post. It isn’t certain to happen, but he doesn’t only say that he is daily driving them. He says his goal is to make them the default in 25.10:

      My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10, and subsequently in our next Long Term Support (LTS) release, Ubuntu 26.04 LTS, if the conditions are right.

      • EveryMuffinIsNowEncrypted@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        4
        ·
        1 month ago

        His goal.

        A VP could have the goal to increase profits by 500% over the next 6 months but that doesn’t mean it’s gonna happen.

        It might happen, but just because someone says it’s their goal is no confirmation that it will happen.

          • EveryMuffinIsNowEncrypted@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 month ago

            Okay, so it’s likely to happen. I never disputed that. But just because the VP says he intends for it to happen still is not the same as a statement by the company that it will happen. He could get vetoed. He could lose his job. There could be a material shortage. Trademark disputes. A kraken could fly through his window and devour his testicles forcing him to be in the hospital on the exact day the paperwork has to be filed.

            The fact remains this article is titled in a very clickbaity way because it jumps to the foregone conclusion that “want to do” = “will 100% happen”.

  • Mactan@lemmy.ml
    link
    fedilink
    arrow-up
    82
    arrow-down
    1
    ·
    1 month ago

    genuinely my only problem with it is the license. I really hate how much stuff is mit or apache now. I’ve seen some really nice projects get taken over and privatized in the last few years and nobody has learned

    • beleza pura@lemmy.eco.br
      link
      fedilink
      arrow-up
      32
      ·
      edit-2
      1 month ago

      sadly, i think that’s exactly the reason why so many gnu coreutils/libc/compiler competitors keep croping up: people want to get rid of the gpl as much as possible. if they could replace the linux kernel with a non gpl variant they would

      not that the people creating the projects necessarily have this intention, but the projects are certainly being picked up and sponsored mainly for that reason

      • kittenzrulz123@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        2
        ·
        1 month ago

        Imo thats also why its devolped as well, people genuenly like permissive licenses because apparently coporate leeches arent an issue to them.

  • Mwa@lemm.ee
    link
    fedilink
    English
    arrow-up
    37
    arrow-down
    3
    ·
    1 month ago

    Can’t wait for proprietary apps to not work on distros that still use gnu core utilities.

  • BJ_and_the_bear@lemm.ee
    link
    fedilink
    English
    arrow-up
    17
    arrow-down
    3
    ·
    1 month ago

    Hopefully it’s drop in compatible with GNU coreutils else a lot of scripts are gonna break

    • hackeryarn@lemmy.world
      link
      fedilink
      arrow-up
      15
      ·
      1 month ago

      That’s the project’s goal and they have 100% comparability across quite a few of the tools. Definitely still a ways to go before they can fully replace all of coreutils, but Ubuntu’s goal is to replace the tools peace meal with the once that are ready.

    • Badabinski@kbin.earth
      link
      fedilink
      arrow-up
      55
      arrow-down
      1
      ·
      1 month ago

      I love rust and projects rewritten in Rust, but I’ve felt pretty mixed about this particular project. The strong copyleft on GNU coreutils is part of what keeps many Linux distros truly free. There’s stuff like BusyBox or BSD coreutils if you need something you can make non-free, but GNU coreutils are just so nice. I wish this reimplementation in rust had been licensed with GPL or a similar copyleft license. At least there’s no CLA with copyright transfer.

        • moonpiedumplings
          link
          fedilink
          English
          arrow-up
          13
          ·
          edit-2
          1 month ago

          It actually is a language issue.

          Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.

          But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you’re program doesn’t have to be GPL. It’s partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn’t be able to extend proprietary code off of it — not that I care about that, but the library makers often do.

          https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries — it’s complicated.

          EDIT: Nvm I’m wrong. Rust does allow dynamic linking

          Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.

          EDIT2: Upon further research it seems that Rust’s dynamic linking implementation lacks a “stable ABI” as compared to other languages such as Swift or C. So I guess we are back to “it is a language issue”. Well thankfully this seems easier to fix than “Yeah Rust doesn’t support dynamic linking at all.”

          Edit3: Nvm, I’m very, very wrong. The GPL does require programs using GPL libraries, even dynamically linked, be GPL. It’s the LGPL that doesn’t.

          • Mia@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            3
            ·
            1 month ago

            As long as two binaries are compiled with the same version of the Rust compiler, they are ABI compatible. Even if the compiler version differs, I’ve found that changes to the ABI are fairly uncommon. Furthermore, anything exposed through the C ABI is stable, so the problem can be circumvented if needed. It’s not the most ergonomic solution, admittedly, but with some compromises dynamic linking is perfectly feasible.

          • killeronthecorner@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 month ago

            The lack of ABI stability in Rust means they don’t have to commit to language changes that may prove to be unpopular or poorly designed later.

            Swift went through the same growing pains and, IMO, has suffered for it a bit with even quite basic code often needing lots of availability checks. This may seem counter intuitive but Swift is in the unique(-ish) position of having to serve both a huge corporation demanding significant evolution on a regular basis and a cross platform community that don’t want to write an encyclopedia every time a major version of the language is rolled out.

            Rust doesn’t have this issue and I think it’s right for them to allow themselves the freedom to correct language design errors until it gains more traction as a systems language - and it’s quite exciting that we’re seeing that traction happen now in realtime!

          • Mia@lemmy.blahaj.zone
            link
            fedilink
            arrow-up
            26
            ·
            1 month ago

            No that’s the issue: it’s too permissive. It allows corporations or individuals to redistribute and modify the code as closed source, which isn’t desirable for this kind of project.

    • Drito@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      IMHO distros share the same apps. The defaults can differ, the implementations too but the user can install apps that are on other distros.

    • Ferk@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 month ago

      IANAL, but as far as I know there’s no problem with distributing MIT software as a GPL component, since MIT allows imposing extra restrictions (like the share-the-source limitations of the GPL) to the code, so you can in theory turn every MIT software into GPL, what you can’t do is turn GPL software into MIT, so if the GPL software links MIT libraries that are part of its function, that instance of MIT software needs to follow the GPL.

  • lud@lemm.ee
    link
    fedilink
    arrow-up
    2
    arrow-down
    20
    ·
    1 month ago

    Sounds good to me.

    I actually prefer the MIT license too. It’s more open.

    • zagaberoo@beehaw.org
      link
      fedilink
      arrow-up
      13
      ·
      1 month ago

      More open strictly in that it allows free software to be rolled up into proprietary software.

      • lud@lemm.ee
        link
        fedilink
        arrow-up
        1
        arrow-down
        2
        ·
        1 month ago

        So what? Some people just want to make stuff that helps other people.

        A more open license is a way to accomplish that.

        IMO it’s weird to complain that someone makes their thing even more open source.

        • zagaberoo@beehaw.org
          link
          fedilink
          arrow-up
          2
          ·
          1 month ago

          I’m not complaining; I’m clarifying for less informed readers. It’s a subtle and often misleading distinction.

          Calling a license that leads to more proprietary software “even more open source” is absolutely debatable. The only extra restriction is disallowing free software becoming proprietary, which promotes more openness overall.

          You’re not wrong by any means, but people should understand the actual tradeoff when considering licenses.

  • istdaslol@feddit.org
    link
    fedilink
    arrow-up
    3
    arrow-down
    26
    ·
    1 month ago

    Isn’t Rust a Mozilla project, and with the direction they are heading it’s not long until Rust is considered non-free and we‘ll be forever stuck with C

    • Mia@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      22
      ·
      1 month ago

      No, it started as a Mozilla project; it’s been independent for a long time now.
      If anything I expect Mozilla to be among the smaller contributors nowadays from a purely monetary standpoint.

    • Vincent@feddit.nl
      link
      fedilink
      arrow-up
      19
      ·
      1 month ago

      Which Mozilla projects started out as free and are now non-free, i.e. no longer under an open source (or even viral open source) licence?

    • illegalflyer@lemm.ee
      link
      fedilink
      English
      arrow-up
      9
      ·
      1 month ago

      It started there, but now it’s controlled by the rust foundation. If you wanna worry about licensing uutils is under an MIT license unlike GNU coreutils which is under GPL