Did a quick test build for it and seems the main issue is or rpmalloc crate which is lacking support (https://github.com/EmbarkStudios/rpmalloc-rs/issues/11). We could for now disable the custom global allocator for now for this target

Version: 0.2.0

With newlines in <pre> formatted sections in the hbs, the generated .html has the newlines removed. This is true whether it's static text or {{text}} from a license.

(Happens to be running on windows, but don't see any unix newlines either)

This was not a problem with 1.x.

Checklist

• [x] I have read the Contributor Guide
• [x] I have read and agree to the Code of Conduct
• [x] I have added a description of my changes and why I'd like them included in the section below

Description of Changes

This PR updates SPDX to version 0.9, which will allow cargo-about to run against Elastic-2.0 licensed crates.

Related Issues

This is the second step towards fixing https://github.com/apollographql/router/issues/2055

PS: I tried to understand where spdx_cache.bin.zstd comes from and how to update it, but I'm not sure.

Happy to update it and add a section to the readme if it can help :)

Describe the bug The latest release (0.4.2) fails to build on my machine. Error:

error[E0599]: no method named `compat` found for struct `anyhow::Error` in the current scope
  --> /home/stefano/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-about-0.4.2/src/licenses.rs:21:24
   |
21 |         .map_err(|e| e.compat())
   |                        ^^^^^^ method not found in `anyhow::Error`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `cargo-about` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-about v0.4.2`, intermediate artifacts can be found at `/tmp/cargo-installGSR9B8`

To Reproduce Try to install the latest cargo-about release with cargo install --version "=0.4.2" cargo-about

Expected behavior cargo-about can be compiled successful.

Device:

• OS: Ubuntu 20.04.3 LTS
• Rust Compiler: rustc 1.56.1 (59eed8a2a 2021-11-01)

Additional Infos: If I compile the latest version of this git repo (0c74659e7e24f3a894cdb3a6e7dacfd2ea8c6b48) cargo build as well as cargo build --release can compile. Maybe the version on crates.io is different :thinking: .

For our about box we would just list the direct dependencies. A config flag for ignoring transitive dependencies would be awesome!

Thanks a lot for sharing this really helpful tool 🙏

The AGPL-1.0-open license causes everything to fail (and I don't know what is using this license as cargo lichking and cargo license aren't listing it anywhere). If I include "AGPL-1.0-only" in the list of accepted licenses, cargo about spits out an error:

$ cargo about generate about.hbs > license.html
2020-02-18 16:52:09 [ERROR] 'AGPL-1.0-only' is not a valid SPDX licensee: AGPL-1.0-open
^^^^^^^^^^^^^ unknown term for key `accepted` at line 1 column 1

If I change that to AGPL-1.0 (as suggested by https://embarkstudios.github.io/cargo-deny/checks/licenses/cfg.html#gnu-licenses), I get:

$ cargo about generate about.hbs > license.html
2020-02-18 16:53:11 [ERROR] Crate 'app': These licenses [AGPL-1.0-only], could not be satisfied with the following accepted licenses [Apache-2.0, MIT, CC0-1.0, MIT, BSD-2-Clause, BSD-3-Clause, MPL-2.0, ISC, Zlib, Unlicense, 0BSD, BSL-1.0, CC-BY-3.0, OpenSSL, AGPL-1.0]

This is being run in a workspace root. The app is the main binary of the project, and isn't currently licensed (I have set publish = false and license-file = "LICENSE" in the crate's Cargo.toml) (I know this is incompatible with AGPL-1.0, but again as far as I can tell, nothing is using AGPL-1.0 anyway).

(edit note I typed AGPL-1.0-open, but that was a mistake and it should have been AGPL-1.0-only, the issue remains however)

D:\dev\learn-opengl>cargo about init
error: Found argument 'init' which wasn't expected, or isn't valid in this context

USAGE:
    cargo-about.exe [OPTIONS] <SUBCOMMAND>

For more information try --help

Perhaps the readme is old? or it's for the next version to be published?

Describe the bug I'm trying to run cargo about generate on a library that uses ring indirectly, and I'm being met by a rather confusing error message:

❯ cargo about generate about.hbs > license.html
2022-07-23 11:30:00.6617877 +00:00:00 [WARN] crate 'ring 0.16.20' doesn't have a license field
error: failed to satisfy license requirements
   ┌─ C:\Users\alexs\.cargo\registry\src\github.com-1ecc6299db9ec823\ring-0.16.20\Cargo.toml:28:13
   │
28 │ license = "(GPL-1.0-or-later AND OpenSSL AND OpenSSL OR (BSD-3-Clause OR GPL-1.0-or-later)) AND (ISC) AND (ISC AND MIT AND NOASSERTION AND OpenSSL) AND (MIT) AND (NOASSERTION) AND (NOASSERTION AND OpenSSL) AND (OpenSSL) AND (OpenSSL AND OpenSSL OR (BSD-3-Clause OR (GPL-1.0-or-later OR GPL-2.0-only))) AND (OpenSSL AND OpenSSL OR (BSD-3-Clause OR GPL-1.0-or-later))"
   │             ----------------     -------     -------                     ----------------                                  -----------     -------                 -----------       -----------     -------       -------       -------     -------                      ----------------    ------------         -------     -------                     ----------------

I say it's confusing, because 1) just above it says "ring 0.16.20 doesn't have a license field" and 2) Despite this, it manages to produce a license field from somewhere, but it's definitely not @ ring-0.16.20\Cargo.toml:28:13 because 28:13 is

[package.metadata.docs.rs]
            ^ Here

To Reproduce Steps to reproduce the behavior:

1. Run cargo init
2. Add ring = "0.16" as a dependency in Cargo.toml
3. Run cargo about init
4. Run cargo about generate
5. Get error above
6. Check the source linked to and see that it's pointing on something entirely different than the provided error span.

Expected behavior I feel like this error could do with some improvement. I have absolutely no idea what this error is talking about, because it's pointing to the wrong file, and I don't know which one it actually printed an excerpt from.

I think I'm missing something but when running cargo about generate about.hbs, I bump into this error:

error: failed to satisfy license requirements
   ┌─ /home/geobert/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/Cargo.toml:28:13
   │
28 │ license = "(GPL-1.0-or-later AND OpenSSL AND OpenSSL OR (BSD-3-Clause OR GPL-1.0-or-later)) AND (ISC) AND (ISC AND MIT AND NOASSERTION AND OpenSSL) AND (MIT) AND (NOASSERTION) AND (NOASSERTION AND OpenSSL) AND (OpenSSL) AND (OpenSSL AND OpenSSL OR (BSD-3-Clause OR (GPL-1.0-or-later OR GPL-2.0-only))) AND (OpenSSL AND OpenSSL OR (BSD-3-Clause OR GPL-1.0-or-later))"

I tried to put in about.toml:

[ring]
accepted = ["OpenSSL"]

[ring.clarify]
license = "ISC AND MIT AND OpenSSL"

with no luck.

What am I doing wrong?

Thanks!

Describe the bug Following https://embarkstudios.github.io/cargo-about/cli/generate/config.html#the-ignore-field I put

[licenses]
private = { ignore = true }

into my about.toml (at the end of the file) and it is rejected when running cargo about generate about.hbs

Expected behavior should accept private field as mentioned in the book

Device:

• OS: Ubuntu in WSL
• Version cargo-about 0.5.1

Is your feature request related to a problem? Please describe. Setting private = { ignore = true } will ignore any crates in the current workspace that are set publish = false, but I also have some private crate dependencies that I include from other git repositories. When using these dependencies cargo-about will warn about the licenses for these crates.

Describe the solution you'd like Add an option to extend ignoring private crates outside of the workspace. Perhaps the toml choices could be:

private = { ignore = true }
private = { ignore = "all" }
private = { ignore = "workspace" }

Describe alternatives you've considered I think it might be possible to do with clarifications, if I added a clarification for each external dependency. It also might be possible to use a LicenseRef-xyz in these dependencies, but I really just rather not bother with all of this.

None of the windows-rs targets have license files in the crate source, instead there is a license file in the top level of the git repo.

As seen here: https://github.com/microsoft/windows-rs there are both MIT and Apache-2.0 licenses available, but none of the crates in the targets directory have license files, giving the generated license file the default MIT license without the correct copyright info for these targets (e.g. windows_x86_64_msvc)

The workaround I'm using is to set the clarification path to ../windows-sys-0.42.0/license-mit which is just escaping to another crate from this same repo which does have a license file and is checksum identical to the one at the root of the repo. I don't know why this crate has a copy of the license and none of the targets do but whatever works I guess.

Describe the bug I have a variety of dependencies that are licensed under GPL-3.0 WITH Classpath-exception-2.0. The license check seems to work correctly but the generated html report puts the dependencies in the GNU General Public License v3.0 only section without any mentioning of the classpath exception. Mentioning the exception is quite important in this case and so I would like it to show up in the generated report.

To Reproduce Steps to reproduce the behavior:

1. Create a new empty cargo project
2. Add a dependency to fui_core = "0.12.0" (which has GPL-3.0 WITH Classpath-exception-2.0 license)
3. Run cargo about init
4. Modify the about.toml to this:

accepted = [
    "Apache-2.0",
    "MIT",
    "GPL-3.0 WITH Classpath-exception-2.0",
    "Unicode-DFS-2016",
]

7. Run cargo about generate about.hbs > license.html
8. Check the generated license.html

Expected behavior Ideally the dependency would be listed in a GNU General Public License v3.0 WITH Classpath-exception-2.0 section and the exception text would be appended to the "normal" license.

Is your feature request related to a problem? Please describe. For our CI I would like the execution of cargo-about to return an error code if there are any warnings (e.g. crate XY doesnt have a license field`) such that our build pipeline would fail if there are any warnings. Currently it is easy to overlook these warnings.

Describe the solution you'd like It would be nice to have a config flag like fail-on-warning to support this use case.

Describe alternatives you've considered We could also check/parse the output of cargo-about but I would prefer to just return an error code.

Is your feature request related to a problem? Please describe.

We have been (successfully, tysm! ❤️) using cargo about to generate our licenses.html file for a while, and we love it so much we have had a CI step that ensures the licenses.html file is always up to date.

We currently do that by invoking cargo about generate in CI and checking if there's a diff.

CI sometimes turns red, and after a bit of investigation it seems like the licenses.html file generation isn't deterministic.

Describe the solution you'd like

Would you be open to receiving a PR that makes licenses.html file generation deterministic?

I haven't dug too much yet (I wanted to first make sure this would fit your goals, and you'd be open to receiving a PR first), but this may involve having a (possibly gated) "preserve-order" feature on serde_json, but it might be a bit more involved.

Describe alternatives you've considered

We haven't considered any alternatives yet, but we'd be happy to discuss this if there's an other way to make sure licenses are always in sync :)

Thanks a lot! :)

Is your feature request related to a problem? Please describe. Right now, cargo-deny and cargo-about are two separate tools. This is fine, except that both tools will validate the license files used in the project.

As such, the list of accepted licenses needs to appear in both about.toml's accepted = [] and deny.toml's allow = [] arrays.

Describe the solution you'd like The simplest solution I think would be for cargo-about to not need an accepted array and simply spit out all found licenses. Or at least having a flag to do so. This way, I could use cargo-about to generate the license file and cargo-deny to enforce license requirements.

Describe alternatives you've considered Maybe the two configurations could be merged? For example cargo-about could read the deny.toml file and pick up the allowed licenses in there. about.toml contains more config options, so those would need to be moved to deny.toml. That's a large breaking change though.

Is your feature request related to a problem? Please describe.

I need to provide licenses for non-crate code that is being included in a project. The code is in C and is wrapped in a -sys FFI crate. Right now, cargo-about will see the -sys crate and include its license, but cannot go further and find the wrapper C code's license.

Describe the solution you'd like

I don't expect cargo-about to be able to track the C code license as it does for Rust crates, but it would be nice if I could manually add "extra" licenses to include in the final report. I think the about.toml config file might be the best place that information.

Describe alternatives you've considered

The final report could be manually edited but that brings us back to scripts to build the license file