Open pombredanne opened 2 years ago
A new license rule for npm should fix this, should I make the changes?
A new license rule for npm should fix this, should I make the changes?
@adii21-Ux good point! yes... please go ahead. Thank you ++
@pombredanne I tried to solve it by adding a new rule but no use can you please explain any other ways
We have specified LicenseRef-LICENSE here but its not detecting it so should I declare new .LICENSE and .yml for this specific key
We have specified LicenseRef-LICENSE here but its not detecting it so should I declare new .LICENSE and .yml for this specific key
this would be a likely bug in the code that's supposed to do this. That's the npm code to compute a normalized license
I think that this can be fixed in code and not just with a rule. See https://github.com/nexB/scancode-toolkit/blob/7bc0782fdfda9da5dba0500446ff3e8d58623e99/src/packagedcode/npm.py#L485 and https://github.com/nexB/scancode-toolkit/blob/7bc0782fdfda9da5dba0500446ff3e8d58623e99/src/packagedcode/models.py#L658
See https://github.com/search?p=2&q="LicenseRef-LICENSE"&type=Code
Over the years, npm had a few evolving conventions:
See https://softwareengineering.stackexchange.com/questions/285885/which-spdx-license-is-equivalent-to-all-rights-reserved
https://github.com/npm/npm/issues/8795#issuecomment-119760485
and https://www.bonbon.io/commercial-licenses-for-npm-packages
This legacy way should be supported. It is seen on bower packages too