Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
vemonet opened this issue Aug 22, 2024 · 2 comments · Fixed by #703
Labels
bug Something isn't working

Comments

@vemonet
Copy link

vemonet commented Aug 22, 2024

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 vemonet added the bug Something isn't working label Aug 22, 2024
@vemonet
Copy link
Author

vemonet commented Sep 19, 2024

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
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants