Invalid SPDX license identifier used in file

[kestewart]

Describe the bug
An invalid SPDX license identifier is being specified in
https://github.com/zephyrproject-rtos/openthread/blob/zephyr/third_party/NordicSemiconductor/libraries/nrf_security/config/nrf-config.h

SPDX-License-Identifier: BSD-3-Clause OR Arm’s non-OSI source license

The phrase "Arm's non-OSI source license" is not a valid SPDX license identifier.

To Reproduce
The problem is in the source files, and needs to be addressed there.

Expected behavior
Valid SPDX license identifier from https://spdx.org/licenses/ should be used, or
a "LicenseRef-" identifier should be created and used. Details on the "LicenseRef-" syntax can be found in https://spdx.github.io/spdx-spec/6-other-licensing-information-detected/#61-license-identifier should be used in the expression

Impact
Serious - this breaks tooling working to summarize the licenses for the sources and generate SPDX documents.

Logs and console output

FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/config/nrf-config.h
SPDXID: SPDXRef-File-nrf-config.h
FileChecksum: SHA1: e667be982ab96d6d59de7b965538cb109d91d18c
FileChecksum: SHA256: fb5342294f7c89fba780af925abb41aecf583a1d692e73d05a8d0b2af581203c
LicenseConcluded: BSD-3-Clause OR Arm’s non-OSI source license
LicenseInfoInFile: Arm’s
LicenseInfoInFile: BSD-3-Clause
LicenseInfoInFile: license
LicenseInfoInFile: non-OSI
LicenseInfoInFile: source
FileCopyrightText: NOASSERTION

Environment (please complete the following information):
The problem can be seen in the source file.

Additional context
This same problem can also be seen in:
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/ccm_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/chacha20_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/chachapoly_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/ecp_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/platform_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/poly1305_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/sha1_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/sha256_alt.h
FileName: ./modules/lib/openthread/third_party/NordicSemiconductor/libraries/nrf_security/include/mbedtls/threading_alt.h

[carlescufi]

@kestewart what would be the correct way of expressing the dual-licensing using SPDX? To have 2 separate SPDX lines?

[kestewart]

@carlescufi The way the license expression itself is written is fine. Problem is

The phrase "Arm's non-OSI source license" is not a valid SPDX license identifier.

See the link provided earlier for how to code up something that doesn't have an equivalent on
the SPDX license list.

Possibly Arm has a standard SPDX identifier they use for this license already ?

If not, suggest you follow the guidelines from https://reuse.software/spec/#license-files and create a License file in the module with the text of the license you want to represent, and then name it
something that conforms to the standard, like "LicenseRef-ARM-non-OSI-source".

Alternately - given that its an "OR" scenario, will your legal folk just let you release it with the BSD-3-Clause license and avoid the issue?

[swinslow]

From the SPDX community perspective, agreed with @kestewart -- LicenseRef-ARM-non-OSI-source would likely be fine as a custom identifier, and would be syntactically valid.

[carlescufi]

The OpenThread PR has now been merged: openthread/openthread#6137
So we either update our OpenThread copy or cherry-pick this commit into our fork. I will let @rlubos decide as the module maintainer.

[edmont]

@carlescufi, I proceeded with the upmerge: #32025