Incorrect LicenseRef-scancode being used

[ariel11]

ClearlyDefined picked an incorrect License Ref ID for this component - https://clearlydefined.io/definitions/npm/npmjs/@ag-grid-enterprise/status-bar/30.2.1/30.2.1.

I don't think another company’s EULA should get “LicenseRef-scancode-warranty-disclaimer,” which is described as a “catch all license” often used by Microsoft in its source code.

However, there does not appear to be a License Ref for the AG GRID ENTERPRISE EULA. How can I nominate that for a LicenseRef-scancode ID?

Also, I hope ClearlyDefined is not defaulting to the closest LicenseRef-scancode ID it thinks it has? If there's not a match, ClearlyDefined should still put NOASSERTION, correct?

[ariel11]

@elrayle - FYI. Thank you!

@capfei and @AE49 - FYI

[elrayle]

@ariel11 For questions or improvements to the licenses coming from ScanCode, you can see your options for support in the scancode-licensedb support page.

Screen shot here for reference. If you go to the support page, there are links.

[ariel11]

Thanks for the pointer @elrayle on where to propose new scancode license refs. To confirm - I think this is the correct location for the first part of this issue, correct? --> ClearlyDefined selecting an incorrect scancode license ref?

[elrayle]

@ariel11 I added an issue to scancode-licensedb using primarily your description in this issue.

• a company’s EULA is identified as “LicenseRef-scancode-warranty-disclaimer” aboutcode-org/scancode-toolkit#4082

There is another issue in scancode related to whether "unknown" licenses should be NOASSERTION. The issue has a long discussion, so the link jumps ahead to a comment that is more closely related.

• unexpected LicenseRefs scancode-toolkit/issue #3974

---

NOTE: There still may be work on the CD side to address:

I hope ClearlyDefined is not defaulting to the closest LicenseRef-scancode ID it thinks it has? If there's not a match, ClearlyDefined should still put NOASSERTION, correct?

[bduranc]

Sorry to jump late into this.

But isn't LicenseRef-scancode-unknown basically the same as what we would traditionally call a NOASSERTION?

This applies to the case where there is text referring to a license, but it is not possible to determine exactly which license.

[bduranc]

Also, I hope ClearlyDefined is not defaulting to the closest LicenseRef-scancode ID it thinks it has? If there's not a match, ClearlyDefined should still put NOASSERTION, correct?

I agree with @ariel11's initial concern around the use of LicenseRef-scancode-warranty-disclaimer in this particular example.
I'm still familiarizing myself with the LicenseRefs available, but it would seem appropriate that cases where a LicenseRef cannot be confidently assigned, default to NOASSERTION (or LicenseRef-scancode-unknown assuming it's a valid equivalent).

[ariel11]

I agree @bduranc. Also, there seems to be two LicenseRef's that both mean "there appears to be a LICENSE or license info, but can't tell what it is" - LicenseRef-scancode-unknown-license-reference and LicenseRef-scancode-unknown. Since users of ClearlyDefined will have established processes around NOASSERTION, it seems prudent to have ClearlyDefined continue using NOASSERTION in these cases. Otherwise, folks will have to update their processes (if they want to) to investigate three "can't tell what the license is" ID's. That is doable, but noisier.

[bduranc]

Since users of ClearlyDefined will have established processes around NOASSERTION, it seems prudent to have ClearlyDefined continue using NOASSERTION in these cases. Otherwise, folks will have to update their processes (if they want to) to investigate three "can't tell what the license is" ID's. That is doable, but noisier.

100% agreed @ariel11 . I think this would have the least impact on our downstream users and still allow them to benefit from LicenseRef for everything else.

So basically, to codify the logic:

if is_known_SPDX_license then:
    assign SPDX_ID
elif is_known_license_ref:
    assign license_ref
else:
    assign NOASSERTION