Trying out Licensebat on a repository of mine I ran into a problem (got the output No collector found for dependency file). From my investigation this is due to the fact that my project uses lockfile version 3. In contrast to versions 1 and 2, version 3 does not have "dependencies" field. Instead, it has "packages" (also present in version 2, not in version 1).

I have no idea why I pushed configuration file to root directory already and still reported no file found with these pull request:

• Anitemp PR 4
• Anitemp PR 5

I tried to delete and push the file to head branch directly and still reported not found.

Using [cargo-deny] as inspiration (not sure we can fully reuse it here), add support for Rust. They seem to use cargo-metadata.

See https://github.com/EmbarkStudios/cargo-deny/blob/d0ea0a2e7d7376ee212faec756cb12ab05f55c4d/docs/src/checks/licenses/README.md

Expression Source Precedence

The source of the SPDX expression used to evaluate the crate by is obtained in the following order.

1. If the crate in question has a Clarification applied to it, and the source file(s) in the crate's source still match, the expression from the clarification will be used.
2. The license field from the crate's Cargo.toml manifest will be used if it exists.
3. The license-file field, as well as all other LICENSE(-*)? files will be parsed to determine the SPDX license identifier, and then all of those identifiers will be joined with the AND operator, meaning that you must accept all of the licenses detected.

Evaluation Precedence

Currently, the precedence for determining whether a particular license is accepted or rejected is as follows:

1. A license specified in the deny list is always rejected.
2. A license specified in the allow list is always accepted.
3. If the license is considered copyleft, the [licenses.copyleft] configuration determines its status
4. If the license is OSI Approved or FSF Free/Libre, the [licenses.allow-osi-fsf-free] configuration determines its status, if it is neither the check continues
5. If the license does not match any of the above criteria, the [licenses.default] configuration determines its status

License files

Example of crate with license file: https://github.com/briansmith/ring/blob/main/LICENSE

Hi,

thanks for a great tool, it's been really helpful to us in our documentation process about usage of OSS libraries.

One thing that we are missing is a clearer distinction between :

• "non dev" dependencies : which end up as part of our final build product
• "dev" dependencies : which only exist for tooling and during development process

While the rules for license usage are usually strict for "non dev" dependencies (you don't want to build something that rely on viral licenses, that would force you to publish your product under the same license), they can sometimes be relaxed for "dev" dependencies.

Some of the parts where it would be useful to be refect it :

• listing of found dependencies : why is it listed ? "direct dev dependency" vs "direct prod dependency" ... (vs transitive dependency only for dev / transitive dependency only for prod / transitive dependency for both)
• configuration : ignore dev dependencies from list / have difference rules for valid licenses for dev vs "non-dev"

I hope I'm explaining myself 😅

I don't want to sound like a zealot, but this sentence:

Let's say, for instance, that you are building a commercial application. In that case, you may consider avoiding the use of some software with a restrictive license like GPL.

is not correct. One wants to avoid GPL because one wants to write proprietary software, not commercial software. GPL software can perfectly be commercial. I understand that "commercial" may be easier to understand for many but, to GPL advocates, the issue is not the commercial nature of software but the fact it is proprietary... So replacing "commercial" by "proprietary" in the sentence would be correct.

Bumps thread_local from 1.1.3 to 1.1.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps crossbeam-utils from 0.8.5 to 0.8.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This was not working as expected and I think it's better to not confuse the user. If we have no information about a license, the user should manually check it and ignore the dependency if he feels ok with that.

Instead of passing the client to the collector just to create an instance of a retriever, we must inject the retriever itself as a trait object.

By doing this, we can use one collector and use several retrievers. For instance, for Rust, we may want to use the crates.io retriever or the metadata retriever, which uses cargo metadata and it's better for cli executions where we have access to the whole source code.

The idea here is that we're able to easily mock the Store behaviour so we can test it properly without having to create one. For the moment, it's not really that critical as we can create askalono::Store quite easily.

Use httpmock to mock the calls to different APIs. This implies changing the way we're using the different API urls. As they're absolute, we should be able to find a mechanism to change the base url:

• Injection
• Env var

https://github.com/EmbarkStudios/spdx https://choosealicense.com/appendix/ https://crates.io/crates/cargo_metadata https://github.com/cds-astro/get-license-helper

This would help with AND and OR licenses