Difference between revisions of "Technical Team/Proposals/Rough proposal for provenance, hierarchy and aggregation, and supply chain friendliness in SPDX 2.0"

Revision as of 23:19, 5 December 2011

A desire has been expressed to be able to have SPDX be capable of expressing

1. Hiearchy ( package A contains packages B, C, etc)
2. Authentication ( we can know precisely who said what and when about a package)
3. 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_0.jpg" alt="" width="586" height="372" />

 The simple story behind this diagram is this:

1. The upstream maintainer of coreutils provides an SPDX file which
1. Provides information for the copyrighted entity that is the package as a whole
2. Provides embedded information for the copyrighted entity that is each file in the package (same format, just embedded and clearly down hiearchy)
3. Provides a coreutils.spdx.sig file with the signature for the coreutils.spdx file (so we can authenticate it)
2. This coreutils.spdx file is in the coreutils.tar.gz for the upstream
3. The rpm (or deb) packager creates a coreutils.spdx (distinct from the one for the upstream) in the rpm file which:
1. Provides information for the copyrighted entity that is the rpm (or deb) package as a whole
2. Provides embedded information for the copyrighted entity that is each file (such as patch files) contained in the rpm (or deb) package
3. 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.
4. Optionally provides and Annotation section to 'annotate' some of the information provided by the coreutils upstream.

Diagram for a Concrete proposal (very very rough) for structure (note, notes that say 'Concrete' or 'Referential' are just indicating an 'or' in the doc structure):

<img src="http://spdx.org/system/files/spdxdoodle2.jpg" alt="" />

Description of diagram

• Top: Simple top level place to start
• SPDXFile: File containing SPDX data
• SPDXElement: The containing element for SPDX data for a given copyrightable work contained in the SPDXFile.  It's SPDXElements all the way down.
• Specifier: Not really a node, sort of a grouper of nodes to indicate those fields which specify the 'thing' the SPDX Element is about
• LicenseData: not really a node, sort of a grouper of nodes to indicate those fields which specify what we know about the 'thing' this SPDX Element is about
• SPDXElements: zero or more additional 'contained' SPDX Elements referring to contained things (like files, or contained tarballs etc).
• Annotations: zero or more annotations indicating additional information about the contained SPDXElements (to handle the case where a contained SPDX Element represents a reference to a another SPDX file that is signed and thus we can't change directly) - Note, we need more thought here.
• Name: Equivalent to SPDX 1.0 Formal Name
• Version: Equivalent to SPDX 1.0 Package Version Information
• Supplier: Equivalent to SPDX 1.0 Package Supplier
• Summary: Equivalent to SPDX 1.0 Package Summary Description
• Description: Equivalent to SPDX 1.0 Package Detailed Description
• URI (in SPDXElement->Specifier): URI of the copyrightable thing being referenced, may point to a file, an archive, a package, etc.
• URICheckSum( in SPDXElement->Specifier): Checksum for the thing URI points to
• CopyrightText: Equivalent to SPDX 1.0 CopyrightText
• LicenseText: Full text of license if LicenseShortForm isn't available
• LicenseShortForm: License short form in lew of license text if available
• SPDXFileURI: If the SPDX Element does not contain it's own concrete license data but references an external SPDX File... the URI of that SPDXFile
• SPDXFileSigURI: If the SPDX Element references an external SPDXFile, the URI of the sig file for that SPDX file
• ACL: I hate the name ACL, but basically it's a way of specifying that you are including or excluding some of the copyrightable bits that are covered by the referenced SPDX File.  Say if you are *not* using 
• Exclude (in ACL):
• ExcludeAll (in ACL):
• Include (in ACL):
• SPDXFileSig: Separate file containing the signature for the octets of the SPDXFile