nuttx/apps: migrate to SPDX identifier

[jerpelea]

Summary

Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.

Impact

SBOM

Testing

CI

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR description does not adequately meet the NuttX requirements. While it touches on some points, it lacks crucial details. Here's a breakdown of what's missing:

• Summary: While it states the why, it's very vague about the what and how. Which tools are affected? What part of the code is changed to use SPDX identifiers? How are these identifiers being integrated? A concrete example would be helpful. Issue/PR references are missing.

• Impact: Simply stating "SBOM" is insufficient. While it implies an impact on documentation (the SBOM itself), it doesn't explicitly state this. All other impact categories need to be addressed with a "YES/NO" and description if yes. Even if the answer is NO for all others, it must be explicitly stated.

• Testing: "CI" is not sufficient. While Continuous Integration is important, local testing details are required. Which host OS, CPU, compiler were used? What specific target architecture and board/configuration were tested? The requirement specifically asks for logs before and after the change, and these are missing. Just saying the code works "as intended" isn't verifiable.

Example of how to improve this PR description:

Summary

Currently, our codebase lacks standardized component identification, making automated SBOM generation difficult. This change integrates SPDX license identifiers into the Makefile (or specific file/function) for each library/module used by [specific part of NuttX]. This will enable tools like [tool name] to accurately identify components and generate a compliant SBOM. Relates to [NuttX Issue # if applicable].

Impact

• Is new feature added? NO
• Is existing feature changed? YES (Improved SBOM generation capability)
• Impact on user (will user need to adapt to change)? NO
• Impact on build (will build process change)? NO
• Impact on hardware (will arch(s) / board(s) / driver(s) change)? NO
• Impact on documentation (is update required / provided)? YES (The generated SBOM will be updated. Documentation on how to generate the SBOM may need updating).
• Impact on security (any sort of implications)? NO
• Impact on compatibility (backward/forward/interoperability)? NO
• Anything else to consider? This change facilitates future compliance efforts.

Testing

I confirm that changes are verified on local setup and works as intended:

• Build Host(s): Linux (Ubuntu 20.04), x86_64, GCC 9.4.0
• Target(s): sim:qemu-x86_64

Testing logs before change:

$ [command to generate SBOM]
[output showing missing/incorrect component identification]

Testing logs after change:

$ [command to generate SBOM]
[output showing correct SPDX identifiers and complete SBOM]

[cederom]

Thank you @jerpelea :-)

[yamt]

this broke toywasm regen.sh.
#2920 contains a fix.

[cederom]

sorry i just got back from a holiday break.. and some flu.. all seems merged now. thank you @jerpelea !! :-)