• boonhet@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    8
    ·
    2 days ago

    GPL doesn’t allow for closed source forks. MIT does. You can add extra features without removing compatibility, by adding new flags, etc. Though I do struggle to come up with what premium features cp, mv and rm in particular could be expanded with.

    • thingsiplay@lemmy.ml
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      2
      ·
      2 days ago

      I don’t think that is a problem. As long as the GNU tools behave as the original ones, that’s okay. If someone wants to target Ubuntu extensions of the tools, they can. Also when did any Linux distribution anytime locked up their own version of MIT tools without sharing the source code?

      It just feels like people are making up issues that aren’t.

      • boonhet@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 days ago

        Also when did any Linux distribution anytime locked up their own version of MIT tools without sharing the source code?

        I mean RHEL has been kinda doing it with GPL for a few years. They share the code with you if you have a subscription, since they have to, but if you share it with anyone, they’ll void your subscription contract. With MIT you can skip that scheme altogether and just make version closed source.

        Like… Why else would they use MIT here? They could have just used GPL for the Rust coreutils.

          • boonhet@sopuli.xyz
            link
            fedilink
            English
            arrow-up
            1
            ·
            2 days ago

            GPL for separate tools is compatible with everything. It only becomes an issue if you’re shipping a custom version of a GPL tool.