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
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> as well as the <a href="http://spdx.org/system/files/ecosystem.jpg">SDPX 1.0 Use Case Picture</a>.</li></ol><div> </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. Note, these use cases should be *<strong>doable</strong>* but in general not *<strong>required</strong>*. Any item listed here that is not a link, should have a child page created for it.</div><div> </div><div><ol><li>Upstream maintainer providing SPDX data</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><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>Aggregator aggregating many packages for redistribution</li><ol><li>Linux Distros</li><li>Embedded Images</li><li>SDKs</li><li>Reference implementations</li><li>Eclipse/OSGI distributions</li></ol><li>Aggergators aggregating other aggrgations 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>Consumers receiving SPDX data</li></ol><div> </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></ol></div></div><div> </div></div><div><h2>Themes:</h2></div><div> </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> </div><div> </div><p> </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> as well as the <a href="http://spdx.org/system/files/ecosystem.jpg">SDPX 1.0 Use Case Picture</a>.</li></ol><div> </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. Note, these use cases should be *<strong>doable</strong>* but in general not *<strong>required</strong>*. Any item listed here that is not a link, should have a child page created for it.</div><div> </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><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>Aggregator aggregating many packages for redistribution</li><ol><li>Linux Distros</li><li>Embedded Images</li><li>SDKs</li><li>Reference implementations</li><li>Eclipse/OSGI distributions</li></ol><li>Aggergators aggregating other aggrgations 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>Consumers receiving SPDX data</li></ol><div> </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></ol></div></div><div> </div></div><div><h2>Themes:</h2></div><div> </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> </div><div> </div><p> </p> |
Revision as of 17:52, 27 March 2012
We have several sources to begin pulling for SPDX Use Cases:
- 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>
- 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.
- <a href="http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data">Upstream maintainer providing SPDX data</a>
- Upstream maintainer consuming another project
- Upstream maintainer including another project by including source
- Upstream maintainer including another project by reference (think maven, possibly linking cases)
- Upstream maintainer pulling individual files out of another project (subsetting)
- Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
- Intermediate packager subsetting upstream package
- Aggregator aggregating many packages for redistribution
- Linux Distros
- Embedded Images
- SDKs
- Reference implementations
- Eclipse/OSGI distributions
- Aggergators aggregating other aggrgations for redistribution
- Asserting corrections to SPDX data provided by others further upstream
- Committers providing, or assenting to SPDX data
- Consumers receiving SPDX data
Cross-cutting concerns:
- Provenance (the need to optionally use signing to validate who said what)
Themes:
Looking at these Use Cases, there are some underlying themes:
- Root of data (closer to upstream the better)
- Subsetting of copyrightable things (and their SPDX data) (Note: Subsets of copyrightable things are usually also copyrightable things)
- Aggregation of copyrightable things (and their SPDX data) (Note: Aggregations of copyrightable things are usually also copyrightable things).