Cargo IANAL

[Stebalien]

It would be really nice to have a cargo command that analizes all dependencies and:

1. Verifies that the licenses are compatible.
2. Informs the user about any additional use/distribution restrictions.
3. Helps the user choose an appropriate license (if not already specified).

This doesn't have to cover all licenses, just the common ones (MIT, Apache2, the GPLs, the BSDs, etc...).

[huonw]

Do you know of any preexisting data for 1 and 2 that cargo can reuse?

[Stebalien]

For 1, there's this for GPL compatibility... That's why I said we should start with common ones. Unfortunately, license compatibility is not transitive so a full license compatibility matrix is very verbose.

[ticki]

Big 👍. It would be very nice to have such feature.

[rphmeier]

This, or something like it, is really necessary in my eyes. Since you can easily rack up tons of transitive dependencies with just a couple direct ones, it would be nice to have a tool like this.

I don't know if there's a 'crates.io user agreement' but there should also be some kind of terms you have to agree to before uploading your crate which states that the license you specify in your Cargo.toml overrides any other licenses in your repository, for those rare cases someone might put down MIT and actually uses GPL.

IANAL, not sure how fully legally binding that would be.

[jethrogb]

Automated license-compatibility checking is really complicated if not impossible. For example, there is no automated way to tell the difference between a derived work and a combined work. The main problem here is that you don't want Cargo to have something declared OK which turns out to be not OK.

It would be nice though to have a command that lists all dependencies and their licenses.

[Stebalien]

Automated license-compatibility checking is really complicated if not impossible.

This isn't automated license-compatibility checking. This is automated project compatibility checking using a precomputed license compatibility matrix of common licenses. (see the gnu link above). This is totally doable for a small set of well understood, common licenses.

[jethrogb]

Just came across this somewhat relevant article today: Streamlining license compliance with FOSSology 3.0

[Nemo157]

I've been meaning to do something like this for a while and finally got round to finishing my prototype and pushing it to github: https://github.com/Nemo157/cargo-lichking.

[ticki]

A basic matrix, which should cover the majority of cases:

COMPATIBLE WITH >  PD  MIT  BSD  AL  LGPL  LGPL+  LGPL3  MPL  GPL  GPL+  GPL3  AGPL
Public Domain      ✔   ✔    .    .   .     .      .      .    .    .     .     .
MIT                .   ✔    ✔    .   .     .      .      .    .    .     .     .
BSD-new            .   .    ✔    ✔   ✔     ✔      ✔      ✔    .    .     .     .
Apache 2.0         .   .    .    ✔   .     .      ✔      .    .    .     .     .
LGPLv2.1           .   .    .    .   ✔     .      .      .    ✔    ✔     .     .
LGPLv2.1+          .   .    .    .   ✔     ✔      ✔      .    ✔    .     .     .
LGPLv3(+)          .   .    .    .   .     .      ✔      .    .    .     ✔     .
MPL 1.1            .   .    .    .   .     .      .      ✔    .    .     .     .
GPLv2              .   .    .    .   .     .      .      .    ✔    .     .     .
GPLv2+             .   .    .    .   .     .      .      .    ✔    ✔     ✔     .
GPLv3(+)           .   .    .    .   .     .      .      .    .    .     ✔     ✔
AGPL               .   .    .    .   .     .      .      .    .    .     .     ✔

[tbu-]

@ticki Are these licenses really that incompatible? Can't I have a GPL program that has a Apache or MIT dependency?

[Nemo157]

@tbu- according to Wikipedia, gnu.org and http://www.dwheeler.com/essays/floss-license-slide.html you can. Maybe @ticki's matrix is assuming the compatability is transitive and not showing that explicitly?

[burdges]

@ticki's matrix is completely wrong, maybe even if you check everything under the diagonal.

If you've no problem with any common licenses, then you only need to worry about mutual incompatibilities, probably only Apache vs (L)GPLv2 and MPL 1 vs GPL. Now the GPLv3 has resolved compatibility issues with Apache and [https://www.fsf.org/blogs/licensing/mpl-2.0-release](MPL 2 resolved compatibility issues with the GPL).

At this point, I think the major source of problems for common licenses issue is Apple's AppStore restrictions, which seem incompatible with third parties developers using GPLed libraries. There are rumors the FSF might eventually develop an AppStore amenable license based around reproducible builds, but that's probably years off.

[ticki]

@burdges @Nemo157 @tbu- It is based on the fact that these licenses are transitive with each other. If you extend the set, it might not be transitive, though.

[Stebalien]

@ticki That's why we need something more extensive than a simple matrix.

[Nemo157]

Pretty sure a matrix does work, I basically used one for cargo-lichking: https://github.com/Nemo157/cargo-lichking/blob/master/src/license.rs although that doesn't assume any kind of transitivity of the relationship and just has a fully specified matrix.

[raphaelcohn]

In practice, this kind of thing is more complex, particularly because there's an implicit difference between the licence for the whole, and the licence for the source. The former incorporates the source along with not only artifacts, but the way in which it is structured, delivered, organised or even marketed (!) Oh, and then one has to add in legal domain (country, and, in places like the UK, region; eg how Scots law works here with overlap) and choice of vendoring author / legal entity (company).

So the most useful thing a tool could do is show license usage as SPDX codes (or, ideally, as SPDX codes as per the Debian COPYRIGHT file format, which is more subtle) by crate, by type of dependency. And even then, it wouldn't be 100% right. For example, take clippy. It gets listed as a dependency because it's a compiler plugin, but it's actually never shipped in a binary... so if clippy was AGPL, say, it wouldn't actually virally infest any other code.

I would suggest we look at adopting Debian's COPYRIGHT file format for cargo, though. It's something I've used for a couple of years now, and it makes documenting license details, copyright statements and authorship transparent and explicit. Of course, it would mean writing a parser for Debian-style files, but that wouldn't be a bad thing at all. And they're not hard.

[glandium]

There are other considerations than straight license compatibility. For an example I have been directly involved with, the LGPL was designed against closed-source software, at the expense of copyleft free software. So even though LGPL and MPL are compatible, there are redistristribution constraints that forces Mozilla to distribute binary code from LGPL source code in a separate shared library instead of statically linking it like everything else. These kind of problems are especially hitting Rust code, since the Rust compiler defaults to static linking.

[xizhao]

https://github.com/fossas/fossa-cli accomplishes this, and is OSS -- a PR could be a great home for cargo support

[realHorst]

https://github.com/fossas/fossa-cli accomplishes this, and is OSS -- a PR could be a great home for cargo support

I do not think fossa qualifies as an open source tool. Only their client is open, the analysis is done on their servers.

[phoepsilonix]

For example, if a Linux distributor is creating a package, they may wish to have the ability to check the licence list of the relevant crate as a standard feature of cargo.
It is hoped that functions such as cargo-lichking and cargo-license will become standard features.

cargo lichking bundle

The above features would be eagerly awaited by distributors.