Bug: documentation to bulk accept OSI/FSF licenses leads to error when applied, and absence of working documentation to bulkd accept OSI/FSF licenses

[vemonet]

Describe the bug

In the past (~v0.14) there was a key allow-osi-fsf-free = "either" which would accept all OSI/FSF licenses by default. Which seems to be an excellent default, or at least something that should be easy to define for a user

The current documentation website mentions the use of allow-osi-fsf-free

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

But if I try to use allow-osi-fsf-free I get an error when running cargo deny check

[licenses]
allow-osi-fsf-free = "both"

cargo deny check
error[deprecated]: this key has been removed, see https://github.com/EmbarkStudios/cargo-deny/pull/611 for migration information
   ┌─ curies.rs/deny.toml:91:1
   │
91 │ allow-osi-fsf-free = "both"
   │ ━━━━━━━━━━━━━━━━━━

Moreover the allow-osi-fsf-free key has disappeared from the comment in the deny.toml generated by cago deny init, which seems to indicate that it is not supported anymore and that the documentation website is not up-to-date

Overall from the current documentation it is not clear how to bulk accept OSI/FSF licenses (I hope the feature has not disappeared! It is such a basic and useful feature), where can we find those instructions?

Thanks

To reproduce

1. Install the latest version of cargo-deny v0.16.1
2. cargo deny init
3. Add allow-osi-fsf-free = "both" to the generated deny.toml
4. Run cargo deny check > error

cargo-deny version

0.16.1

What OS were you running cargo-deny on?

Linux

Additional context

No response

[vemonet]

Any update on this @Jake-Shadle ?

It is really weird because if I try to use allow I get this error implying the allow-osi-fsf-free key still exists

error[unexpected-value]: expected '["both", "either", "osi", "fsf", "osi-only", "fsf-only", "neither"]'
   ┌─ /home/vemonet/dev/perso/curies.rs/deny.toml:91:23
   │
91 │ allow-osi-fsf-free = "allow"
   │                       ━━━━━ unexpected value

But if I use either I get this:

error[deprecated]: this key has been removed, see https://github.com/EmbarkStudios/cargo-deny/pull/611 for migration information
   ┌─ /home/vemonet/dev/perso/curies.rs/deny.toml:91:1
   │
91 │ allow-osi-fsf-free = "either"
   │ ━━━━━━━━━━━━━━━━━━

It is explicitly saying the whole config has been removed... 😂

But the PR description at #611 explicitly says that just the default changed for this key, so that's really the most confusing "error" message I ever got

How should we interpret these? Do we need to manually add all licenses we accept to allow? (seems quite bad tbh, the whole point of a library like cargo-deny is that it should be automatically figuring out those SPDX stuff for me)

[Jake-Shadle]

The current documentation website mentions the use of allow-osi-fsf-free

This was a leftover that's removed in #703, as stated multiple times in issues and the CHANGELOG, the field is removed.

It is really weird because if I try to use allow I get this error implying the allow-osi-fsf-free key still exists

This was a confusing oversight, removed in #703.

How should we interpret these? Do we need to manually add all licenses we accept to allow? (seems quite bad tbh, the whole point of a library like cargo-deny is that it should be automatically figuring out those SPDX stuff for me)

It's more to type, but all individual licenses must be explicitly allowed now. The reason for this change is that the more complicated configuration of osi-fsf-free/copyleft/etc was confusing to users. In reality even projects with hundreds of dependencies will only rely on a small handful of licenses and it's mostly a one time configuration, with the (IMO) good effect that dependencies changing licenses or adding new dependencies with a license not in this set is now apparent and can be discussed (change of ownership/maintainership is interesting when evaluating the health of dependency).