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
 
(95 intermediate revisions by 8 users not shown)
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="http://spdx.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>Code commits (original work intended for the project)</li><ol><li><a href="http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed">Committer provides SPDX data</a></li><li><a href="http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project">Contributor makes commit &nbsp;subject to existing SPDX data of project</a></li><li>Contributor makes commit subject to existing SPDX data of a dual licensed project and selects one license</li></ol><li><a href="http://spdx.org/wiki/committer-annotates-source-files-spdx-data">Committer annotates source files with SPDX data</a></li><li>Patches (original work intended for the project)</li><ol><li><a href="http://spdx.org/wiki/patch-provider-provides-spdx-data-patch">Patch provider provides SPDX data for the patch</a></li><li><a href="http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied">Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied</a></li><li>Patch provider provides patch subject to existing SPDX data of project</li></ol><li>Patch provider provides a patch that modifies existing SPDX data of project</li><li><a href="http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data">Upstream maintainer providing SPDX data</a></li><ol><li><a href="http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive">Upstream maintainer providing SPDX data in source archive</a></li><li><a href="http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm">Upstream maintainer providing SPDX data in SCM</a></li><li>Upstream maintainer providing SPDX data at a URL</li><li>Upstream maintainer preparing release artifacts (including SPDX data).</li></ol><li>Project maintainer incorporates another project</li><ol><li>Project maintainer incorporates another project by including source</li><li>Project maintainer incorporates another project by including binary</li><li>Project maintainer pulling individual files out of another project (subsetting)</li></ol><li>Project maintainer incorporates another copyrightable artifact 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><li>Maven case</li></ol><li>Unaffiliated third party provides SPDX data for a project</li><li>Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data</li><ol><li>Intermediate packager builds source package from upstream source</li><ol><li><a href="http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data">Intermediate packager builds source package from upstream source&nbsp;that provides SPDX data</a></li><li>Intermediate packager builds source package from upstream source that does not provide SPDX data</li></ol><li>Intermediate packager builds binary package from upstream source</li><ol><li><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></li><li>Intermediate packager builds binary package from upstream source that does not provides SPDX data</li></ol><li>Intermediate packager adds patches to upstream source&nbsp;</li><ol><li><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></li><li>Intermediate packager adds patches to upstream source that does not provide SPDX data</li></ol><li>Intermediate packager adds someone else's patches to upstream source</li><ol><li><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></li><li>Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data</li></ol><li>Intermediate packager subsetting upstream source</li><ol><li><a href="http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data">Intermediate packager subsetting upstream source that provides SPDX data</a></li><li>Intermediate packager subsetting upstream source that does not provide SPDX data</li></ol><li>Intermediate packager chooses to distribute one of multiple available under licenses provided for by upstream (check with legal team)</li></ol><li>Build systems (build systems want to pass on SPDX data for the thing they are building)</li><ol><li>Yocto [Jack Manbeck]</li><ol><li>How does SPDX work in an environment where the sources aren't there, but are pulled from git or a mirror and patched.</li></ol><li>Maven [ Brian Fox ]</li><ol><li>Rolling into release artifacts things only referenced in the POM file</li><li>Shading (subsetting) portions of a transitive dependency for inclusion in your artifact</li></ol><li>Continuous integration around SPDX files (fixing SPDX files for commits coming in etc).</li></ol><li>Aggregator aggregating many 'copyrightable items' for redistribution</li><ol><li>Linux Distros [Kate Stewart]</li><li>Embedded Images (e.g. router images, switch images)</li><li>SDKs [Jack Manbeck]</li><li><a href="http://spdx.org/wiki/spdx-20-usecase-reference-implementations">Reference implementations </a>[Jack Manbeck]</li><li>Eclipse/OSGI distributions</li><li><a href="http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software">Application which ships with documentation + &nbsp;media + software</a> [Jack Manbeck]</li><li><a title="Use case details" href="http://spdx.org/wiki/application-which-ships-contrib-libraries">Application which ships with a contrib libraries</a>&nbsp;[Gary O'Neall]</li><li><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]</li><li>Receiving what appears to be commercial software but that commercial software contains Open Source</li><li>Receiving what appears to be opensource software but that opensource software contains commercial software</li><li>Subsetting out only the shippable bits of stuff coming from an SDK</li></ol><li>Tool used to produce software infecting distribution license of the software itself [Kevin Fleming]</li><li>Aggregators aggregating other aggregations for redistribution</li><li>I just made a binary out of some source</li><ol><li>SPDX data indicating subset of the source that made it into a particular binary or binary package</li></ol><li>Asserting corrections to SPDX data provided by others further upstream</li><li>Consumers receiving SPDX data</li><ol><li>Procurement needs to view it and review it</li><li>Legal department needs to review</li><li>Comply with licensing when there are multiple rights holders each with licensing use under a different license</li><li>Bradley want to extract all rights holders for a particular file</li><li>Multiple SPDX files you need to reconcile</li><li>Recognizing the same SPDX data for the same code coming from multiple supply chain paths</li><li>Incomplete SPDX data you may need to complete</li><li>Flagging potential issues revealed by the SPDX</li><ol><li>License conflicts</li><li>Listing out obligations</li></ol></ol><li>Consuming code snippets (God help us all) (subfile pieces of code not originally intended for the project) [Gary O'Neall]</li><ol><li>Make sure that the license and copyright information for a snippet is reflected in the SPDX data for the file</li><li>Track differently licensed snippets explicitely</li><li>Handle the case where code is copied and pasted through online forums etc.</li></ol><li>Signoff/multiple signoff on SPDX data</li><ol><li>Contracts with multiple parties requiring signoff by all [Kate Stewart]</li><li>Signing off on only a subset of the SPDX data (of an SPDX document in progress?)</li></ol><li>Auditor scenario: given big pile of 'copyrightable items', creating Bill of Materials [Peter Williams]</li><ol><li>Acceptable usage communicated by auditor [Peter Williams]</li><li>Intended usage communicated by the auditee [Bill Schineller]</li><li>Did the code that I shipped (the binaries) match the copyrightable items.</li><li><a href="http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component">Collecting enough information to allow auditor to make recommendations to remove or not a component</a></li></ol><li>Intermediate packager reviews SPDX data provided by upstream.</li><li>Sanity-checking Bill of Material</li><ol><li>outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]</li><ol><li>Check to see if the SPDX data provided matches the files provided [Kirsten Newcomer]</li><li>Check to see if the SPDX file is internally consistent (do I have a license refs to match licenses)</li></ol><li>inbound: &nbsp;validate that SPDX goes hand in hand with what's being brought in&nbsp;[Kirsten Newcomer]</li><ol><li>Chcek to see if the SPDX data matches the files you are shipping [Kirsten Newcomer]</li><li>Check to see if the SPDX file is internally consistent (do I have a license refs to match licenses)</li></ol><li>SPDX lint</li></ol><li>Java complications [Richard Fontana]</li><ol><li>What to do about installers that download JDK directly from sun.</li></ol><li>Tooling to assist with copyright registration for changes between versions</li><li>Conveying Encryption content (Export Control implications) of a package/file in a package [someone at collab summit]</li><li>Conveying Security Vulnerability information [Jianshen O.- Huawei]</li><li>Linking</li><ol><li>Debian has an interest in only building things that are linking license compatible</li><ol><li>If a tool is consuming SPDX data to interact with heuristics.</li></ol></ol><li>Migrating from one version of the SPDX spec to another (moving a file from SPDX 1.0 to 2.0 for example)</li><li>Extensions:</li><ol><li>Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know [Peter Williams]</li><li>Experimental improvements for new flavors data in SDPX files w/o breaking consumers that are not in the know. [Peter Williams]</li><li>License list extensions, how do you handle folks who have more licenses than SPDX [Peter Williams]</li><li>Decorating an already produces and signed SPDX dataset with extension data [Bill Schineller]</li></ol><li>SPDX-Lite:</li><ol><li>Allow a low investment SPDX producer to produce valid SPDX data</li><li>Produce a valid SPDX dataset even if data is missing for some data we would like to</li></ol><li>Equivalence classes of binaries and tracking back to the same source and source SPDX data.</li><ol><li>Consider what to do about license metafiles</li><li>COPYING files</li><li>LICENSE.* files</li><li>README.*</li><li>Think about how to handle NOTICE files and Apache</li></ol><li>Helping to meet the obligations of the licenses</li><ol><li>How to capture attribution information for binaries</li><li>Help with redistribution obligations</li></ol><li>Downstream consumers contributing patches to SPDX data to upstream.</li><li>Look at a 'pingback' (URL string similar for blogs)kind of mechanism for original providers of SPDX (to allow them to figure out where it's used) [Andrew Hsu]</li><li>Cloud</li><ol><li>Materializing a VM and making sure it's OK from a licensing mechanism</li><li>SugarCRM case, obligation by virtue of using web service interface</li></ol><li>How are we going to handle Public Domain.</li><li>Allow the NDA status of an SPDX document to be communicated in a machine readable way (not just a comment) for organizations that don't want the SPDX document to be publicly released [Mark Baushke from Juniper]</li><li>Recording free-form tribal knowledge about a file which is not otherwise visible in the text of the file itself (e.g. commit history from git repo, origin information such as scanning against a knowledge base of open source could provide) [Mark Gisi]</li><li>Recording per ExtractedLicenseText a comment detailing exactly which pattern matching technique / string found that Extracted License Text (so that SPDX file doesn't need to repeat in every matched File instance) [D. M. German]</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>Trust</li><li>Handling staleness of data</li><li>Composite licensing</li><li>Ease of sharing information</li><ol><li>Collecting tribal knowledge along the way&nbsp;</li></ol><li>Guarding against file bloat</li><li>Simple simple simple</li><li>Clarity</li><li>Automation/toolifiability</li><li>Regionality</li></ol></div></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>
+
We have several sources to begin pulling for SPDX Use Cases:
 +
 
 +
# The Pad from earlier conversations collected at [[Technical_Team/Old/Use_Cases_Collected_during_1.x_timeframe|Use Cases For SPDX 2.0 Discussion]]
 +
# The old [[Technical_Team/Old/Sandbox_for_Sharing_Examples/SPDX_Use_Case_1|SPDX 1.0 Use Cases]] as well as the [[:File:ecosystem.jpg|SDPX 1.0 Use Case Picture]].
 +
 
 +
== Use Cases ==
 +
 
 +
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.
 +
 
 +
# Code commits (original work intended for the project)
 +
## [[Technical_Team/Use_Cases/2.0/Committers_provides_SPDX_data_for_a_code_being_committed|Committer provides SPDX data]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Contributor_makes_commit_subject_to_existing_SPDX_data_of_project|Contributor makes commit subject to existing SPDX data of project]] [OK]
 +
# [[Technical_Team/Use_Cases/2.0/Committer_annotates_source_files_with_SPDX_data|Committer annotates source files with SPDX data]] [OK]
 +
# Patches (original work intended for the project)
 +
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch|Patch provider provides SPDX data for the patch]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch_indicating_it_is_licensed_however_the_hell_its_applied|Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_patch_subject_to_existing_SPDX_data_of_project|Patch provider provides patch subject to existing SPDX data of project]] [OK]
 +
# Patch provider provides a patch that modifies existing SPDX data of project
 +
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_SPDX_data_to_an_upstream_that_doesnt_have_it|Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Downstream_consumers_contributing_patches_to_provide_corrections_to_SPDX_data_for_an_upstream_that_does_have_it|Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.]] [OK]
 +
# [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data|Upstream maintainer providing SPDX data]]
 +
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_source_archive|Upstream maintainer providing SPDX data in source archive]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_SCM|Upstream maintainer providing SPDX data in SCM]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_at_a_URL|Upstream maintainer providing SPDX data at a URL]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_preparing_release_artifacts_(including_SPDX_data)|Upstream maintainer preparing release artifacts (including SPDX data).]] [OK]
 +
# Project maintainer incorporates another project
 +
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_source|Project maintainer incorporates another project by including source]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_binary|Project maintainer incorporates another project by including binary]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Project_maintainer_pulling_individual_files_out_of_another_project_(subsetting)|Project maintainer pulling individual files out of another project (subsetting)]] [OK]
 +
# Ease adoption
 +
## [[Technical_Team/Use_Cases/2.0/Low_cost_SPDX_file|Allow a low investment SPDX producer to produce valid SPDX data]] [OK-fathomed but not Approved for Implementation]
 +
## [[Technical_Team/Use_Cases/2.0/Producing_valid_SPDX_files_in_the_face_of_missing_data|Produce a valid SPDX dataset even if some data is missing]] [OK]
 +
# Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
 +
## Intermediate packager builds source package from upstream source
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_source_package_from_upstream_source_that_provides_SPDX_data|Intermediate packager builds source package from upstream source that provides SPDX data]] [OK]
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_source_package_from_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager builds source package from upstream source that does not provide SPDX data]] [OK]
 +
## Intermediate packager builds binary package from upstream source
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_binary_package_from_upstream_source_that_provides_SPDX_data|Intermediate packager builds binary package from upstream source that provides SPDX data]] [OK]
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_builds_binary_package_from_upstream_source_that_does_not_provides_SPDX_data|Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]]
 +
## Intermediate packager adds patches to upstream source
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_patches_to_upstream_source_that_provides_SPDX_data|Intermediate packager adds patches to upstream source that provides SPDX data]] [OK]
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_patches_to_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]]
 +
## Intermediate packager adds someone else's patches to upstream source
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_someone_elses_patches_to_upstream_source_that_provides_SPDX_data|Intermediate packager adds someone else's patches to upstream source that provides SPDX data]] [OK]
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_adds_someone_elses_patches_to_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data]] [OK]
 +
## Intermediate packager subsetting upstream source
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_subsetting_upstream_source_that_provides_SPDX_data|Intermediate packager subsetting upstream source that provides SPDX data]] [OK]
 +
### [[Technical_Team/Use_Cases/2.0/Intermediate_packager_subsetting_upstream_source_that_does_not_provide_SPDX_data|Intermediate packager subsetting upstream source that does not provide SPDX data [OK]]
 +
# Build systems (build systems want to pass on SPDX data for the thing they are building)
 +
## [[Technical_Team/Use_Cases/2.0/Build_System_Yocto|Yocto]] [OK]
 +
## Linking
 +
### [[Technical_Team/Use_Cases/2.0/Debian_has_an_interest_in_only_building_things_that_are_linking_license_compatible|Debian has an interest in only building things that are linking license compatible]] [OK]
 +
## I just made a binary out of some source
 +
### [[Technical_Team/Use_Cases/2.0/SPDX_data_indicating_subset_of_the_source_that_made_it_into_a_particular_binary_or_binary_package|SPDX data indicating subset of the source that made it into a particular binary or binary package]] [OK]
 +
# Aggregator aggregating many 'copyrightable items' for redistribution
 +
## [[Technical_Team/Use_Cases/2.0/Linux_Distros|Linux Distros]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Embedded_Images_(e.g._router_images,_switch_images)|Embedded Images (e.g. router images, switch images)]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Reference_Implementations|Reference implementations]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_documentation_and_media_and_software|Application which ships with documentation + media + software]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_a_contrib_libraries|Application which ships with a contrib libraries]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_development_tools|Application which ships with development tools]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Subsetting_out_only_the_shippable_bits_of_stuff_coming_from_an_SDK|Subsetting out only the shippable bits of stuff coming from an SDK]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Aggregators_aggregating_other_aggregations_for_redistribution|Aggregators aggregating other aggregations for redistribution]] [OK]
 +
# Consumers receiving SPDX data
 +
## [[Technical_Team/Use_Cases/2.0/Provide_sufficient_data_to_allow_consumer_to_comply_with_licenses_on_redistribution|Provide sufficient data to allow consumer to comply with licenses on redistribution]] Alcatel-Lucent requirements attached [OK]
 +
# [[Technical_Team/Use_Cases/2.0/Consuming_code_snippets|Consuming code snippets]] (God help us all) (subfile pieces of code not originally intended for the project) [OK]
 +
# Signoff/multiple signoff on SPDX data
 +
## [[Technical_Team/Use_Cases/2.0/Contracts_with_multiple_parties_requiring_signoff_by_all|Contracts with multiple parties requiring signoff by all]] [MORE INFO REQUESTED Kate Stewart]
 +
# Third party does licensing analysis
 +
## [[Technical_Team/Use_Cases/2.0/Third_party_produces_bill_of_materials_for_software_package|Third party generates license analysis]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Collecting_enough_information_to_allow_auditor_to_make_recommendations_to_remove_or_not_a_component|Collecting enough information to allow auditor to make recommendations to remove or not a component]] [OK]
 +
# Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed
 +
## [[Technical_Team/Use_Cases/2.0/Backtrack_from_binary_to_source_files|Backtrack from compiled/binary file to constituent files]] [MORE STUDY NEEDED]
 +
## outbound: validate that SPDX goes hand in hand with what's being shipped (Kirsten Newcomer)
 +
### [[Technical_Team/Use_Cases/2.0/Check_to_see_if_the_SPDX_data_provided_matches_the_files_provided_and_is_trustworthy_and_most_current_for_package|Check to see if the SPDX data provided matches the files provided]] [OK larger scope]
 +
# Extensions:
 +
## [[Technical_Team/Use_Cases/2.0/Communicate_data_beyond_what_is_described_in_spec|Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/License_list_extension|License list extensions, how do you handle folks who have more licenses than SPDX]] [OK]
 +
## [[Technical_Team/Use_Cases/2.0/Decorating_an_already_produces_and_signed_SPDX_dataset_with_extension_data|Decorating an already produces and signed SPDX dataset with extension data]] [OK]
 +
# Other arising during vetting...
 +
## Given 2 SPDX files about the same codebase from the same source, be able to tell which is the later rev / more current and correct one. [DETAIL PAGE NEEDS TO BE WRITTEN - seems to be asking for something more robust than just a later date on one SPDX file vs. the other, rather 'signing with revisioning, where the later revision may reference the earlier and declare it is an amendment to the earlier one]
 +
 
 +
== Cross-cutting concerns ==
 +
 
 +
# Provenance (the need to optionally use signing to validate who said what)
 +
# Trust
 +
# Handling staleness of data
 +
# Composite licensing
 +
# Ease of sharing information
 +
## Collecting tribal knowledge along the way
 +
# Guarding against file bloat
 +
# Simple simple simple
 +
# SPDX-Lite:  here's interest in something SPDX-Lite like https://bugzilla.yoctoproject.org/show_bug.cgi?id=4516 
 +
# Clarity
 +
# Automation/toolifiability
 +
# Regionality
 +
 
 +
==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).
 +
 
 +
[[Category:Technical]]

Latest revision as of 18:17, 21 May 2013

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

  1. The Pad from earlier conversations collected at Use Cases For SPDX 2.0 Discussion
  2. The old SPDX 1.0 Use Cases as well as the SDPX 1.0 Use Case Picture.

Use Cases

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 (original work intended for the project)
    1. Committer provides SPDX data [OK]
    2. Contributor makes commit subject to existing SPDX data of project [OK]
  2. Committer annotates source files with SPDX data [OK]
  3. Patches (original work intended for the project)
    1. Patch provider provides SPDX data for the patch [OK]
    2. Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied [OK]
    3. Patch provider provides patch subject to existing SPDX data of project [OK]
  4. Patch provider provides a patch that modifies existing SPDX data of project
    1. Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it. [OK]
    2. Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it. [OK]
  5. Upstream maintainer providing SPDX data
    1. Upstream maintainer providing SPDX data in source archive [OK]
    2. Upstream maintainer providing SPDX data in SCM [OK]
    3. Upstream maintainer providing SPDX data at a URL [OK]
    4. Upstream maintainer preparing release artifacts (including SPDX data). [OK]
  6. Project maintainer incorporates another project
    1. Project maintainer incorporates another project by including source [OK]
    2. Project maintainer incorporates another project by including binary [OK]
    3. Project maintainer pulling individual files out of another project (subsetting) [OK]
  7. Ease adoption
    1. Allow a low investment SPDX producer to produce valid SPDX data [OK-fathomed but not Approved for Implementation]
    2. Produce a valid SPDX dataset even if some data is missing [OK]
  8. Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data
    1. Intermediate packager builds source package from upstream source
      1. Intermediate packager builds source package from upstream source that provides SPDX data [OK]
      2. Intermediate packager builds source package from upstream source that does not provide SPDX data [OK]
    2. Intermediate packager builds binary package from upstream source
      1. Intermediate packager builds binary package from upstream source that provides SPDX data [OK]
      2. Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK
    3. Intermediate packager adds patches to upstream source
      1. Intermediate packager adds patches to upstream source that provides SPDX data [OK]
      2. Intermediate packager adds patches to upstream source that does not provide SPDX data [OK
    4. Intermediate packager adds someone else's patches to upstream source
      1. Intermediate packager adds someone else's patches to upstream source that provides SPDX data [OK]
      2. Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data [OK]
    5. Intermediate packager subsetting upstream source
      1. Intermediate packager subsetting upstream source that provides SPDX data [OK]
      2. Intermediate packager subsetting upstream source that does not provide SPDX data [OK
  9. Build systems (build systems want to pass on SPDX data for the thing they are building)
    1. Yocto [OK]
    2. Linking
      1. Debian has an interest in only building things that are linking license compatible [OK]
    3. 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 [OK]
  10. Aggregator aggregating many 'copyrightable items' for redistribution
    1. Linux Distros [OK]
    2. Embedded Images (e.g. router images, switch images) [OK]
    3. Reference implementations [OK]
    4. Application which ships with documentation + media + software [OK]
    5. Application which ships with a contrib libraries [OK]
    6. Application which ships with development tools [OK]
    7. Subsetting out only the shippable bits of stuff coming from an SDK [OK]
    8. Aggregators aggregating other aggregations for redistribution [OK]
  11. Consumers receiving SPDX data
    1. Provide sufficient data to allow consumer to comply with licenses on redistribution Alcatel-Lucent requirements attached [OK]
  12. Consuming code snippets (God help us all) (subfile pieces of code not originally intended for the project) [OK]
  13. Signoff/multiple signoff on SPDX data
    1. Contracts with multiple parties requiring signoff by all [MORE INFO REQUESTED Kate Stewart]
  14. Third party does licensing analysis
    1. Third party generates license analysis [OK]
    2. Collecting enough information to allow auditor to make recommendations to remove or not a component [OK]
  15. Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed
    1. Backtrack from compiled/binary file to constituent files [MORE STUDY NEEDED]
    2. outbound: validate that SPDX goes hand in hand with what's being shipped (Kirsten Newcomer)
      1. Check to see if the SPDX data provided matches the files provided [OK larger scope]
  16. Extensions:
    1. Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know [OK]
    2. License list extensions, how do you handle folks who have more licenses than SPDX [OK]
    3. Decorating an already produces and signed SPDX dataset with extension data [OK]
  17. Other arising during vetting...
    1. Given 2 SPDX files about the same codebase from the same source, be able to tell which is the later rev / more current and correct one. [DETAIL PAGE NEEDS TO BE WRITTEN - seems to be asking for something more robust than just a later date on one SPDX file vs. the other, rather 'signing with revisioning, where the later revision may reference the earlier and declare it is an amendment to the earlier one]

Cross-cutting concerns

  1. Provenance (the need to optionally use signing to validate who said what)
  2. Trust
  3. Handling staleness of data
  4. Composite licensing
  5. Ease of sharing information
    1. Collecting tribal knowledge along the way
  6. Guarding against file bloat
  7. Simple simple simple
  8. SPDX-Lite: here's interest in something SPDX-Lite like https://bugzilla.yoctoproject.org/show_bug.cgi?id=4516
  9. Clarity
  10. Automation/toolifiability
  11. Regionality

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