85
Is the FOSS world in danger of a corporate takeover, thanks to pushover licenses? (libretechni.ca)
submitted 1 year ago by to c/linux@programming.dev
18 comments fedilink hide all child comments
 

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 @ZkhqrD5o@lemmy.world

you are viewing a single comment's thread
view the rest of the comments
[–] 38 points 1 year ago (5 children)

"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.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] 10 points 1 year ago (4 children)

    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.

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

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

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

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 1 year ago* (last edited 11 months ago) (1 child)

    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 without needing 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 year ago

    That was what I was trying to communicate with my comment. It's very difficult to provide the compile objects in rust, and dynamic linking deprives you of many of the benefits of using rust.

    It introduces friction if you don't want to open source your code. This friction will drive away many users. I want people to use my code, even in commercial products, so providing libraries in Apache or MIT just makes more sense for that goal. If you have another goal lgpl might be more inline.

  • permalink
  • fedilink
  • source
  • parent