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.
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.
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.
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?
Well, the thing is, if you’re developing a library, you usually do so, because you want it to be useful to people in the ecosystem.
By putting it under the GPL, you limit that usefulness to only those projects which are willing to also put themselves under the GPL. From an idealist point of view, I certainly also would like to say that people not willing to put their software under GPL don’t need to be my users. But from a library author point of view, I might as well not write a library then, since no one’s going to use it then.Many open-source projects are under a permissive license themselves. I might disagree with their choice, but I don’t really want to exclude those from using my library. They’re still doing good things. I would love to exclude specifically any proprietary software from using my library, but that’s not really something you can require in your license without excluding all those permissive open-source projects.
So, to answer your question, I actually don’t think people are being tricked into it. I thought about choosing GPL for my libraries for a while (all my applications are under GPL) and decided against it. Which is a personal choice that others can disagree with, but all I’m saying is, I know what I’m doing, I wasn’t tricked to use a permissive license.
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.
MIT does not force you to not make your project free.
Given the double negative and the ambiguity of “free,” I don’t know what you’re trying to say here.
You are allowed to license your code change under gpl, you do not have to use MIT just because the package author uses MIT. You can use GPL.
You can also use MIT or no license at all. it does not force you to use MIT
Why is it an MIT project in the first place?
I am no dev of rust.
My guess:
- they didn’t want to scare anyone.
- They really think that MIT is free and that anyone shall do with it whatever they like. They are not afraid that someone takes the rust code base and produces a proprietary fork and make money from it.
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.
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.
I do not program. So maybe trying to understand all this is over my head. wikipedia describes
A static library or statically linked library contains functions and data that can be included in a consuming computer program at build-time such that the library does not need to be accessible in a separate file at run-time.
I thought that was the idea of binaries in general. In the Arch repos there are many packages appended with
-bin. (The Arch repos also contain items of various licenses including proprietary.) Lots of FLOSS packages make a binary available by direct download from their website. Without too much detail, is there something special about Rust? Or maybe I misunderstand the concept of a binary release.library code licensed under it must be able to be replaced.
Does this mean you need to be able to make a reproducible build? Or need to be able to swap code for something else? Wouldn’t that inherently break a program?
So the basic purpose of a library is to allow code that does some useful thing to be easily used in multiple programs. Like say math functions beyond what is in the language it self or creating network connections.
When you build a program with multiple source files there are many steps. First each file compiled into an object file. This is machine code but wherever you have calls into other files it just inserted a note that basicly says connect this call to this part of another file. So for example connect this call to SquareRoot function in Math library.
After that has been done to every file needed then the linker steps in. It grabs all the object files combines them into one big file and then looks for all the notes that say connect this call to that function and replaces them with actual calls to the address where it put that function.
That is static linking. All the code ends up in a big executable. Simple but it has two big problems. The first is size. Doing it this way means every program that takes the squareroot of something has a copy of the entire math library. This adds up. Second is if there is an error in the math library every program needs to be rebuilt for the fix to apply.
Enter dynamic linking. With that the linker replaces the note to connect to the SquareRoot function in math library with code that requests the connection be made by the operating system.
Then when the program is run the OS gets a list of the libraries needed by the program, finds them, copies them into the memory reserved for that program, and connects them. These are .so files on Linux and .dll on Windows.
Now the os only needs one copy of math.so and if there is a error in the library a update of math.so can fix all the programs that use it.
For GPL vs LGPL this is an important distinction. The main difference between them is how they treat libraries. (There are other differences and this is not legal advice)
So if math.so is GPL and your code uses it as a static link or a dynamic link you have to providd a copy of the source code for your entire program with any executable and licence it to them under the GPL.
With LGPL it’s different. If math.so is staticly linked it acts similar to the GPL. If it’s dynamicly linked you only have to provide the source to build math.so and licences it under LGPL. So you don’t have to give away all your source code but you do have to provide any changes to the math library you made. So if you added a cubeRoot function to the math library you would need to provide that.
To add a couple of issues with Dynamic Libraries, and why someone would choose Static Libraries:
- The dynamic library being updated can break a program due to a change in the library. Think a math call goes from divide(a,b) to divide(a,b, precision), so now the old call doesn’t exist.
- Some languages don’t have a “stable” way to talk to itself. This means that if you have a program and library compiled with compiler version A, then later compile an update to the library with compiler version B, the program won’t know how to talk to the library correctly, even though the call is still there.
Like a lot of things, there are tradeoffs, and there is no universal correct choice.
Agreed. I wasn’t trying to say they are always better just explain the difference.
I almost exclusivity use Linux and it handles this great. .so libraries are stored with a version number and a link to the latest. So math3.so and math4.so with math.so being a link to math4.so. that way if needed I can set a program to use math3.so and keep everything else on the latest version.
There are two ways of using library code in an executable program: dynamically linked libraries – also shared libraries – (these are DLL files on Windows, so files on Linux, dylib files on Mac), and statically linking libraries, which are embedded into the program executable at build time (specifically the link step which is generally the last).
Dynamically linked libraries just store a reference to the library file name, and when the program is run, the dynamic linker searches for these library files on disk and loads them into the program memory, whereas as I already said above statically linked libraries already are part of the program executable code so nothing special has to be done there at runtime.
This has nothing to do with bin packages inherently, which usually use at least a couple dynamically linked libraries anyway (libc at least). In fact every Rust program dynamically links to libc by default as at least glibc is impossible afaik to statically link. Some of them ship dynamic libraries along with the program binary (you see this a lot with Qt since it is pretty hard to link statically), some of them link their dependencies statically, some just expect the system to have certain versions of shared libraries available.
The special thing about Rust is that it really does not want you to output dynamically linked Rust libraries and link them to Rust programs, at least if they’re not inside the same project, since it does not have a stable interface for Rust code to Rust code calls (and a couple other reasons). This means you cannot ship a Rust shared library as a system package that programs in other packages can link against, like you can with for example C or Swift languages. Every dependency has to be built inside the same project the final executable is also in.
library code licensed under it must be able to be replaced.
Does this mean you need to be able to make a reproducible build? Or need to be able to swap code for something else? Wouldn’t that inherently break a program?
It does not mean you need to make a reproducable build, it just means users must be able to modify the LGPL licensed parts. For example, the library loads a file from a specific path that you want to change, you must be able to change that path by editing the library source code. This is trivial if it’s a shared library since you can just build your own where the path is changed and tell the dynamic linker to load that instead of the original, but with a closed-source statically linked binary you cannot easily change it if it does not provide the object files. These are essentially mostly final compiled code produced from source code files but not yet linked together into an executable, and significantly the LGPL parts are isolated files which can be swapped out with your own and then linked together again.
Doing this does not inherently break a program as long as the interface of the library (like function names, parameter types, general behavior of the code) stays compatible with the original one shipped with the program.
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 licenses?
The word “libre” in the context of licensing exists to clarify the ambiguity of the word “free”, to emphasize that it means “free as in freedom” rather than “free as in beer” (aka no cost, or gratis) as the FSF explains here.
The MIT license is a “libre” license, because it does meet the Free Software Definition.
I think the word you are looking for here is copyleft: the MIT license is a permissive license, meaning it is not a copyleft license.
I don’t know enough about the Rust community to say why, but from a distance my impression is that yes they do appear to have a cultural preference for permissive licenses.
The MIT license is a “libre” license, because it does meet the Free Software Definition.
Nope. It allows someone to use code without sharing the changes of that code. It enables non-free software creators like Microsoft to take the code, use it however they like, and not have to share back. This is what Free Software prevents.
Tired of people calling things like MIT and *BSD true libre/Free Software. They’re basically one step away from no license at all.
Nope.
Nope, it is.
It allows someone to use code without sharing the changes of that code. It enables non-free software creators like Microsoft to take the code, use it however they like, and not have to share back.
This is correct; it is a permissive license.
This is what Free Software prevents.
No, that is what copyleft (aims to) prevent.
Tired of people calling things like MIT and *BSD true libre/Free Software.
The no True Scotsman fallacy requires a lack of authority about what what constitutes “true” - but in the case of Free/Libre software, we have one: https://en.wikipedia.org/wiki/The_Free_Software_Definition
If you look at this license list (maintained by the Free Software Foundation’s Licensing and Compliance Lab) you’ll see that they classify many non-copyleft licenses as “permissive free software licenses”.
They’re basically one step away from no license at all.
Under the Berne Convention of 1886, everything is copyrighted by default, so “no license at all” means that nobody has permission to redistribute it :)
The differences between permissive free software licenses and CC0 or a simple declaration that something is “dedicated to the public domain” are subtle and it’s easy to see them as irrelevant, but the choice of license does have consequences.
The FSF recommends that people who want to use a permissive license choose Apache 2.0 “for substantial programs” because of its clause which “prevents patent treachery”, while noting that that clause makes it incompatible with GPLv2. For “simple programs” when the author wants a permissive license, FSF recommends the Expat license (aka the MIT license).
It is noteworthy that the latter is compatible with GPLv2; MIT-licensed programs can be included in a GPLv2-only work (like the Linux kernel) while Apache 2.0-licensed programs cannot. (GPLv3 is more accommodating and allows patent-related additional restrictions to be applied, so it is compatible with Apache 2.0.)
Yes you are correct I mis-used the term. I mean copyleft. So I fixed the post. :)
@cypherpunks @some I agree, and I think it’s partly a consequence (rightly or wrongly) of static linking being the default.
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.
I don’t think it’s Rust exactly. I think Rust is just newer and this attracts developers with less experience with licensing. It’s not really something developers want to think about very much so they often just use the default. Heck, most code on github, etc., didn’t have any licenses at all for a really long time until businesses realized they couldn’t use the code without them due to copyright laws being applied by default but patents not being default in many countries, etc.
There are consequences to using copyleft as opposed to more permissive libre licenses, and vice versa, that may not be well understood by a lot of developers in general until they get into a situation where it matters. Either their code can’t be used by people they wanted to sue it, or companies are abusing the code without proper attribution, etc.
It’s not really something developers want to think about very much so they often just use the default.
Do you think it was intentional ideological decision by the Rust developers or some other contributors/interests to make permissive the default? Or a random decision that has ended up being consequential because of the popularity of Rust?
I have noticed for a long time that github promotes MIT license. It lets you use any, of course, but puts a real positive shine on MIT. My perception is that this is a purposeful intervention by MS into FLOSS to promote MIT.
I think its just that the language having built in licensing is a newer concept as opposed to just having a companion document. And MIT and Apache are the licenses the pieces of the language is licensed under, so they made those default. That way it’s a conscious decision to make it more restrictive.
built in licensing
how’s it built in?
Rust crates manifest file requires a license be set to be hosted on crates.io and the example manifest file uses:
[package] license = "MIT OR Apache-2.0"Something like the Java’s jar manifest doesn’t have a predefined license property for interpreters to parse. Maven has a property, but it’s not required.
MS and other corps love MIT and related licenses because they can just take the code and basically do whatever with it in their projects, so it makes sense for them to promote it. Generally speaking, they won’t touch GPL/AGPL as it would force them to distribute their source.
I believe it was a very intentional choice to use a permissive license for Rust. If they hadn’t, it would not have been as popular as it is today, nor would it have big money behind it. https://rustfoundation.org/members
