Multi license handling?

[kitplummer]

Just ran the tool for the first time.

Seeing:

[2022-10-07T21:15:51Z ERROR cargo_cyclonedx::generator] Package chrono has an invalid license expression, trying lax parsing (MIT/Apache-2.0): Invalid SPDX expression: invalid character(s)

For chrono as well as a slew of others that show MIT/Apache-2.0 as the license. Looked to see if anyone else has seen this or created an issue. Could just be the way I'm running the command? Figured I'd ask here before I create the issue.

[kitplummer]

Notice some like assert_cmd show MIT or Apache-2.0 as their license:

https://github.com/assert-rs/assert_cmd/blob/master/Cargo.toml

[amy-keibler]

Could just be the way I'm running the command? Figured I'd ask here before I create the issue.

Thanks for the question! #238 has some more context, but the short version is that we are attempting to parse the license field as an SPDX expression and there are a number of crates in the crates.io ecosystem that have things that are almost valid SPDX expressions.

We parse the / in MIT/Apache-2.0 as OR, but it could just as easily mean AND. When dealing with licenses, we don't want to make assumptions on the user's behalf, so we output an error message to let you know that we are defaulting to OR. We need to do this so we can output the SBOM with valid SPDX expressions that can be processed by tools that use that information for license compliance purposes, for example.

We're still in our pre-1.0 phase and working on polishing the user experience and documentation, so now is a great time to get your feedback on how we can improve this. My guess is that we could improve the wording and maybe change the level to WARN instead of ERROR, but anything else you can think of would be appreciated.

[kitplummer]

I am curious about the OR condition. I’m wondering if that should even be an allowable, valid, state - it should never allow an assumption to be possible. I ran the `-all` on my repo and there were a lot of them with this ERROR. Do you think this is worth raising to the Rust community? I’m guessing most are in the AND state. I did notice that the bom.xml was produced. I think generally an ERROR condition implies unsuccessful completion with an accompanying status code. Perhaps a flag should be provided to ignore errors?

…

On Sat, Oct 8, 2022 at 7:38 PM Amy Keibler ***@***.***> wrote: Could just be the way I'm running the command? Figured I'd ask here before I create the issue. Thanks for the question! #238 <#238> has some more context, but the short version is that we are attempting to parse the license field as an SPDX expression and there are a number of crates in the crates.io ecosystem that have things that are *almost* valid SPDX expressions. We parse the / in MIT/Apache-2.0 as OR, but it could just as easily mean AND. When dealing with licenses, we don't want to make assumptions on the user's behalf, so we output an error message to let you know that we are defaulting to OR. We need to do this so we can output the SBOM with valid SPDX expressions that can be processed by tools that use that information for license compliance purposes, for example. We're still in our pre-1.0 phase and working on polishing the user experience and documentation, so now is a great time to get your feedback on how we can improve this. My guess is that we could improve the wording and maybe change the level to WARN instead of ERROR, but anything else you can think of would be appreciated. — Reply to this email directly, view it on GitHub <#282 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBGLFK3T4TDXJ2B3M6D3WCIAWVANCNFSM6AAAAAAQ76CNEI> . You are receiving this because you authored the thread.Message ID: <CycloneDX/cyclonedx-rust-cargo/repo-discussions/282/comments/3830948@ github.com>

[amy-keibler]

Unfortunately, despite the documented SPDX schema for the license field, I think there is not yet a strong consensus in the Rust community (this issue was one I found when doing the initial research shows that some crates likely won't change without a compelling reason). I don't want to go out and bother a bunch of maintainers to get them to change, so I think we're stuck with accepting the field as it is for now.

As for why I'm accepting / as OR, the linked issue shows that crates.io interprets it that way, so I think it's legally safe enough to infer that someone publishing their crate on crates.io accepts that interpretation.

I did notice that the bom.xml was produced. I think generally an ERROR condition implies unsuccessful completion with an accompanying status code. Perhaps a flag should be provided to ignore errors?

What are your thoughts on a --strict flag? I'm trying to balance the impact of a negative user experience of running the tool -> it failing -> running the tool with an --allow-invalid-licenses flag with the negative user experience of running the tool and having a different assumption about the license of a dependency from what the tool assumes (even with a warning message).

[Shnatsel]

There is now an elaborate system for handling cases like these, with in-depth configuration via CLI flags, so I'm going to go ahead and close this as resolved.