Technical Team/Use Cases/2.0

2012-04-17T17:50:53Z

Eaw:

<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> 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>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  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><li><a href="http://spdx.org/wiki/committer-annotates-source-files-spdx-data">Committer annotates source files with SPDX data</a></li></ol><li>Patches (original work intended for the project)</li><ol><li>Patch provider provides SPDX data for the patch</li><li>Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied</li><li>Patch provider provides patch subject to existing SPDX data of project</li><li>Patch provider provides a patch that modifies existing SPDX data of project</li></ol><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>Unaffiliated third party provides SPDX data for a project</li><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 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>Project 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 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 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 </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><li>Intermediate packager reviews SPDX data provided by upstream.</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 +  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> [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>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:  validate that SPDX goes hand in hand with what's being brought in [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> </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 </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> </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>

Technical Team/Use Cases/2.0/Committer annotates source files with SPDX data

2012-04-17T17:50:18Z

Eaw:

<ol style="color: #4d4d4d; font-family: Arial, Helvetica, sans-serif; font-size: 13px;"><li><strong>Title:</strong> Committer annotates source files with SPDX data</li><li><strong>Primary Actor:</strong> Committer</li><li><strong>Goal in Context:</strong> To indicate SPDX data for the file in the source code file.</li><li><strong>Preconditions:</strong> <ol><li>Committer has decided the license for the file they are committing</li></ol></li><li><strong>Stakeholders and Interests:</strong> <ol><li><strong>Committer:</strong> <ol><li>To communicate the license information for the file in line with the file.</li></ol></li><li><strong>Upstream maintainers: </strong><ol><li>To be able to have the source code be self documenting in a machine and human readable manner with respect to license information.</li><li>To communicate the licensing information for their copyrightable artifacts.  </li><li>To have their licenses respected</li></ol></li><li><strong>Consumers of upstream source:</strong><ol><li>To receive accurate and clear information of licensing of upstream source</li><li>To be able to comply easily with licenses for upstream source</li><li>To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.</li></ol></li></ol></li><li><strong>Main Success Senario:</strong> Source code files contain complete accurate SPDX data sufficient to communicate their licensing information in a way that is both human and machine readable.</li><li><strong>Failed End Condition:</strong> Source code files lack complete accurate SPDX data.</li><li><strong>Trigger:</strong><ol><li>Commit of code to an upstream project.</li></ol></li><li><strong>Notes: </strong>There may be sub-use cases here around the distinction between original authorship of a file and capturing in SPDX existing information about the file, either from existing file headers or from commit logs.</li></ol>