Technical Team/Use Cases/2.0

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. Code commits
1. <a href="http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed">Committer provides SPDX data</a>
2. <a href="http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project">Contributor makes commit  subject to existing SPDX data of project</a>
3. Contributor makes commit subject to existing SPDX data of a dual licensed project and selects one license
4. Committer annotates source files with SPDX data
2. Patches
1. Patch provider provides SPDX data for the patch
2. Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied
3. Patch provider provides patch subject to existing SPDX data of project
4. Patch provider provides a patch that modifies existing SPDX data of project
3. <a href="http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data">Upstream maintainer providing SPDX data</a>
1. <a href="http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive">Upstream maintainer providing SPDX data in source archive</a>
2. <a href="http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm">Upstream maintainer providing SPDX data in SCM</a>
3. Upstream maintainer providing SPDX data at a URL
4. Project maintainer incorporates another project
1. Project maintainer incorporates another project by including source
2. Project maintainer incorporates another project by including binary
3. Project maintainer incorporates another copyrightable artifact 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. Maven case
4. Project maintainer pulling individual files out of another project (subsetting)
5. Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
1. Intermediate packager builds source package from upstream source
1. <a href="http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data">Intermediate packager builds source package from upstream source that provides SPDX data</a>
2. Intermediate packager builds source package from upstream source that does not provide SPDX data
2. Intermediate packager builds binary package from upstream source
1. <a href="http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data">Intermediate packager builds binary package from upstream source that provides SPDX data</a>
2. Intermediate packager builds binary package from upstream source that does not provides SPDX data
3. Intermediate packager adds patches to upstream source 
1. <a href="http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data">Intermediate packager adds patches to upstream source that provides SPDX data</a>
2. Intermediate packager adds patches to upstream source that does not provide SPDX data
4. Intermediate packager adds someone else's patches to upstream source
1. <a href="http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data">Intermediate packager adds someone else's patches to upstream source that provides SPDX data</a>
2. Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data
5. Intermediate packager subsetting upstream source
1. <a href="http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data">Intermediate packager subsetting upstream source that provides SPDX data</a>
2. Intermediate packager subsetting upstream source that does not provide SPDX data
6. Intermediate packager chooses to distribute one of multiple available under licenses provided for by upstream (check with legal team)
6. Build systems (build systems want to pass on SPDX data for the thing they are building)
1. Yocto [Jack Manbeck]
2. Maven
7. Aggregator aggregating many 'copyrightable items' for redistribution
1. Linux Distros [Kate Stewart]
2. Embedded Images
3. SDKs [Jack Manbeck]
4. <a href="http://spdx.org/wiki/spdx-20-usecase-reference-implementations">Reference implementations </a>[Jack Manbeck]
5. Eclipse/OSGI distributions
6. <a href="http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software">Application which ships with documentation +  media + software</a> [Jack Manbeck]
7. <a title="Use case details" href="http://spdx.org/wiki/application-which-ships-contrib-libraries">Application which ships with a contrib libraries</a> [Gary O'Neall]
8. <a title="Use case details" href="http://spdx.org/wiki/application-which-ships-development-tools">Application which ships with development tools</a> [Gary O'Neall]
8. Aggregators aggregating other aggregations for redistribution
9. I just made a binary out of some source
1. SPDX data indicating subset of the source that made it into a particular binary or binary package
10. Asserting corrections to SPDX data provided by others further upstream
11. Consumers receiving SPDX data
1. Procurement needs to view it and review it
2. Legal department needs to review
12. Consuming code snippets (God help us all)
13. Signoff/multiple signoff on SPDX data
1. Contracts with multiple parties requiring signoff by all [Kate Stewart]
14. Auditor scenario: given big pile of 'copyrightable items', creating Bill of Materials [Peter Williams]
15. Sanity-checking Bill of Material
1. outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]
2. inbound:  validate that SPDX goes hand in hand with what's being brought in 
16. Java complications [Richard Fontana]

 

Cross-cutting concerns:

1. Provenance (the need to optionally use signing to validate who said what)
2. Handling staleness of data
3. Expressing applicable licensing as a function of Usage [Bill Schineller]
4. Permissive licensed thing becomes restrictive as function of packaging (e.g. BSD file included in GPL becomes GPL)

 

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).