THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Technical Team/Use Cases/2.0"

From SPDX Wiki
Jump to: navigation, search
Line 1: Line 1:
−
<p>We have several sources to begin pulling for SPDX Use Cases:</p><ol><li>The Pad from earlier conversations collected at <a href="http://spdx.org/wiki/use-cases-collected-20-discussion">Use Cases For SPDX 2.0 Discussion</a></li><li>The old <a href="https://fossbazaar.org/wiki/spdx-use-case-1">SPDX 1.0 Use Cases</a>&nbsp;as well as the <a href="http://spdx.org/system/files/ecosystem.jpg">SDPX 1.0 Use Case Picture</a>.</li></ol><div>&nbsp;</div><div>I'd like to propose that we flesh out use cases here by having a brief summary listed here as a link to a more detailed child page. &nbsp; Note, these use cases should be *<strong>doable</strong>* but in general not *<strong>required</strong>*. &nbsp;Any item listed here that is not a link, should have a child page created for it.</div><div>&nbsp;</div><div><ol><li><a href="http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data">Upstream maintainer providing SPDX data</a></li><li>Upstream maintainer consuming another project</li><ol><li>Upstream maintainer including another project by including source</li><li>Upstream maintainer including another project by reference (think maven, possibly linking cases)</li><ol><li>by static reference (the referenced library is included with a redistribution)</li><li>by dynamic reference (express runtime dependency on the external library, but not redistributing it)</li></ol><li>Upstream maintainer pulling individual files out of another project (subsetting)</li></ol><li>Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data</li><ol><li>Intermediate packager subsetting upstream package</li></ol><li>Yocto [Jack Manbeck]</li><li>Aggregator aggregating many 'copyrightable items' for redistribution</li><ol><li>Linux Distros</li><li>Embedded Images</li><li>SDKs</li><li>Reference implementations</li><li>Eclipse/OSGI distributions</li><li>Application which ships with documentation + &nbsp;media + software [Jack Manbeck]</li></ol><li>Aggregators aggregating other aggergations for redistribution</li><li>Asserting corrections to SPDX data provided by others further upstream</li><li>Committers providing, or assenting to SPDX data</li><li>Committers annotating source files with SPDX info</li><li>Consumers receiving SPDX data</li><li>Signoff/multiple signoff on SPDX data</li><ol><li>Contracts with multiple parties requiring signoff by all [Kate Stewart]</li></ol></ol><div>&nbsp;</div><div><div><h2>Cross-cutting concerns:</h2></div><div><ol><li>Provenance (the need to optionally use signing to validate who said what)</li><li>Handling staleness of data</li></ol></div></div><div>&nbsp;</div></div><div><h2>Themes:</h2></div><div>&nbsp;</div><div>Looking at these Use Cases, there are some underlying themes:</div><div><ol><li>Root of data (closer to upstream the better)</li><li>Subsetting of copyrightable things (and their SPDX data) (<strong>Note</strong>: Subsets of copyrightable things are usually also copyrightable things)</li><li>Aggregation of copyrightable things (and their SPDX data) (<strong>Note</strong>: Aggregations of copyrightable things are usually also copyrightable things).</li></ol></div><div>&nbsp;</div><div>&nbsp;</div><p>&nbsp;</p>
+
<p>We have several sources to begin pulling for SPDX Use Cases:</p><ol><li>The Pad from earlier conversations collected at <a href="http://spdx.org/wiki/use-cases-collected-20-discussion">Use Cases For SPDX 2.0 Discussion</a></li><li>The old <a href="https://fossbazaar.org/wiki/spdx-use-case-1">SPDX 1.0 Use Cases</a>&nbsp;as well as the <a href="http://spdx.org/system/files/ecosystem.jpg">SDPX 1.0 Use Case Picture</a>.</li></ol><div>&nbsp;</div><div>I'd like to propose that we flesh out use cases here by having a brief summary listed here as a link to a more detailed child page. &nbsp; Note, these use cases should be *<strong>doable</strong>* but in general not *<strong>required</strong>*. &nbsp;Any item listed here that is not a link, should have a child page created for it.</div><div>&nbsp;</div><div><ol><li><a href="http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data">Upstream maintainer providing SPDX data</a></li><li>Upstream maintainer consuming another project</li><ol><li>Upstream maintainer including another project by including source</li><li>Upstream maintainer including another project by reference (think maven, possibly linking cases)</li><ol><li>by static reference (the referenced library is included with a redistribution)</li><li>by dynamic reference (express runtime dependency on the external library, but not redistributing it)</li></ol><li>Upstream maintainer pulling individual files out of another project (subsetting)</li></ol><li>Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data</li><ol><li>Intermediate packager subsetting upstream package</li></ol><li>Yocto [Jack Manbeck]</li><li>Aggregator aggregating many 'copyrightable items' for redistribution</li><ol><li>Linux Distros</li><li>Embedded Images</li><li>SDKs</li><li>Reference implementations</li><li>Eclipse/OSGI distributions</li><li>Application which ships with documentation + &nbsp;media + software [Jack Manbeck]</li></ol><li>Aggregators aggregating other aggergations for redistribution</li><li>Asserting corrections to SPDX data provided by others further upstream</li><li>Committers providing, or assenting to SPDX data</li><li>Committers annotating source files with SPDX info</li><li>Consumers receiving SPDX data</li><li>Signoff/multiple signoff on SPDX data</li><ol><li>Contracts with multiple parties requiring signoff by all [Kate Stewart]</li></ol><li>Auditor scenario: given big pile of 'copyrightable items', creating Bill of Materials [Peter Williams]</li><li>Sanity-checking Bill of Material</li><li>&nbsp;- validate that it represents a&nbsp;</li></ol><div>&nbsp;</div><div><div><h2>Cross-cutting concerns:</h2></div><div><ol><li>Provenance (the need to optionally use signing to validate who said what)</li><li>Handling staleness of data</li></ol></div></div><div>&nbsp;</div></div><div><h2>Themes:</h2></div><div>&nbsp;</div><div>Looking at these Use Cases, there are some underlying themes:</div><div><ol><li>Root of data (closer to upstream the better)</li><li>Subsetting of copyrightable things (and their SPDX data) (<strong>Note</strong>: Subsets of copyrightable things are usually also copyrightable things)</li><li>Aggregation of copyrightable things (and their SPDX data) (<strong>Note</strong>: Aggregations of copyrightable things are usually also copyrightable things).</li></ol></div><div>&nbsp;</div><div>&nbsp;</div><p>&nbsp;</p>

Revision as of 18:43, 27 March 2012

We have several sources to begin pulling for SPDX Use Cases:

  1. The Pad from earlier conversations collected at <a href="http://spdx.org/wiki/use-cases-collected-20-discussion">Use Cases For SPDX 2.0 Discussion</a>
  2. The old <a href="https://fossbazaar.org/wiki/spdx-use-case-1">SPDX 1.0 Use Cases</a> as well as the <a href="http://spdx.org/system/files/ecosystem.jpg">SDPX 1.0 Use Case Picture</a>.
 
I'd like to propose that we flesh out use cases here by having a brief summary listed here as a link to a more detailed child page.   Note, these use cases should be *doable* but in general not *required*.  Any item listed here that is not a link, should have a child page created for it.
 
  1. <a href="http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data">Upstream maintainer providing SPDX data</a>
  2. Upstream maintainer consuming another project
    1. Upstream maintainer including another project by including source
    2. Upstream maintainer including another project by reference (think maven, possibly linking cases)
      1. by static reference (the referenced library is included with a redistribution)
      2. by dynamic reference (express runtime dependency on the external library, but not redistributing it)
    3. Upstream maintainer pulling individual files out of another project (subsetting)
  3. Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
    1. Intermediate packager subsetting upstream package
  4. Yocto [Jack Manbeck]
  5. Aggregator aggregating many 'copyrightable items' for redistribution
    1. Linux Distros
    2. Embedded Images
    3. SDKs
    4. Reference implementations
    5. Eclipse/OSGI distributions
    6. Application which ships with documentation +  media + software [Jack Manbeck]
  6. Aggregators aggregating other aggergations for redistribution
  7. Asserting corrections to SPDX data provided by others further upstream
  8. Committers providing, or assenting to SPDX data
  9. Committers annotating source files with SPDX info
  10. Consumers receiving SPDX data
  11. Signoff/multiple signoff on SPDX data
    1. Contracts with multiple parties requiring signoff by all [Kate Stewart]
  12. Auditor scenario: given big pile of 'copyrightable items', creating Bill of Materials [Peter Williams]
  13. Sanity-checking Bill of Material
  14.  - validate that it represents a 
 

Cross-cutting concerns:

  1. Provenance (the need to optionally use signing to validate who said what)
  2. Handling staleness of data
 

Themes:

 
Looking at these Use Cases, there are some underlying themes:
  1. Root of data (closer to upstream the better)
  2. Subsetting of copyrightable things (and their SPDX data) (Note: Subsets of copyrightable things are usually also copyrightable things)
  3. Aggregation of copyrightable things (and their SPDX data) (Note: Aggregations of copyrightable things are usually also copyrightable things).
 
 

 

Retrieved from "https://wiki.spdx.org/index.php?title=Technical_Team/Use_Cases/2.0&oldid=1505"