Linux

10165 readers

833 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

Is the FOSS world in danger of a corporate takeover, thanks to pushover licenses? (libretechni.ca)

submitted 2 days ago by cm0002@libretechni.ca to c/linux@programming.dev

16 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

[–] markz@suppo.fi 36 points 2 days ago (1 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.

[–] HappyFrog@lemmy.blahaj.zone 10 points 2 days ago (1 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.

[–] Womble@piefed.world 4 points 2 days ago (1 children)

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

[–] HappyFrog@lemmy.blahaj.zone 0 points 2 days ago (1 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.

[–] Womble@piefed.world 4 points 2 days ago* (last edited 2 days ago) (1 children)

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

[–] HappyFrog@lemmy.blahaj.zone 3 points 1 day 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.