I often see Rust mentioned at the same time as MIT-type licenses.
Is it just a cultural thing that people who write Rust dislike Libre copyleft licenses? Or is it baked in to the language somehow?
Edit: It has been pointed out that I meant to say “copyleft”, not “libre”, so edited the title and body likewise.
It’s a cultural thing mainly. Things like rust and npm came out of the “Github generation” of open source developers which trend towards permissive licensing, in part thanks to Github’s own anti-copyleft bias. Github’s founder openly advocated to “open source almost everything” (the “almost” part being “core business value”), arguing that open source serves as a foundation upon which to build proprietary products. In this world, participating in open source is merely a way to gain PR and volunteer labor for the proprietary product.
I’m not automatically opposed to permissive licensing (nor is FSF/GNU, in fact!) but in making it the norm we put proprietary software companies in control of what ultimately becomes available in the commons.
There’s nothing stopping you from using GPL.
But there is a culture - I think even explicit - of using MIT or APACHE licensing. In some sense is okay, because it simplifies crate compatibility. But it comes at the cost of feeding the usual suspects who now obviously turn against humanity.
My unconfirmed suspicion is that there are forces behind (Google, Microsoft, Amazon, Meta) who like permissive licenses because this makes it easier for them to exploit the work of the public.
I’m a (mediocre) Rust dev, and I use GPL licenses for my projects. There’s nothing preventing you from doing so. I think the answer to your question is that it’s largely cultural.
This is somewhat concerning, as im a big fan of working for free, as long as it benefits the users. I have also been looking at the EUPL as a happy middleground (it permits static linking, while any changes to the acual code is copyleft). Copyleft is important, and needs to be talked about.
FWIW static linking is also fine with LGPL (see my comment).
Yes, but this comes with restrictions on distribution of your binary/code/artifacts.
I see the value in these restrictions, but i also see why these libraries are avoided in commercial settings. These terms often come as a suprise from my understanding.
The EUPL solves this by only making claims of the actual modifications to the EUPL licensed components, not any third party user code.
This license (EUPL) was designed with cooperarion as the primary motive, and this is very valuable in my opinion.
I believe the reason we see so much permissive code is because of said suprises with the GPL’s, it defeats the utility of the license itself. I say this as an avid GPL lover, but i have also seen projects like libopencm3, which desperately needs EUPL.
On the other hand we have projects like Linux and VESC, where we absolutely positively need to kill user-exploatation dead in its tracks, mostly since it is an end-user product. The GPL serves its purpose perfectly here.
Also, you might note that the MPL is a valid choice here, but it does not offer the same protection in the case of third party extension of the licensed code, since it is file-based, in essence.
Ive actually spent a good amount of time looking into licenses, would love to hear more of your thoughts.
Here is a discussion and Here is the original author (i think) of the EUPL.
It’s kind of the default in the docs
SPDX license expressions support AND and OR operators to combine multiple licenses.1
[package] # ... license = "MIT OR Apache-2.0"Using OR indicates the user may choose either license. Using AND indicates the user must comply with both licenses simultaneously. The WITH operator indicates a license with a special exception. Some examples:
MIT OR Apache-2.0 LGPL-2.1-only AND MIT AND BSD-2-Clause GPL-2.0-or-later WITH Bison-exception-2.2When I started out (I don’t write Rust but other languages), in my first years, I liked gpl and after a couple of years I got to know MIT and I started using that because I thought it is “more free”. I wasn’t aware of the consequences immediately. Once I read the GNU philosophy and started reading more about free software, I started using gplv3 again
soo you are saying people are tricked into it?
You could say that, yes.
It makes sense to suggest MIT license for a MIT project
MIT is better than proprietary. MIT does not force you to not make your project free.
Why is it an MIT project in the first place?
Specifically for libraries licensed as LGPL, a lot of the time with Rust I hear the justification that it forces anything using it to also be (L)GPL, because Rust always links libraries statically1 into the final binary and therefore does not meet the requirement of the LGPL that library code licensed under it must be able to be replaced.
This is absolutely not the case however, precompiled binaries can just ship all the object files it is linked from along with it so users can replace the object files of the LGPL library with their own custom version, or just the source code for open-source software, which also meets the requirement of course.
1 something I could rant about for hours as this is lowkey one of the two things that ruins Rust for me but I digress
This is absolutely not the case however, precompiled binaries can just ship all the object files it is linked from
This is completely incorrect for languages like Rust (or, say, C++). You are spouting misinformation.
Generics mean that not all the code “in a library” can be compiled to a single object file, as it’s impossible to know ahead of time what instantiations will exist. This means these instantiations may instead be emitted to another object file, and therefore include a copy of the code.
It is therefore impossible to “just publish the object files and swap out some of them link again”. Meaning it is impossible to comply with the LGPL if a Rust library is LGPL.
Oh and also, Rust isn’t ABI safe. So even if you make a library “without generics” to get around this, it’s still impossible to ensure it keeps working with future Rust compiler changes.
Yes, that is true. And yet, there are C++ LGPL libraries which as you say do in principle have the same problem. It should be safe if you’re careful about not using generics in the library’s public interface, or at least only generic code that is essentially just stubs calling the real logic. (I haven’t actually tried this myself tbh.)
In general any kind of inlined code is always a problem when doing this, even C can have this with macros, or “static final” integer constants in Java.
I should have definitely mentioned this and Rust’s ABI stability though, yeah. As for that, keeping the same compiler version is generally not a problem since all of them are available.
IIRC Same compiler version doesn’t mean the ABI will be the same. Each compilation may produce different representation of data structures in the binary. Depending on the optimization and other things.
Ugh, that would complicate things. If that’s the case, all I can say is that’s really negligent (and goes into what I originally said about lack of stable ABI really ruining Rust for me — technically I said static linking but that’s really the core issue)
Yeah, and there’s no plan to stabilize the ABI because it’s developing.
You can use C ABI for some data formats, but you’re limited on what you can use (mostly primitives). There’s a crate stable-abi or abi-stable that provides a way to do things to keep it stable, but since it’s external crate it has limitations.
I know it’s frustrating because I am writing something in rust that loads functions in runtime. I thought it’d be easy because programs written in C do it all the time. Rust gives a lot of advantages but working on dynamic loading hasn’t been fun. And there aren’t a lot of resources about this either.
