onur / cargo-license Goto Github PK

I tried running cargo license in the sample folder of the servo/webrender repository to try and see the license of all the dependencies. However I got a crash instead:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error(Io, (Some(Error { repr: Os { code: 2, message: "No such file or directory" } }), stack backtrace:
   0:     0x55a22e62f06d - backtrace::backtrace::trace::h16372ee7bf1517e5
   1:     0x55a22e62f6f2 - backtrace::capture::Backtrace::new::hcc43c50c4b11c693
   2:     0x55a22e57533f - <cargo_license::Error as core::convert::From<std::io::error::Error>>::from::hdf8702df7c2b799c
   3:     0x55a22e5742a9 - cargo_license::get_dependencies_from_cargo_lock::h8e93364dce42dbf0
   4:     0x55a22e56e40d - cargo_license::main::he7497a14b2ac292f
   5:     0x55a22e6e9cca - panic_unwind::__rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libpanic_unwind/lib.rs:97
   6:     0x55a22e6e152a - std::panicking::try<(),fn()>
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panicking.rs:332
                         - std::panic::catch_unwind<fn(),()>
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/panic.rs:351
                         - std::rt::lang_start
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libstd/rt.rs:57
   7:     0x7fc7cfb7b82f - __libc_start_main
   8:     0x55a22e56dbd8 - _start
   9:                0x0 - <unknown>))', ../src/libcore/result.rs:837
note: Run with `RUST_BACKTRACE=1` for a backtrace.

The new v0.5.0 release broke a feature that was working in v0.4.2.

We have a "virtual manifest" workspace (I'm not sure how to call it, our Cargo.toml is simply linking to other crates). In v0.4.2, we could ask for

cargo-license -d -t

and it was working. Now it only prints

No root package

hi @onur @dalance

This crate does not appear to be in a state of active maintenance, nor are there any plans for a new release.

We have chosen to fork this crate in order to get a stable build. But for now, I'd like us to go 'upstream first', preferably using a crate that is published to crates.io. see datafuselabs/databend#6969

I am not sure if you would like to release a new release, or if a new maintainer is needed, we would be happy to help.

▶ cargo license
error: Found argument 'license' which wasn't expected, or isn't valid in this context

USAGE:
    cargo-license [FLAGS] [OPTIONS]

For more information try --help

Many other cargo install xxx commands work as expected.
Bash/Pop!_OS(Ubuntu) 19.10,
cargo 1.42.0 (86334295e 2020-01-31)

Any ideas?

Hi,
Before I go about doing it myself, is there a github action which wraps this?
Thanks!

The cargo version used depends on libgit2-sys v0.4.6, which no longer builds on Debian Testing. Since newer versions build just fine, the easiest fix would be to update to newer cargo.

The errors are:

libgit2-sys-0.4.6/libgit2/src/openssl_stream.c:146:3: error: dereferencing pointer to incomplete type ‘BIO {aka struct bio_st}’
libgit2-sys-0.4.6/libgit2/src/openssl_stream.c:204:1: error: variable ‘git_stream_bio_method’ has initializer but incomplete type

Both compiled from source (newest master) and installed via cargo cargo install cargo-license, the binary results in "N\A" licenses for every dependency (even when the actual crates have valid licenses on crates.io).

crossbeam-channel has the license MIT/Apache-2.0 AND BSD-2-Clause, which they intend to mean ((MIT OR APACHE) AND BSD), but cargo-license outputs Apache-2.0 AND BSD-2-Clause OR MIT.

The issue is that it just assumes normal operator precedence, but a reasonable person would not interpret A/B AND C as A/(B AND C).

Not a trivial problem to solve (are you going to add support for brackets? I don't think so). I would suggest you only normalise if //OR and AND are not mixed (see what I did there?).

D:\dev\beryllium>cargo license
error: Found argument 'license' which wasn't expected, or isn't valid in this context

USAGE:
    cargo-license.exe [FLAGS] [OPTIONS]

For more information try --help

It looks like the command line arguments are off by 1 or something?

cargo_metadata is part of the public API of the crate through the MetaataCommand argument and therefore this is a breaking change, the release should have been 0.6.0.

It would likely make sense to yank 0.5.2 and re-release as 0.6.0.

Thanks for the project. We find it really useful for managing our program's license file.

I have a CI check to keep the license file up to date and we end up installing this on CI but it seems we have install from source as there aren't binaries with the releases as there are with some Rust tools. Installing from source takes longer than ideal.

Would you be ok with adding binaries to releases? I'm not expert in the area but I could try to look into getting it working. I have a Rust project called matcha to which someone kindly added the github action/workflow set up for binaries in the releases: https://github.com/michaeljones/matcha/releases. I could try to work from that?

It would be great if cargo-license could separate between normal, build and development dependencies, because in most cases the latter two do not affect licensing of the resulting library. Current cargo_metadata should have the necessary information: https://docs.rs/cargo_metadata/0.8.0/cargo_metadata/enum.DependencyKind.html

I'd like to generate license information for my project, but only want to include licenses of dependencies which are actually used. For example, when I am building on macOS I don't want to include target-specific dependencies for other platforms such as Windows.

Just wanted to leave some love for this project -- it's made me much more comfortable when trying to make decisions on how to license projects after I've built prototypes for them, and already have a set of dependencies I think I'll want to keep. I feel like I can give back better to Rust because of how you're giving back!

Feel free to close this issue -- AFTER you've gotten the warm fuzzies you deserve. :)

Did you consider adding a check that all the licenses are compatible?

Hi! 👋

I'm currently looking into packaging this crate for Arch Linux (and I see a lot of use-cases to improve our Rust packaging with this here tooling!).

We usually follow our Rust packaging guidelines when packaging Rust projects.

For this we use cargo fetch --locked to fetch the relevant sources to later build (using cargo build --frozen).

With the 0.6.0 there is unfortunately a mismatch between the Cargo.toml (project version set to 0.6.0) and the Cargo.lock (project version set to 0.5.2).
This prevents cargo fetch --locked and downstreams have to patch the Cargo.lock file before proceeding.

It would be great to include an updated/matching Cargo.lock in upcoming updates.

Thanks for your work on this crate! 👏

I just feel that that's misleading.
Wouldn't it be better to check if:

• license-file is set in Cargo.toml
• AND license is not set in Cargo.toml

And say something like "Custom License" instead of N/A?

Related to #47

git clone https://github.com/gfx-rs/wgpu
cd wgpu/wgpu-hal
cargo license | wc -l  # prints 9
cargo license --no-deps | wc -l # prints 9

The tool returns licenses from the dependencies dependency ...

Is it possible to get only the licenses of my direct dependencies listed in the cargo.toml ?

Thanks

There seems to be a slight misunderstanding in the Boost-1.0 reporting as there is a BSL-1.0 (bussiness source license): https://mariadb.com/bsl-faq-adopting/

Fix: Report Boost-1.0 and not as BSL-1.0

It’s very common to have declared dependencies that don’t actually end up in the compiled result. Sometimes this is formalised via optional dependencies and Cargo features, but more of the time it isn’t—and even when it is, sometimes those features are accidentally enabled unnecessarily.

Such unused dependencies are not actually relevant for license compliance purposes and should preferably be removed; but cargo-license can’t currently do this.

(It’s probably even more common to have dependencies that are included in the compiled result but are never activated at runtime, but until they’re removed cargo-license is correct to care about them, and to get them removed you’d need to convince the compiler that they can’t be activated, which is commonly halting problem territory.)

Take this scenario:

• There is a Crate C.
• There is a Crate B which depends on Crate C, and exposes two functions, uses_c and does_not_use_c, which do as their names suggest.
• We are Crate A and depend on Crate B, calling its function does_not_use_c.

In this case, nothing from Crate C will end up in the final compiled artefact, and so we are not bound by Crate C’s license terms. Yet cargo-license will currently still include Crate C in its reckoning.

I propose a mode of operation for cargo-license that effectively runs cargo check and then traverses the compiler’s output at that point, eliminating from its reckoning any crate that has no contents present in the compiled artefact.

Implementation details aside, the main potential hitch I see here is macros and other compile-time-only dependencies. Legally, macro output will be license-bound some times but not others, depending on what it's doing and how it does it. I suppose build-dependencies are easy enough to flag in this way (they already are, to a large extent, though this would provide new opportunities for transitive removal of dev-dependencies and build-dependencies), but I’m not sure if you can track macro stuff through the compilation or not.

I think my ideal form of output would be dividing the crates into three categories:

• “definitely used, follow the license”;
• “potentially used (at build time or via macros), follow the license unless you investigate carefully”; and
• “definitely not used on this target, don’t worry about the license for this target”.

This issue is related to #42, which was closed by #43, which took things as far as possible without compiling code. The step I’m proposing would, I expect, be a rather large increase in scope, but I think it’s worthwhile.

Hey, I realize the maintainers of this project might be busy (aren't we all). However, this crate should be maintained as it fulfills a somewhat important role in the ecosystem. If you don't have time to care for this, could you please pass on the maintenance of this crate to some other maintainers?

Please don't take this the wrong way. :)

This is more of a question...I think...

I have a Rust project with the following dependencies:

[dependencies]
postgres = { version = "0.19.0", features = ["with-serde_json-1"] }
postgres-openssl = "0.5.0"
reqwest = { version = "0.11.0", features = ["blocking"] }
native-tls = "0.2.7"
openssl = { version = "0.10.32", features = ["vendored"] }
timer = "0.2.0"
chrono = "0.4.19"
clap = "2.33.3"
ctrlc = { version = "3.1.7", features = ["termination"] }
serde = "1.0.120"
serde_json = "1.0.61"

When I run cargo license, I get the following listing:

Apache-2.0 (1): openssl
Apache-2.0 OR Apache-2.0 WITH LLVM-exception OR MIT (1): wasi
Apache-2.0 OR BSL-1.0 (1): ryu
Apache-2.0 OR MIT (120): async-trait, autocfg, base64, bitflags, block-buffer, bumpalo, cc, cfg-if, cfg-if, chrono, core-foundation, core-foundation-sys, cpuid-bool, crypto-mac, ctrlc, digest, encoding_rs, fallible-iterator, fnv, foreign-types, foreign-types-shared, form_urlencoded, futures, futures-channel, futures-core, futures-executor, futures-io, futures-macro, futures-sink, futures-task, futures-util, getrandom, hashbrown, hermit-abi, hmac, http, httparse, httpdate, hyper-tls, idna, indexmap, ipnet, itoa, js-sys, lazy_static, libc, lock_api, log, md5, mime, miow, native-tls, ntapi, num-integer, num-traits, num_cpus, once_cell, opaque-debug, openssl-probe, openssl-src, parking_lot, parking_lot_core, percent-encoding, pin-project, pin-project, pin-project-internal, pin-project-internal, pin-project-lite, pin-utils, pkg-config, postgres, postgres-openssl, postgres-protocol, postgres-types, ppv-lite86, proc-macro-hack, proc-macro-nested, proc-macro2, quote, rand, rand_chacha, rand_core, rand_hc, remove_dir_all, reqwest, scopeguard, security-framework, security-framework-sys, serde, serde_json, serde_urlencoded, sha2, siphasher, smallvec, socket2, stringprep, syn, tempfile, time, tokio-openssl, tokio-postgres, typenum, unicode-bidi, unicode-normalization, unicode-width, unicode-xid, url, vcpkg, vec_map, version_check, wasm-bindgen, wasm-bindgen-backend, wasm-bindgen-futures, wasm-bindgen-macro, wasm-bindgen-macro-support, wasm-bindgen-shared, web-sys, winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu
Apache-2.0 OR MIT OR Zlib (2): tinyvec, tinyvec_macros
BSD-3-Clause (2): instant, subtle
MIT (31): ansi_term, atty, bytes, clap, generic-array, h2, http-body, hyper, matches, mio, nix, openssl-sys, phf, phf_shared, redox_syscall, redox_syscall, schannel, slab, strsim, textwrap, tokio, tokio-native-tls, tokio-stream, tokio-util, tower-service, tracing, tracing-core, tracing-futures, try-lock, want, winreg
MIT OR Unlicense (2): byteorder, memchr
MPL-2.0 (1): timer

Something that caught my eye in this list was the following that was included in the output:

winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu

If I run cargo tree on the same project, these are not included anywhere. I'm just curious as to why cargo tree wouldn't include these but cargo license would. Most likely it is just me not understanding why.

I am running these commands from Ubuntu 20.10 in WSL2 on Windows 10 if that helps any.

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.10 (Groovy Gorilla)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.10"
VERSION_ID="20.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy

Hi!
is it intentional that 0.5.1 tag is missing, or just an oversight?