Copyrighted code publishing on crates.io

Would it be legit to publish on crates.io a crate built from the sources that are not distributed under any OSS-compatible license?

I'm thinking about publishing of my personal Rust project that is not going to be(at least not in the nearest time) distributed as an open-source free software. In other words I would like to keep an opportunity to selectively grant exclusive permissions to use and derive this work in the 3rd party software rather than granting such permissions to everyone through some OSS license . However I don't mind about making the sources to be publicly visible and downloadable by everyone for read-only purposes. As such I also don't mind to publish it on crates.io too.

The question is wouldn't such attempt violate the terms of the crates.io repository use? Cargo requires to link a license-file in the project manifest, but I suppose I can simply put a copyright notice in the file.

1 Like

The way I see it is that crates.io is specifically intended as a means of providing code that people can build programs with. Building programs is what cargo and crates are all about.

As such it seems inappropriate to push code that is intended for people to read only into a system designed to build and run software.

If you publish it anywhere it would be better to include a license file that specifically states the allowed use of the work i.e. for human readers only not to be executed by machine in this case.

Well, the user could use this published crate to build and run software too, but only if the user obtained appropriate exclusive license which is not granted by default to everyone who can potentially download this crate.

I didn't find explicit prohibition of such use case in crates repository terms of use, but would like to double check with the community, and to hear some feedbacks on this idea. And maybe even see if there are example of the projects with similar distribution policies?

Exactly. Conditions like that are what license files are for. The terms should be spelled out in there.

Personally I would be very annoyed to find I had accidentally come to dependent on some such a non-Free and/or non-Open-Source (note the capitalization) in my project. Either through my own mistake or via some other crate that depended on it.

Of course ultimately it is my responsibility to check the license terms of everything I use. Which again is why your terms should be spelled out in your license file.

2 Likes

Good point.

I'm thinking that maybe as an additional "guard" it would be also reasonable to put a non-default marker feature(something like license-granted) into the crate, that the crate user must explicitly set. Otherwise it will show the copyright notice during compilation and fails. Just as an idea to prevent such accidents.

Does crates.io even allow crates with no license?

(link is almost six years old, but still)

Cargo allows to have a license-file entry only that could internally have any text. For example, a custom license or just copyright notice with some explanation on how to obtain actual license. So at least from the technical point of view this is a workaround I think.

1 Like

Gentoo has ACCEPT_LICENSES, which defaults to free/open licenses only, and will not install anything with a license not in that list. (One can always add additional licenses to be able to install more things, but they're not allowed by default.)

Would be a nice thing to have for cargo as well.

4 Likes

You can use cargo-deny. It checks licenses as well as checks for crates with known vulnerabilities (the same as cargo-audit).

1 Like

If you are publishing the code to crates.io you are effectively giving everyone permission to use it. Anyone can grab a copy of the source code if they want, so you'd have no practical way of limiting use in the future.

I agree although it's not giving permission, it's giving access.

In these cases I'd prefer to keep sources in git. It's trivial to add git dependecies or build tools from a git repo. No need to involve crates.io.

1 Like

You're not necessarily giving everyone permission. Most licenses limit permission, in fact. You also have legal recourse, a tool some consider practical.

Edit: In fact, given the title of this thread, perhaps I should emphasize: OSS licenses are (also) a copyright based mechanism.

2 Likes

Of course, although I question the practicality of this. It'll only really work if you know one or two big companies have been using (or derived from) your code.

Yeah, and as a bonus hosting providers like GitHub and GitLab will provide practical mechanisms for limiting access, like giving people read-only permission to your private repo so they can use it.

If your code isn't compatible with an open source project and you found them using your code, I suspect sending them a notice would usually work. I agree that if a non-open source project uses your code against the license, it is a lot harder to find and prove (whether or not your license is open source).

I don't see anything in the policies that requires OSS licenses.

crates-io/Cargo requires you to disclose source code, and it would be very cumbersome not to. If you're fine with that, technically you could publish.

If you want to have an option to sell the code commercially, consider dual-licensing code under (A)GPL + commercial license. This way the published crate would still be useful for FLOSS projects.

Other options:

  • You could set up an alternative Cargo registry and publish there.
  • You could ask your users/customers to use a Git dependency. With a bit of tinkering it can even be a private repo.
2 Likes

from: licence "The name must be a known license from the SPDX license list 3.6."

Crates closed to anyone's free use and to modification "CC-BY-NC-ND-4.0.html" is explicitly allowed.

I think most prefer you just squat the name; if financial payment is required to use.

Interesting.

So if I include your not open/not free crate into a project of mine, for my own use, with or without bad intent. Then you are never going to know. Maybe not even me if it was accidentally included due to some other dependency.

Further, if I publish a program of mine, as source, as a crate or on github or whatever, which happens to depend on your not-free/not-open crate, then that is not a worry. Anyone can download my source and have cargo pull in your crate. After all, I'm not distributing your code, crates.io is.

Further, if I or any user of my program is using your code as part of some cloud service, then you are never going to know.

All in all, I'm not sure what you are trying to protect and against what with some funky license in code you are publishing via crates.io

Seems a better idea to not publish it as a crate. Perhaps just as a github repo or some such.

Crates.io just seems to be the wrong place for this.

2 Likes

Just to make sure I get this right, this point is only about pragmatics; a commercial cloud service would still, legally, not be allowed to use your program because of the non-free dependency, right?

1 Like

Yes indeed.

My take on it is that crates.io is intended as a place to put code that people can use. The Rust ecosystem.

Therefore, I reason, putting code there with a license that says they cannot use it runs counter to the whole reason for being of crates.io.

Or is crates.io to be a place for commercial code vendors to advertise their products?

Just seems to run against the grain to me.

I’m wondering how things like docs.rs or crater work with crates licensed under e.g. CC-BY-NC-ND-4.0. Docs.rs is building the documentation of the public API and publishing the result. Wouldn’t this count as publishing derivative work? And while crater runs for rustc might be non-commercial (although I’m not 100% sure about this), if some company uses crater to evaluate their custom fork of rustc, would they be violating the license by having crater run the test-suite of a CC-BY-NC-ND-4.0 crate for commercial purposes (even if it’s just about evaluating the compiler, not actually really using the crate)?

1 Like