• arcterus@piefed.blahaj.zone
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 day ago

    It’s already fractured, as I literally mentioned. That’s why it’s hard to write cross-platform scripts. Part of the reason it’s fractured is that the implementations most commonly in use other than GNU coreutils are permissively licensed and thus cannot easily adopt unique features from GNU coreutils.

    In any case, at this point, changing the coreutils license itself will not materially change much in terms of how fractured the existing landscape is given that people could already use Busybox, Toybox, programs from any of the BSD userlands, etc. if they didn’t want to use GNU coreutils for whatever reason.

    • doodoo_wizard@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      17 hours ago

      If it doesn’t matter then why not use the original projects license?

      I know you’re not able to read minds or responsible for the greater rust community but how come when I or anyone else asks the above question of any mit licensed rust project is the answer never “huh, I guess if the license doesn’t matter then we can gpl it no problem!” And always “no, and get your politics out of my code!”

      It clearly matters to someone because everyone’s feet are always dug in to the sand about sticking with mit.

      • arcterus@piefed.blahaj.zone
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        13 hours ago

        Do you make your learning projects that you don’t really care about GPL? I don’t.

        The reason people don’t want to GPL stuff like this is it’s bothersome to change it and get support from the existing contributors who are actually, you know, contributing to the project. The “get your politics out of my code” thing (for the license) is at this point because some completely random person who has no relevance to the project coming by, screaming about the GPL, and subsequently spawning a massive MIT vs. GPL debate/mudslinging contest is incredibly annoying. I’d frankly be tempted to keep it non-GPL just to spite anyone who does that. It’s a different thing if people who are actually relevant to the project consider doing it.

        EDIT: I noticed this is a different subthread than I was thinking it was, so for context the project was started as a single person’s way to learn Rust using relatively easy to implement programs (with easy to access docs). Also, elsewhere someone mentioned forking. In that vein, I largely think this entire discussion is completely unserious because there has been a over a decade for someone to fork it in one of the drive-by license complaints, or even through complaints like here, yet no one has done anything.

        • doodoo_wizard@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          11 hours ago

          The code in question is a rewrite of a gpl licensed c package in rust under the mit license.

          The “completely random person with no relevance to the project” specifically in reference to uutils-coreutils, but I will stand on the assessment for every other rust/mit rewrite of a c/gpl package, is in every instance a contributor, maintainer or user of the gpl package it’s based on and therefore neither random or irrelevant.

          They are always people saying “hey, we wanna help but your license is standing in the way, why not change it so we can more easily work together?” Or “this project is great but the license is too permissive, since the thing it’s based on got by great with gpl, couldn’t the license be changed to gpl?”

          Forking over license would be counterproductive and silly when the thing in question is a reimplementation of a gpl package. Literally just use the license that the original work had!

          From my perspective the people asking rust/MIT rewrites of gpl/c stuff to go back to gpl are being perfectly reasonable and have every possible definition of standing to make that request and always get treated as interlopers.

          I believe you about the spite thing though. People do be spiteful.

          While you’re right that this isn’t the thread about someone’s private learning project (btw, allowed under gpl), plenty of personal learning projects have changed license when they grew beyond the scope of just some guy messing around.

          Part of refactoring during that growth includes administration and licenses are part of that.

          Projects I have personally written had to have a license applied or changed when their scope changed.

          I think especially once several companies employees are acting in their official capacities in the project it’s very reasonable to bring up the license!

          We havent even touched on the violation of the gpl aspect, where no programmer and certainly not one using a llm could be reasonably thought to be ignorant of the gpl coreutils inner workings and doing a clean room implementation which is what is legally required to not be considered a derivative work!

          Decades ago the gpl assholes had to figure out that you can’t use the license to stop Sony from doing something you won’t use it to stop your neighbor from doing.

          The way around that is to make the rust rewrite gpl.

          • arcterus@piefed.blahaj.zone
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 hours ago

            The “completely random person with no relevance to the project” specifically in reference to uutils-coreutils, but I will stand on the assessment for every other rust/mit rewrite of a c/gpl package, is in every instance a contributor, maintainer or user of the gpl package it’s based on and therefore neither random or irrelevant.

            There are constantly random people complaining who literally have never been involved with GNU coreutils (or frankly any GNU project at all) or uutils. If all the people complaining worked on GNU projects, they’d have a truly astounding supply of contributors.

            They are always people saying “hey, we wanna help but your license is standing in the way, why not change it so we can more easily work together?” Or “this project is great but the license is too permissive, since the thing it’s based on got by great with gpl, couldn’t the license be changed to gpl?”

            People say this in the other direction as well.

            Forking over license would be counterproductive and silly when the thing in question is a reimplementation of a gpl package. Literally just use the license that the original work had!

            From my perspective the people asking rust/MIT rewrites of gpl/c stuff to go back to gpl are being perfectly reasonable and have every possible definition of standing to make that request and always get treated as interlopers.

            I suppose you complain about this when the BSD folks reimplement functionality present in Linux or other GPL projects. To put it bluntly, uutils isn’t GNU coreutils. It’s an implementation of the utilities trying to get as close as possible to the same functionality, but it will likely never truly “replace” GNU coreutils (as long as the latter is still being developed, at least).

            We havent even touched on the violation of the gpl aspect, where no programmer and certainly not one using a llm could be reasonably thought to be ignorant of the gpl coreutils inner workings and doing a clean room implementation which is what is legally required to not be considered a derivative work!

            This is completely ridiculous. How does “no programmer … could be reasonably thought to be ignorant of the gpl coreutils inner workings” even make sense to you? Under this thought process, it’s impossible to make a clean room implementation at all because you cannot be “ignorant of the [XYZ project] inner workings” if you implement the same functionality. I suppose all the BSDs are in violation of the GPL since they have implemented roughly the same functionality. Not to mention Toybox.