I ask this because I think of the recent switch of Ubuntu to the Rust recode of the GNU core utils, which use an MIT license. There are many Rust recodes of GPL software that re-license it as a pushover MIT or Apache licenses. I worry these relicensing efforts this will significantly harm the FOSS ecosystem. Is this reason to start worrying or is it not that bad?

IMO, if the FOSS world makes something public, with extensive liberties, then the only thing that should be asked in return is that people preserve these liberties, like the GPL successfully enforces. These pushover licenses preserve nothing.

OQB @[email protected]

  • Mark with a Z@suppo.fi
    34·
    20 hours ago

    “Pushover license” is a pretty descriptive way to call it. I’ve seen quite a few dumb takes on coreutils that focus on the “Rust rewrite” part and not “MIT-licensed rewrite”. Pushover licenses have a place, but to me the goal here is pretty transparent and I don’t like it.

    • HappyFrog@lemmy.blahaj.zone
      6·
      14 hours ago

      I like permissive licenses for libraries, that way you leave room for corporate collaborators, however, all my binaries and end user apps are copy left.

      • Womble@piefed.worldEnglish
        2·
        2 hours ago

        Even then, LGPL exists, I wish more libraries would use it rather than going for MIT/BSD licences.

        • HappyFrog@lemmy.blahaj.zone
          11·
          44 minutes ago

          Rust libraries are linked statically and aren’t replaced easily after compilation, this makes lgpl libraries very hard to use in proprietary code. I don’t think what the best action is in this case… I should probably start using lgpl.

          • Womble@piefed.worldEnglish
            1·
            22 minutes ago

            I’m not an expert on licences by any means, but my understanding was that LGPL explicitly allows you to link it to other binaries with neededing to licence them with the same licence. Does rust really only support static linking and not dynamic?

            Per the Gnu wiki:

            Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)

            For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

               (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.  

               (2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

            So as long as you also provide your application with an LGPL library shaped hole you can release a static-linked binary with LGPL components.