Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
Description
A customer is asking to extend SBOMs beyond their original goal of NTIA and executive order compliance. Apparently, own product and dependencies need to be have license and copyright statement.
copyright statement can be deduced automatically, so there must be some file that we can hardcode this information in.
License (as SPDX-id) can in theory be deduced by github APIs
Here is the rough plan -
the "machine-readable" file will be yaml-formatted. It consists of a yaml-list. i.e items starting with <dash>-name, every items has a couple of keys, license and maybe "copyright" if known, but also information we hardcoded elsewhere, e.g CPE identifier, or publisher. a cmake parser function will convert the list and they keys into a set of cmake variables, e.g THIRD_PARTY_ZLIB_LICENSE will be taken from
-zlib
|
license:GPL2
|
Attachments
Issue Links
- relates to
-
PT-438 Loading...
Activity
| Field | Original Value | New Value |
|---|---|---|
| Remote Link | This issue links to "PT-438 (Jira)" [ 37468 ] |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Description |
A customer is asking to extend SBOMs beyond their original goal of NTIA and executive order compliance. Apparently, own product and dependencies need to be have license and copyright statement.
copyright statement can be deduced automatically, so there must be some file that we can hardcode this information in. License (as SPDX-id) can in theory be deduced by github APIs |
A customer is asking to extend SBOMs beyond their original goal of NTIA and executive order compliance. Apparently, own product and dependencies need to be have license and copyright statement.
copyright statement can be deduced automatically, so there must be some file that we can hardcode this information in. License (as SPDX-id) can in theory be deduced by github APIs Here is the rough plan - the "machine-readable" file will be yaml-formatted. It consists of a yaml-list. i.e items starting with <dash>-name, every items has a couple of keys, license and maybe "copyright" if known, but also information we hardcoded elsewhere, e.g CPE identifier, or publisher. a cmake parser function will convert the list and they keys into a set of cmake variables, e.g THIRD_PARTY_ZLIB_LICENSE will be taken from {noformat} -zlib license:GPL2 {noformat} |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Assignee | Vladislav Vaintroub [ wlad ] | Sergei Golubchik [ serg ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Assignee | Sergei Golubchik [ serg ] | Vladislav Vaintroub [ wlad ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Component/s | OTHER [ 10125 ] | |
| Fix Version/s | 11.8.2 [ 30001 ] | |
| Fix Version/s | 11.8 [ 29921 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
there were discussions about machine-parseable license file that distros at some point wanted.
if we'll have that we can machine-parse it from cmake for SBOM