THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Proposals/Rough proposal for provenance, hierarchy and aggregation, and supply chain friendliness in SPDX 2.0
From SPDX Wiki
A desire has been expressed to be able to have SPDX be capable of expressing
- Hiearchy ( package A contains packages B, C, etc)
- Authentication ( we can know precisely who said what and when about a package)
- How software flows through a supply chain (upstream to packager, through several intermediate vendors to consumer)
A rough example of this thought is shown in the diagram below, showing how the coreutils package might be represented:
<img src="http://spdx.org/system/files/spdxdoodle.jpg" alt="" width="586" height="372" />
The simple story behind this diagram is this:
- The upstream maintainer of coreutils provides an SPDX file which
- Provides information for the copyrighted entity that is the package as a whole
- Provides embedded information for the copyrighted entity that is each file in the package (same format, just embedded and clearly down hiearchy)
- This coreutils.spdx file is in the coreutils.tar.gz for the upstream
- The rpm (or deb) packager creates a coreutils.spdx (distinct from the one for the upstream) in the rpm file which:
- Provides information for the copyrighted entity that is the rpm (or deb) package as a whole
- Provides embedded information for the copyrighted entity that is each file (such as patch files) contained in the rpm (or deb) package
- For the coreutils.tar.gz file (also contained in the rpm or deb package), provides it's SPDX information by *referencing* the coreutils.spdx in the coreutils.tar.gz file.
- Optionally provides and Annotation section to 'annotate' some of the information provided by the coreutils upstream.