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

Should license detection also return SPDX license expressions? #1217

Closed
pombredanne opened this issue Oct 19, 2018 · 6 comments
Closed

Should license detection also return SPDX license expressions? #1217

pombredanne opened this issue Oct 19, 2018 · 6 comments

Comments

@pombredanne
Copy link
Member

Today we have this:

  • when the output is SPDX, we return proper SPDX license expressions using SPDX license ids
  • otherwise (JSON, etc) we return
    • license expressions using ScanCode own license keys
    • a list licenses and for these that are known at SPDX the corresponding SPDX license key

In this later case I wonder if it could be useful to also return license expressions using SPDX license ids.
This would be eventually a new option and would be returned under its own file-level attribute.
This could also possibly apply to a companion to the license_expression returned with packages for a package manifest. Now, of the 1301 licenses that scancode knows, only 375 are referenced at SPDX, therefore there will be quite a few "LicenseRef" in this case. See #532 for this issue and #532 (comment) in particular.

@sschuberth @mjherzog @DennisClark @armijnhemel Any feedback?

@sschuberth
Copy link
Collaborator

Maybe @mnonnenmacher also has an opinion about this as we were just today discussing this in some other context.

@armijnhemel
Copy link
Contributor

it makes sense to me. What I would love to see is the version of the SPDX standard that is used, so I don't have to guess :-)

@pombredanne
Copy link
Member Author

@armijnhemel good point! We can set the version of the SPDX license list in the scan headers.

@pombredanne
Copy link
Member Author

Maybe @mnonnenmacher also has an opinion about this as we were just today discussing this in some other context.

@mnonnenmacher ping?

@pombredanne pombredanne added this to the v3.1 milestone Dec 11, 2018
@pombredanne
Copy link
Member Author

This is going to be useful for ClearlyDefined and @dabutvin ... so this is going into 3.1 alright at the minimum.

@pombredanne
Copy link
Member Author

This is being merged in develop and will be in v32.0

@pombredanne pombredanne added this to the v32.0 milestone Jan 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants