Does the standard library have linking exceptions to their licensing?

Right now in Rust, if I program a basic hello-world.exe progam, and then I email just that one file to a friend, suddenly I'm a copyright violator (I think).

As far as I can tell, all of Rust's standard library (core, alloc, std, libm, libc, compiler_builtins, etc) is all under "MIT OR Apache-2.0" as much as possible, which means that if you make a simple stand alone program (even without using any crates.io crates), you still need to ship like 3 or more copies of whichever license with your program.

Is there some sort of exception clause to all this madness so that you can send around a simple program?

2 Likes

The simple answer to the titular question is no, and trying to get permission of everyone who's contributed to agree to one would be next to impossible.

More in depth, I don't think a linking exception would even apply to most builds, as IIUC linking exceptions are for dynamic linking where the linking target is already on the target machine; static linking (like rustc does by default) or shipping the dylib both require providing the license.

My IANAL opinion is that copyright is based on enforcement, and since Rust doesn't even have a formal organization, it isn't actually capable of enforcing copyright. It is still good manners to include credit in nontrivial works, but for trivial works, the informal "don't abuse it and we'll not attack you" will have to do.

Also, this feels more like a users question to me.

4 Likes

The general question seems reasonable, though I really don't think a request for credit and licensing information qualifies as "madness".

No, there's no exception clause, and if you distribute a binary that statically links in the Rust libraries, you would need to provide a copy of the license along with it. You won't typically need to ship multiple copies of the license, though; one will typically suffice.

I could imagine ways we could simplify that, such as by offering the option to embed the license.

Also note that similar requirements would apply to the inclusion of any other crate; this isn't specific to the standard libraries.

Also worth noting: if you statically link the platform C library or similar, you'll need to address its license as well. This isn't Rust-specific.

For Rust, at least, you could use tools like cargo-lichking to help you generate appropriate documentation.

1 Like

One crate asking for credit is of course entirely reasonable.

But the winit "hello world" example (named window), which just opens a window and draws nothing, has 95 crates in the complete build graph.

Right, but you can easily avoid crates.io, you cannot easily avoid libcore, libm, and compiler_builtins.

That's where automated tools become critical, yes. I would expect a binary built atop those dependencies to just provide a single programmatically generated file containing the licenses of all its dependencies.

(Also, this only comes up if you're distributing in binary form rather than in source form. If you're distributing in source form, and not bundling/vendoring all your dependencies, you don't need to reproduce any of your dependencies' licenses.)

These same requirements would apply for any dependencies; you'd only "avoid" them if you're building code with no dependencies. (That sometimes happens with no_std code, but otherwise seems relatively uncommon.)

Those don't seem excessively onerous to comply with, if those are the only ones you're dealing with. However, it would certainly help if tools took the standard libraries into account. I've opened an issue on cargo-lichking to support that.

Right, I really did mean "don't use any external dependencies at all, do it all yourself".

To be honest, I prefer this situation over the one where I have to figure out if my compiler run was an "Eligible Compilation Process".

https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

If someone uses 3rd party crates, then restrictions and attribution are expected. But it's less obvious for libstd and compiler built-ins, and I can imagine people being weirded out about this.

Maybe it's worth trying?

  • Git(Hub) keeps track of the e-mail addresses and linked GitHub accounts. Rust is not very old, so lots of people may still be reachable.
  • Existing licenses are already permissive, so addition of something like CC0 or a (static) linking exception clause isn't too much to ask.
  • If individual contributors didn't add themselves to "Copyright …" lines in the license document, they likely don't care about attribution anyway.
  • If it's ever going to happen, it's better to start now than later.
4 Likes

If you mean to say that we shouldn't try and improve the situation just because some other situation elsewhere is worse then that's not a convincing line of argument.

Unfortunately some countries don't support Public Domain, and CC0's fallback license for when PD isn't recognized is not an OSI approved license.

(not a lawyer) For the specific purpose of having a license option so that people can build their Rust programs without having to include license data about the standard library itself in every single Rust binary, it seems like Zlib is the best option of the OSI approved licenses.

... If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

That's basically what you want, I think.

After reading this thread and giving the issue some thought, the conclusion that I need to provide attribution and honor certain licensing restrictions becomes obvious. But to be honest, I'm not really sure what code from the Rust project is actually used when I compile my println!("hello world") code. Am I using libstd? librt? libcore? Some other library I've never heard of? Do all these libraries share the same license and copyright?

I would be grateful if there was an official, or semi-official, recommendation on what type of language I should build into my binaries.

3 Likes

No, that's not what I am saying. The current model is consistent and easy to grok and can be applied to any artifact, independent of build ordering/nature.

The MIT license is often interpreted as not requiring any attribution in compiled binaries, although it's not clear whether this is the correct interpretation (and of course matters of law don't really necessarily have a "correct interpretation", it's more a probability distribution over what a judge/jury would decide).

Maybe cargo should start providing a way to automatically generate copyright/attribution text for all the crates, and also tell you under what terms you can redistribute your binaries.

1 Like

Note that this is almost certainly not a correct interpretation in copyright laws like France's where (code) authors cannot renounce their attribution rights.

I’m only a small time contributor so all my patches could be reimplemented, but I personally would not agree to licensing my patches with an exception. I’m happy with the MIT+Apache as-is and I’m not interested in trying to change that.

Since attribution seems to be required, it would certainly be useful to have a Cargo plugin which assembles the names of all copyright holders mentioned in all dependencies and writes these to a file that can be included with the released binary.

2 Likes

There is cargo-license, cargo-lichking, and cargo-deny, none of which actually give info about the standard library itself. They only give info on the various listed dependencies in Cargo.toml