LicenseView treats NOASSERTION and NONE differently

[bennati]

ORT detects multiple instances of GPL in the Gpgme dependency, but no rule violation is raised in the scan report.
For context, our rules.kts contains the following:

fun RuleSet.strongCopyleftInDependencyRule() = dependencyRule("STRONG_COPYLEFT_IN_DEPENDENCY") {
    licenseRule("STRONG_COPYLEFT_IN_DEPENDENCY", LicenseView.CONCLUDED_OR_DECLARED_OR_DETECTED) {
        require {
            +isStrongCopyleftLicense() # includes GPL
            -isExcluded()
...

According to the documentation, CONCLUDED_OR_DECLARED_OR_DETECTED ignores detected licenses if a license is concluded or declared.
Because the SPDX attribute licenseConcluded is mandatory, the docs suggest to use NOASSERTION to represent a non present value.

I would expect that the license rule would interpret NOASSERTION as “no license is concluded or declared”, evaluate the detected licenses and raise rule violations, but this is not the case. In fact, I see in the ‘Licenses’ section of the gpgme entry in the scan report “Declared (SPDX) NOASSERTION”.

ORT behaves as expected when replacing NOASSERTION with NONE : rules violations are raised and the scan report shows “Declared NONE” and no “Declared (SPXD)“.

The SPDX file:

SPDXID: SPDXRef-DOCUMENT
spdxVersion: SPDX-2.2
dataLicense: CC0-1.0
name: test
documentNamespace: test
creationInfo:
  created: 2025-02-24T00:00:00Z
  creators:
    - "Organization: HERE"
documentDescribes:
- SPDXRef-package-here-test

packages:
  - SPDXID: SPDXRef-package-here-test
    name: here-test
    downloadLocation: https://gitlab.here.com/test.git
    licenseConcluded: NOASSERTION
    licenseDeclared: NOASSERTION
    copyrightText: Copyright (C) 2025 HERE Global B.V. and its affiliate(s).
  - SPDXID: SPDXRef-Package-Gpgme
    name: gpgme
    versionInfo: 1.15.1
    downloadLocation: https://www.gnupg.org/ftp/gcrypt/gpgme/gpgme-1.15.1.tar.bz2
    licenseConcluded: NOASSERTION
    licenseDeclared: NOASSERTION

relationships:
  - spdxElementId: SPDXRef-Package-Gpgme
    relationshipType: DEPENDENCY_OF
    relatedSpdxElement: SPDXRef-package-here-posbe-backend-cloudio

[sschuberth]

Let me start by saying that SPDX's licenseConcluded field does not necessarily have the same semantics as ORT's concludedLicense field. You already mentioned one difference: Whereas in SPDX the licenseConcluded can have special values NONE and NOASSERTION, in ORT the concludedLicense as to be a definite license.

When further drilling down into the semantics of SPDX's licenseConcluded field, it's advisable to look at the SPDX specification instead of ORT's documentation. From here you can gather that NOASSERTION can be used in three (quite different) cases:

• the SPDX document creator has attempted to but cannot reach a reasonable objective determination;
• the SPDX document creator has made no attempt to determine this field; or
• the SPDX document creator has intentionally provided no information (no meaning should be implied by doing so).

So actually, NOASSERTION does not necessarily represent a non-present value. It could also mean a present but unknown / unclear value. Which means that it could actually be a new yet-to-be classified license, which could turn out to be strict-copyleft.

However, it's not definitely a strict-copyleft license.

I'm just sharing my thoughts here, not implied what to do here. I still need to make up my mind myself about whether, with the above in mind, we should trigger that rule violation or not. What are your throughts @oss-review-toolkit/tsc?