https://wiki.spdx.org/api.php?action=feedcontributions&feedformat=atom&user=Bschineller 2026-05-07T13:10:58Z User contributions MediaWiki 1.23.13 https://wiki.spdx.org/view/Technical_Team/Proposals 2015-08-11T17:58:21Z

<p>Bschineller: </p> <hr /> <div>== Proposals for v1.1 ==<br /> <br /> * [[Technical_Team/Proposals/2012-06-18/standardNotice_field_for_License_class|2012-Jun-18: standardNotice field for License Class]]<br /> * [[Technical_Team/Proposals/2012-06-18/isOsiApproved_field_for_listed_licenses|2012-Jun-18-2: isOsiApproved field for listed licenses]]<br /> <br /> == Proposals for vNEXT ==<br /> <br /> * [[Technical_Team/Proposals/2010-10-21/License_URLs|2010-10-21-1: License URLs]]<br /> * [[Technical_Team/Proposals/2011-12-20/SPDX_analysis_history_tracking|2011-12-20: SPDX Analysis History Tracking]]<br /> * [[Technical_Team/Proposals/2012-Mar-11_SPDX_File_Aggregation|2012-Mar-11: SPDX File Aggregation]]<br /> * [[Technical_Team/Proposals/2013-Dec-12_2.0_Tag_Format_Turtle|2013-Dec-02: SPDX 2.0 TagValue Format Proposal - Turtle]]<br /> <br /> ==Adopted proposals==<br /> <br /> * [[Technical_Team/Proposals/2010-10-21/artifactOf|2010-10-21-3: artifactOf]]<br /> * [[Technical_Team/Proposals/2010-10-21/Composite_licensing|2010-10-21-4: Composite licensing]]<br /> * [[Technical_Team/Proposals/2012-06-06/Detached_Signed_SPDX_Files|2012-Mar-6: Detached signed SPDX files]]<br /> <br /> ==Rejected proposals==<br /> <br /> * [[Technical_Team/Proposals/2010-10-21/File_origin|2010-10-21-2: File origin]]<br /> * [[Technical_Team/Proposals/2010-12-07/Tag-value_RDF_mapping|2010-12-07-1: Tag-value RDF mapping]]<br /> * [[Technical_Team/Proposals/2012-01-17/Signed_SPDX_data|2012-01-17: Signed SPDX Data]]<br /> * [[Technical_Team/Proposals/2012-03-05/Inline_signed_SPDX_files| 2012-Mar-5: Inline signed SPDX files]]<br /> <br /> ==Drafts==<br /> <br /> * [[Technical_Team/Proposals/2010-10-28/File_references|2010-10-28-1: File references]]<br /> * [[Technical_Team/Proposals/2010-11-16/Or_later_version_licensing|2010-11-16-1: Or later version licensing]]<br /> * [[Technical_Team/Proposals/2013-6-13/License_Template|2013-6-13-1: License Template Proposal]]<br /> * [[https://docs.google.com/document/d/13OknzNnY56UZhnj_VVPatirBrNze5cWXDx2fnKbBI_g/edit 2015-08 Snippets Proposal]]<br /> * [[https://docs.google.com/document/d/1j6LWnkh5GbMV9Xo5_zJ0wTNLROEIa4o1OU279YueI90/edit 2015-08 External Identifier Proposal]]<br /> * [[https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit 2015-08 Security and Asset Manager Proposal]]<br /> * External Package [[https://docs.google.com/document/d/1HTgrEKBlza_U3yZBKpgu9JDYhZkZ6Jbj9jNsmRreCMo/edit Proposal]] [[https://docs.google.com/spreadsheets/d/1Apd98oRKAKLZfqTYZIx_ugD28RP2NwJMRGD-OHKg4vo/edit Attribute comparison]]<br /> <br /> <br /> ==Other==<br /> <br /> * [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|2012 Feb 1 - Merged Model Proposal]]<br /> * [[Technical_Team/Proposals/2012-03-20/Licenses_associated_with_licensor|2012-Mar-20: Licenses associated with licensor]]<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-26T17:42:45Z

<p>Bschineller: /* Package Download Location (4.6) */</p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> In SPDX 2.0, when the codebase for an SPDX analysis is taken from a Version Control System (VCS) best practice is to provide the specific point in the VCS history from which the code was pulled. The Package Download Location specifies syntax for several VCS systems (git, svn, bzr, hg)<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Using the SPDX License List ==<br /> <br /> * a site which provides a pick list of SPDX licenses, and based on choice stores the declared license for an OSS project<br /> * an API for a site that returns the declared license of a project (e.g. github repo) in terms of SPDX license identifier<br /> * a LICENSES.TXT file in a codebase that states the licensing for the code referencing SPDX license identifiers<br /> * a comment section in a source file that states the licensing for the file referencing SPDX license identifiers<br /> * Package Managers / Distros that state licensing in files specific to that package manager<br /> ** a package manager (e.g. Rubygems) that encourages use of SPDX identifiers by validating .gemspec files ?<br /> ** a distro that encourages use of SPDX identifiers in their spec files (e.g. Debian DEP-5 format, while not an SPDX doc, can/may use SPDX license identifiers)?<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> Below are some pairs of SPDX doc, referencing External SPDX Doc that illustrate a few scenarios<br /> <br /> Ex 1:<br /> * Binary Jar file<br /> * java source files it was built from<br /> <br /> Ex 2:<br /> * original java source files (on apache.org)<br /> * repackaged java source files (from a distro) <br /> <br /> Ex 3:<br /> * original java source files<br /> * patched (modified) java source files (having added a security fix)<br /> <br /> <br /> == Annotations (replaces Reviewer Comments) ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.<br /> <br /> “SOURCE” | “BINARY” | “ARCHIVE” | “APPLICATION” | “AUDIO” |<br /> “IMAGE” | “TEXT” | “VIDEO” | “DOCUMENTATION” | “SPDX” | “OTHER”<br /> <br /> 2.0 Spec allows for multiple filetypes <br /> <br /> * a .jar file containing compiled .class files could be described as BINARY and ARCHIVE<br /> * a .java file could be both SOURCE TEXT<br /> * a binary PDF file could be BINARY DOCUMENTATION</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-26T17:38:58Z

<p>Bschineller: /* Using the SPDX License List */</p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Using the SPDX License List ==<br /> <br /> * a site which provides a pick list of SPDX licenses, and based on choice stores the declared license for an OSS project<br /> * an API for a site that returns the declared license of a project (e.g. github repo) in terms of SPDX license identifier<br /> * a LICENSES.TXT file in a codebase that states the licensing for the code referencing SPDX license identifiers<br /> * a comment section in a source file that states the licensing for the file referencing SPDX license identifiers<br /> * Package Managers / Distros that state licensing in files specific to that package manager<br /> ** a package manager (e.g. Rubygems) that encourages use of SPDX identifiers by validating .gemspec files ?<br /> ** a distro that encourages use of SPDX identifiers in their spec files (e.g. Debian DEP-5 format, while not an SPDX doc, can/may use SPDX license identifiers)?<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> Below are some pairs of SPDX doc, referencing External SPDX Doc that illustrate a few scenarios<br /> <br /> Ex 1:<br /> * Binary Jar file<br /> * java source files it was built from<br /> <br /> Ex 2:<br /> * original java source files (on apache.org)<br /> * repackaged java source files (from a distro) <br /> <br /> Ex 3:<br /> * original java source files<br /> * patched (modified) java source files (having added a security fix)<br /> <br /> <br /> == Annotations (replaces Reviewer Comments) ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.<br /> <br /> “SOURCE” | “BINARY” | “ARCHIVE” | “APPLICATION” | “AUDIO” |<br /> “IMAGE” | “TEXT” | “VIDEO” | “DOCUMENTATION” | “SPDX” | “OTHER”<br /> <br /> 2.0 Spec allows for multiple filetypes <br /> <br /> * a .jar file containing compiled .class files could be described as BINARY and ARCHIVE<br /> * a .java file could be both SOURCE TEXT<br /> * a binary PDF file could be BINARY DOCUMENTATION</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-26T17:34:30Z

<p>Bschineller: /* Using the SPDX License List */</p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Using the SPDX License List ==<br /> <br /> * a site which provides a pick list of SPDX licenses, and based on choice stores the declared license for an OSS project<br /> * an API for a site that returns the declared license of a project (e.g. github repo) in terms of SPDX license identifier<br /> * a package manager (e.g. Rubygems) that encourages use of SPDX identifiers by validating .gemspec files ?<br /> * a LICENSES.TXT file in a codebase that states the licensing for the code referencing SPDX license identifiers<br /> * a comment section in a source file that states the licensing for the file referencing SPDX license identifiers<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> Below are some pairs of SPDX doc, referencing External SPDX Doc that illustrate a few scenarios<br /> <br /> Ex 1:<br /> * Binary Jar file<br /> * java source files it was built from<br /> <br /> Ex 2:<br /> * original java source files (on apache.org)<br /> * repackaged java source files (from a distro) <br /> <br /> Ex 3:<br /> * original java source files<br /> * patched (modified) java source files (having added a security fix)<br /> <br /> <br /> == Annotations (replaces Reviewer Comments) ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.<br /> <br /> “SOURCE” | “BINARY” | “ARCHIVE” | “APPLICATION” | “AUDIO” |<br /> “IMAGE” | “TEXT” | “VIDEO” | “DOCUMENTATION” | “SPDX” | “OTHER”<br /> <br /> 2.0 Spec allows for multiple filetypes <br /> <br /> * a .jar file containing compiled .class files could be described as BINARY and ARCHIVE<br /> * a .java file could be both SOURCE TEXT<br /> * a binary PDF file could be BINARY DOCUMENTATION</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-26T17:32:44Z

<p>Bschineller: /* Examples */</p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Using the SPDX License List ==<br /> <br /> * a site which provides a pick list of SPDX licenses, and based on choice stores the declared license for an OSS project<br /> * an API for a site that returns the declared license of a project (e.g. github repo) in terms of SPDX license identifier<br /> * a LICENSES.TXT file in a codebase that states the licensing for the code referencing SPDX license identifiers<br /> * a comment section in a source file that states the licensing for the file referencing SPDX license identifiers<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> Below are some pairs of SPDX doc, referencing External SPDX Doc that illustrate a few scenarios<br /> <br /> Ex 1:<br /> * Binary Jar file<br /> * java source files it was built from<br /> <br /> Ex 2:<br /> * original java source files (on apache.org)<br /> * repackaged java source files (from a distro) <br /> <br /> Ex 3:<br /> * original java source files<br /> * patched (modified) java source files (having added a security fix)<br /> <br /> <br /> == Annotations (replaces Reviewer Comments) ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.<br /> <br /> “SOURCE” | “BINARY” | “ARCHIVE” | “APPLICATION” | “AUDIO” |<br /> “IMAGE” | “TEXT” | “VIDEO” | “DOCUMENTATION” | “SPDX” | “OTHER”<br /> <br /> 2.0 Spec allows for multiple filetypes <br /> <br /> * a .jar file containing compiled .class files could be described as BINARY and ARCHIVE<br /> * a .java file could be both SOURCE TEXT<br /> * a binary PDF file could be BINARY DOCUMENTATION</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-26T17:27:59Z

<p>Bschineller: /* File Types */</p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> Below are some pairs of SPDX doc, referencing External SPDX Doc that illustrate a few scenarios<br /> <br /> Ex 1:<br /> * Binary Jar file<br /> * java source files it was built from<br /> <br /> Ex 2:<br /> * original java source files (on apache.org)<br /> * repackaged java source files (from a distro) <br /> <br /> Ex 3:<br /> * original java source files<br /> * patched (modified) java source files (having added a security fix)<br /> <br /> <br /> == Annotations (replaces Reviewer Comments) ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.<br /> <br /> “SOURCE” | “BINARY” | “ARCHIVE” | “APPLICATION” | “AUDIO” |<br /> “IMAGE” | “TEXT” | “VIDEO” | “DOCUMENTATION” | “SPDX” | “OTHER”<br /> <br /> 2.0 Spec allows for multiple filetypes <br /> <br /> * a .jar file containing compiled .class files could be described as BINARY and ARCHIVE<br /> * a .java file could be both SOURCE TEXT<br /> * a binary PDF file could be BINARY DOCUMENTATION</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-26T17:24:15Z

<p>Bschineller: /* Examples */</p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> Below are some pairs of SPDX doc, referencing External SPDX Doc that illustrate a few scenarios<br /> <br /> Ex 1:<br /> * Binary Jar file<br /> * java source files it was built from<br /> <br /> Ex 2:<br /> * original java source files (on apache.org)<br /> * repackaged java source files (from a distro) <br /> <br /> Ex 3:<br /> * original java source files<br /> * patched (modified) java source files (having added a security fix)<br /> <br /> <br /> == Annotations (replaces Reviewer Comments) ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.<br /> <br /> “SOURCE” | “BINARY” | “ARCHIVE” | “APPLICATION” | “AUDIO” |<br /> “IMAGE” | “TEXT” | “VIDEO” | “DOCUMENTATION” | “SPDX” | “OTHER”</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Best_Practices 2015-05-19T17:58:12Z

<p>Bschineller: </p> <hr /> <div>This is a place holder for working on the Best Practices document.<br /> <br /> Best Practices <br /> <br /> __TOC__<br /> <br /> = Introduction =<br /> <br /> = Interpreting the Specification =<br /> <br /> Clarify and help with what is in the spec. Structure sections around the spec?<br /> <br /> = Tools =<br /> <br /> Best practices around using the SPDX tools<br /> <br /> = Contributing to SPDX =<br /> <br /> how to provide feedback, get involved, etc<br /> <br /> Jack: This should be moved to the website.<br /> <br /> = Producing = <br /> <br /> SPDX Version: 1.2<br /> PURPOSE: The SPDX specification is meant to stand on its own and to make clear how a field is to be populated. Still, there are times when more clarification is required. This tech note provides clarification with regard to certain fields about which questions of arisen. Some of these clarifications may be rolled into future versions of the specification. <br /> <br /> == Package Name (4.1) ==<br /> <br /> The package name should be exclusive of version number. Field 4.2 Package Version is intended for version number and the package name should not redundantly specify this information.<br /> ===== Example =====<br /> Correct<br /> :Package Name: glibc<br /> :Package Version: 2.11.1<br /> <br /> Incorrect<br /> :Package Name: glibc '''2.11.1'''<br /> :Package Version: 2.11.1<br /> <br /> == Package Supplier (4.4); Package Originator (4.5); Source Information (4.10) ==<br /> <br /> The first two fields are intended to where the package came from and what entity created it. In many cases these will be one in the same, but it is possible that the supplier may have gotten the package from another source. <br /> <br /> ===== Example: =====<br /> Wind River supplies the Linux kernel. <br /> :Package Supplier: Wind River<br /> :Package Originator: linux.org<br /> <br /> Source Information is a freeform field, which, like many such fields in SPDX is there to allow the document creator to provide information they feel would be useful or important, but which my not fit neatly into the specification.<br /> <br /> == Package Download Location (4.6) ==<br /> <br /> The intent of this field is to indicate the URL of the location from which the package is actually obtained. Generally this should be the originating site of the package, but in cases where the package was obtained from a mirror site, the URL of the mirror should be used. The format for the URL should follow RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it.<br /> <br /> == Concluded License (4.11); Declared License (4.13) ==<br /> <br /> In cases where there is a contradiction between the Declared License and some other license present, the concluded license should represent that contradiction, and best practice would be to explain further in the 4.14 Comments on License field.<br /> <br /> '''LEGAL TEAM SHOULD REVIEW THIS'''<br /> <br /> ===== Example: =====<br /> A GPL 2 package that contains files licensed under Apache 2.0. <br /> :Declared License: GPL-2.0<br /> :Concluded License: GPL-2.0 and Apache-2.0<br /> :Comments on License: Several Apache licensed files (A, B, and C) are included in the packages causing an incompatibility with the licensing of the package.<br /> <br /> == Extracted Text (5.2) ==<br /> <br /> To clarify, or reinforce, the text included here, should be the exact text in that is included with the package and no more. Some early SPDX tools included full text of the relevant license even though the full text was not supplied in the actual package. The example in the specification is one where full text is included, but if the text is incomplete, so should be the text in the Extracted Text field.<br /> <br /> ===== Example: =====<br /> A copying file in the top level of the directory says, “This software is licensed under the Beer License.” <br /> <br /> Correct:<br /> :Extracted Text: This software is licensed under the Beer-ware License<br /> <br /> Incorrect:<br /> :“THE BEER-WARE LICENSE&quot; (Revision 42):&lt;phk@FreeBSD.ORG&gt; wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kam<br /> <br /> == File Name (6.1) ==<br /> <br /> To clarify, the format for the file name should follow URI RFC conventions, specifically RFC3986 or any newer one that may eventually augment or obsolete it. Specifically, it uses the relative path reference format of an URI, and is defined as being relative to the root of the package from which the file came.<br /> <br /> In RFC3986, section 4.2, a relative path reference must not start with a slash character (&quot;/&quot;). Relative references also do not need to start with a &quot;./&quot; (dot slash), although there is one format for which the preceding &quot;./&quot; is necessary. In any case, RFC3986 is clear about how to handle dot-segments, and in the case of &quot;./&quot;, it is simply removed.<br /> <br /> ===== Example: =====<br /> Correct:<br /> :FileName: ./package/foo.c<br /> :FileName: package/foo.c<br /> Incorrect:<br /> :FileName: /package/foo.c<br /> :FileName: //package/foo.c<br /> <br /> Note about RFC3986:<br /> :''This document obsoletes [RFC2396], which merged &quot;Uniform Resource Locators&quot; [RFC1738] and &quot;Relative Uniform Resource Locators&quot; [RFC1808] in order to define a single, generic syntax for all URIs.''<br /> <br /> == Author vs. Creator (3.1) vs. Reviewer (7.1)==<br /> <br /> '''Author:''' The author is used occasionally in the text of the specification and generally refers to the creator(s) of the package. There is no explicit field for the author information other than copyright information and URL, which may or may not reflect the actual original author. In section 2.2.1, there is also a reference to an &quot;SPDX Author&quot;; this actually refers to the SPDX Creator.<br /> <br /> '''Creator:''' The SPDX Creator is defined in section 3.1 and is used to identify who (or what, in the case of a tool) created the SPDX file.<br /> <br /> '''Reviewer:''' The SPDX Reviewer is detined in section 7.1 and is used to identify who reviewed the content of the SPDX.<br /> <br /> To put things into context, let's consider the following flow:<br /> # An author creates a package and assigns a license to it, hopefully to each individual file, and also follows all of the best practices and obligations for the chosen or found licenses in the package.<br /> # An SPDX creator analyzes the content of the package, extracts the pertinent information and assembles the SPDX file, whether manually or using a tool.<br /> # An SPDX reviewer inspects the work of the SPDX creator, whether manually or using a tool. Consider the reviewer to be anything from another set of eyes, to a recognized reliable entity with some kind of sign-off authority.<br /> <br /> The SPDX creator is a mandatory parameter - every file must have its creator. However, not every SPDX file is reviewed.<br /> <br /> == Use of Parentheses in License Tag Fields ==<br /> <br /> In the RDF object model, licenses can be defined to be nested disjunctive or conjunctive sets in a very flexible manner. However, when using the Tag value format, it is not clear how, if at all, one could use the parentheses to define more complex licensing scenarios. It is not the intention to restrict either one of the formats, hence we view these additional examples as acceptable:<br /> <br /> '''Examples:'''<br /> <br /> Correct<br /> :LicenseConcluded: LGPL-2.0<br /> :LicenseConcluded: (LGPL-2.0 or LicenseRef-2)<br /> :LicenseConcluded: (LGPL-2.0 and (LicenseRef-2 or LicenseRef-3))<br /> :LicenseConcluded: ((LicenseRef-2 or (LicenseRef-3 and LicenseRef-4)) and LGPL-2.0)<br /> <br /> Incorrect<br /> :LicenseConcluded: (LGPL-2.0)<br /> :LicenseConcluded: LGPL-2.0 or LicenseRef-2<br /> :LicenseConcluded: (LGPL-2.0 and LicenseRef-2 or LicenseRef-3)<br /> <br /> <br /> Conceptually, much like in the RDF format, there are no limits to the depth of nested license sets, although practically, more than 2 levels are improbable.<br /> <br /> This applies to all license fields.<br /> <br /> = Consuming =<br /> <br /> Best practices around the process of doing it. Examples of how this is done.<br /> <br /> = Notes from LinuxCon 2013 17 Sept 2013 =<br /> <br /> What should be in a best practices, how does it relate to the spec?<br /> <br /> Possibilities:<br /> * examples<br /> * particular questions (sort of like a FAQ)<br /> * Could start with things that are not well defined but end up in the specification<br /> * I need a field for X, its not there, what field could I use?<br /> * best practices around the specification and best practices around contributing to SPDX. Maybe two documents?<br /> * Snapshot best practices document at intervals and post on site. Use wiki for active discussions, new proposals, etc.,.<br /> * Should we have a getting started guide?<br /> * best practices for meta tagging like u-boot did. maybe link it in here but should be separate page. Could possibly include other information for developers supporting spdx and producing spdx friendly code. Look at things like U-boot, Mozilla, etc.,.<br /> <br /> &lt;br/&gt;<br /> <br /> = Examples =<br /> <br /> This section contains examples of working with SPDX documents.<br /> <br /> Jack: In doing this I was looking for open source projects to use but Im now thinking we should &quot;create&quot; our own projects. We could right size them for the examples and we could take the code from other OS projects and store the examples and the SPDX docs in our GIT. These docs could then become a form of validation examples so people generating SPDX docs could compare them back?<br /> <br /> Jack: Im also wondering of the examples below should be &quot;singular&quot; in nature. That is they illustrate one concept?<br /> <br /> <br /> == Converting 1.2 to 2.0 ==<br /> <br /> Jack: Show a SPDX 1.2 and then a version of it using 2.0 and explain how one would convert. We can use the spdx tools as the example. Not sure this belongs here. Could be its own thing? May fit better here if there are things you can do when converting that help.<br /> <br /> == Simple 2.0 Document ==<br /> <br /> Jack: Just a simple use case. Small number of files, say less then 5. Easy to get your head around.<br /> Bill: see https://github.com/spdx/tools/blob/develop/TestFiles/SPDXTagExample-v2.0.spdx<br /> <br /> == Multiple SPDX Documents in one ==<br /> <br /> Jack: Use this for a test case of multiple documents related to one another and multiple documents in one. <br /> <br /> [https://www.openssl.org/ OpenSSL Website]<br /> <br /> == External SPDX Documents ==<br /> <br /> Jack: Binary referencing external source spdx documents. We could use SPDX tools here?<br /> <br /> == Reviewer Comments ==<br /> <br /> Jack: Simple example with reviewer comments added after the fact.<br /> <br /> == File Types ==<br /> <br /> Jack: Example showing use of all file types, especially when there are &quot;choices&quot;.</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Priorities 2014-12-16T19:26:35Z

<p>Bschineller: draft google doc</p> <hr /> <div>This page has links to the various items the Technical Team is currently working on.<br /> <br /> * [[Technical_Team/Proposals|Proposals]]<br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]<br /> <br /> SPDX 2.0 draft google doc https://docs.google.com/document/d/1wE_zvLU4c291ACi9wIJmQoE4ltKRW4rzM1TYiIvEVOs/edit<br /> * [[Technical_Team/Ideas_for_After_1.0_of_Spec|Ideas for After 1.0 of Spec]]<br /> * [[Technical_Team/Best_Practices|Best Practices Working Draft]]<br /> * [[Technical_Team/Spec_Release_Process|Specification Release Checklist]]<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal 2014-07-29T18:13:56Z

<p>Bschineller: </p> <hr /> <div><br /> Below is a class diagram merging Ed Warnicke's proposed SPDX Element model with the 1.0 model. Definitely a work in progress. Most of the class definitions can be found in the 1.0 spec in the RDF appendix (model) or in [[Technical_Team/Proposals/Rough_proposal_for_provenance,_hierarchy_and_aggregation,_and_supply_chain_friendliness_in_SPDX_2.0|Ed's proposal]].<br /> <br /> The goals of this proposal are to:<br /> <br /> * Support the use cases for the 2.0 spec<br /> * Support the supply chain use cases (included in the use cases for the 2.0 spec)<br /> * Support the &quot;hierarchical&quot; or embedded package use cases<br /> * Provide a more abstract model which can simplify the application of SPDX to some of the more complex use cases<br /> <br /> This proposal extends the existing proposals by adding an SPDX Element Relationship which describes the type of relationship from one SPDX element to another.<br /> <br /> See the attached document for the mapping between the SPDX 1.0 properties and this proposal.<br /> <br /> See the attached document for a proposal on creating RDF references to other Licensable documents which can be verified through checksums.<br /> <br /> Model updated on April 1, 2014 with the results from the Linux Collab Summit. <br /> <br /> [[Image:Model-4-1-2014.png|909px|Class Diagram]]<br /> <br /> '''Relationship Type and Usage Type Definitions''' <br /> being fleshed out on this Google Doc https://docs.google.com/spreadsheets/d/13MuhIhmdSx5e9B7OCuz_CUoYRtAu-WU08SbIMlym5Xc/edit?usp=sharing<br /> <br /> Yet another Google Doc, this one for correlating Model support for 2.0 Use Cases<br /> https://docs.google.com/spreadsheet/ccc?key=0AhWBVUYWeqV1dC01TGE5eERTdVJqMlZSUWwwZHItaWc&amp;usp=drive_web#gid=0<br /> <br /> Element Identifier proposal (such that an element can be uniquely referred to - IN DRAFT)<br /> https://docs.google.com/document/d/1gNtAYs7IhlGE4SWAXUIIWwpZmEvr4Jz9Ep1MNswyWBk/edit#heading=h.yg1m5fn32gf3<br /> <br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal 2014-07-29T18:09:30Z

<p>Bschineller: </p> <hr /> <div><br /> Below is a class diagram merging Ed Warnicke's proposed SPDX Element model with the 1.0 model. Definitely a work in progress. Most of the class definitions can be found in the 1.0 spec in the RDF appendix (model) or in [[Technical_Team/Proposals/Rough_proposal_for_provenance,_hierarchy_and_aggregation,_and_supply_chain_friendliness_in_SPDX_2.0|Ed's proposal]].<br /> <br /> The goals of this proposal are to:<br /> <br /> * Support the use cases for the 2.0 spec<br /> * Support the supply chain use cases (included in the use cases for the 2.0 spec)<br /> * Support the &quot;hierarchical&quot; or embedded package use cases<br /> * Provide a more abstract model which can simplify the application of SPDX to some of the more complex use cases<br /> <br /> This proposal extends the existing proposals by adding an SPDX Element Relationship which describes the type of relationship from one SPDX element to another.<br /> <br /> See the attached document for the mapping between the SPDX 1.0 properties and this proposal.<br /> <br /> See the attached document for a proposal on creating RDF references to other Licensable documents which can be verified through checksums.<br /> <br /> Model updated on April 1, 2014 with the results from the Linux Collab Summit. <br /> <br /> [[Image:Model-4-1-2014.png|909px|Class Diagram]]<br /> <br /> '''Relationship Type and Usage Type Definitions''' <br /> being fleshed out on this Google Doc https://docs.google.com/spreadsheets/d/13MuhIhmdSx5e9B7OCuz_CUoYRtAu-WU08SbIMlym5Xc/edit?usp=sharing<br /> <br /> Yet another Google Doc, this one for correlating Model support for 2.0 Use Cases<br /> https://docs.google.com/spreadsheet/ccc?key=0AhWBVUYWeqV1dC01TGE5eERTdVJqMlZSUWwwZHItaWc&amp;usp=drive_web#gid=0<br /> <br /> <br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal 2014-06-03T14:48:29Z

<p>Bschineller: </p> <hr /> <div><br /> Below is a class diagram merging Ed Warnicke's proposed SPDX Element model with the 1.0 model. Definitely a work in progress. Most of the class definitions can be found in the 1.0 spec in the RDF appendix (model) or in [[Technical_Team/Proposals/Rough_proposal_for_provenance,_hierarchy_and_aggregation,_and_supply_chain_friendliness_in_SPDX_2.0|Ed's proposal]].<br /> <br /> The goals of this proposal are to:<br /> <br /> * Support the use cases for the 2.0 spec<br /> * Support the supply chain use cases (included in the use cases for the 2.0 spec)<br /> * Support the &quot;hierarchical&quot; or embedded package use cases<br /> * Provide a more abstract model which can simplify the application of SPDX to some of the more complex use cases<br /> <br /> This proposal extends the existing proposals by adding an SPDX Element Relationship which describes the type of relationship from one SPDX element to another.<br /> <br /> See the attached document for the mapping between the SPDX 1.0 properties and this proposal.<br /> <br /> See the attached document for a proposal on creating RDF references to other Licensable documents which can be verified through checksums.<br /> <br /> Model updated on April 1, 2014 with the results from the Linux Collab Summit. <br /> <br /> [[Image:Model-4-1-2014.png|909px|Class Diagram]]<br /> <br /> '''Relationship Type and Usage Type Definitions''' <br /> being fleshed out on this Google Doc https://docs.google.com/spreadsheets/d/13MuhIhmdSx5e9B7OCuz_CUoYRtAu-WU08SbIMlym5Xc/edit?usp=sharing<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Business_Team/SPDX_2_0_Project 2014-04-15T18:31:35Z

<p>Bschineller: /* Milestones */</p> <hr /> <div><br /> '''&lt;big&gt;SPDX 2.0 Specification Project Overview&lt;/big&gt;'''<br /> <br /> __TOC__<br /> <br /> &lt;br /&gt;<br /> <br /> = Objectives =<br /> <br /> This is the next major release of the specification. SPDX 2.0 will extend the specification beyond the package level scope and enhance it to address relationships between artifacts.<br /> <br /> &lt;br /&gt;<br /> <br /> == Overall Status ==<br /> <br /> Our current plan is to try and get 2.0 done before LinuxCon North America which is roughly August 20th of this tear. Our go or no go date to see if we can make it is to have a first draft of the specification y June 1st.<br /> <br /> The specification is still under development, so we would not recommend downloading the version from this wiki page until it is further developed.<br /> <br /> We have made a lot of progress recently and there are a few artifacts that you can look at to give you and idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [[http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25 LinuxCollab Meeting Minutes ]]<br /> <br /> The current goal is to have a first draft by June of this year.<br /> <br /> <br /> &lt;br /&gt;<br /> <br /> = Milestones =<br /> <br /> The target date is set by the Milestone owner. When completed, the date will be changed to say COMPLETE. The milestone owner should also update the Status column as appropriate.<br /> <br /> {| class=&quot;wikitable sortable&quot; border=&quot;1&quot;<br /> |+ 2.0 Milestones<br /> ! align=&quot;left&quot; width=12% | Milestone<br /> ! align=&quot;left&quot; width=12% | Owner<br /> ! class=&quot;unsortable&quot; | Details<br /> ! | Target Date<br /> ! class=&quot;unsortable&quot; | Current Status<br /> |-<br /> | Use Cases<br /> | Tech Team<br /> | Collection of use cases and then prioritization on the ones that will be addressed in the 2.0 specification.<br /> | COMPLETE<br /> |<br /> |-<br /> | Requirements Overview<br /> | Kirsten Newcomer<br /> | High level requirements overview.<br /> | April 2014<br /> | Has been reviewed and pushed to the Tech report Framework. Need to publish to main site an dlink from this page as well.<br /> |-<br /> | Object Models<br /> | Tech Team<br /> | Modeling to support the new use cases. This is the model we are using: [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|Merged Model Proposal]]<br /> | June 1 2014<br /> | <br /> |-<br /> | Draft specification to start tool development<br /> | Tech Team<br /> | First draft of the specification. Can start tool development and get initial reviews by communnity. Ideally soecification should be somewhat stable to start tool development: i.e. no big changes anticipated. [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> | June 1 2014<br /> | Working through polishing the data model which was reviewed at Linux Collab. We have made a lot of progress recently and there are a few artifacts that you can look at to give you an idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25] <br /> |-<br /> | Validate Use cases<br /> | Tech Team<br /> | See use cases here: [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]. Need to valaidate these against the data model.<br /> | June 1 2014<br /> | In Progress. Several of the use cases were reviewed at Linux Collab.<br /> |-<br /> | SPDX Tools and Examples Updates<br /> | Tech Team<br /> | All SPDX tools and examples updated to support 2.0<br /> | start July 1 - August 13 (D-7days)<br /> | Need to recruit someone for the tag-value format tools<br /> |-<br /> | Migration Plan Draft Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Draft Review Period<br /> | Tech Team<br /> | Specification is out for review by the general community<br /> | tentative June 1-June 30<br /> |<br /> |-<br /> | SPDX 2.0 Best and Final Review Period<br /> | Tech Team<br /> | Best and final version of the specification is out for a final blessing.<br /> | tentative July 1-July 15<br /> |<br /> |-<br /> | Migration Plan Best and Final Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | Launch Plan<br /> | Business Team<br /> | Launch Plan devised and in place for 2.0 release. If we want to submit papers to LinuxCons or do something at them we need to decide before May 2nd!<br /> | June 2014<br /> |<br /> |-<br /> | Press release drafted and sent to LF <br /> | Business Team<br /> | Press release announcing 2.0 is drafted and sent to LF to review and publish.<br /> | TBD<br /> |}<br /> <br /> &lt;br /&gt;<br /> <br /> = Useful Links =<br /> <br /> The following are links to useful information around the 2.0 Specification.<br /> * [[Technical_Team/Spec_Release_Process|What is a Specification Release Checklist]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]] <br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> * Bug reports (may be useful to look at those targeted against 2.0 for completion)<br /> <br /> &lt;br /&gt;<br /> <br /> = Specification Release Checklist =<br /> <br /> This checklist will be used as the Specification approaches release. It is to make sure we do no forget something.<br /> <br /> == Specification Review Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Review Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification of start of work on a new version to the General List (with summary)<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version (points to google doc repro)<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that draft is under way<br /> |Web Admin<br /> |<br /> |}<br /> <br /> == SPDX Specification / Document Collateral Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Release Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification on general list that the specification is approved<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version<br /> |Web Admin<br /> |<br /> |-<br /> |RDF terms page updated<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that there is a new version<br /> |Web Admin<br /> |<br /> |-<br /> |Press release (via Linux Foundation) for the new version<br /> |Business Team<br /> |<br /> |-<br /> |Roadmap updated to show specification release<br /> |Business Team<br /> |<br /> |}<br /> <br /> <br /> == SPDX Tools Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Tool Release Checklist<br /> |-<br /> |Tool<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Spreadsheet Template and Examples updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |SPDX Compare updated<br /> |Tech team tools group<br /> |<br /> |--<br /> |SPDX Viewer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet Template and Examples posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |SPDX Compare posted to web site<br /> |SPDX Web Admin<br /> |<br /> |--<br /> |SPDX Viewer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |}<br /> <br /> [[Category:Business]]</div>

Bschineller https://wiki.spdx.org/view/Business_Team/SPDX_2_0_Project 2014-04-15T18:28:58Z

<p>Bschineller: /* Milestones */</p> <hr /> <div><br /> '''&lt;big&gt;SPDX 2.0 Specification Project Overview&lt;/big&gt;'''<br /> <br /> __TOC__<br /> <br /> &lt;br /&gt;<br /> <br /> = Objectives =<br /> <br /> This is the next major release of the specification. SPDX 2.0 will extend the specification beyond the package level scope and enhance it to address relationships between artifacts.<br /> <br /> &lt;br /&gt;<br /> <br /> == Overall Status ==<br /> <br /> Our current plan is to try and get 2.0 done before LinuxCon North America which is roughly August 20th of this tear. Our go or no go date to see if we can make it is to have a first draft of the specification y June 1st.<br /> <br /> The specification is still under development, so we would not recommend downloading the version from this wiki page until it is further developed.<br /> <br /> We have made a lot of progress recently and there are a few artifacts that you can look at to give you and idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [[http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25 LinuxCollab Meeting Minutes ]]<br /> <br /> The current goal is to have a first draft by June of this year.<br /> <br /> <br /> &lt;br /&gt;<br /> <br /> = Milestones =<br /> <br /> The target date is set by the Milestone owner. When completed, the date will be changed to say COMPLETE. The milestone owner should also update the Status column as appropriate.<br /> <br /> {| class=&quot;wikitable sortable&quot; border=&quot;1&quot;<br /> |+ 2.0 Milestones<br /> ! align=&quot;left&quot; width=12% | Milestone<br /> ! align=&quot;left&quot; width=12% | Owner<br /> ! class=&quot;unsortable&quot; | Details<br /> ! | Target Date<br /> ! class=&quot;unsortable&quot; | Current Status<br /> |-<br /> | Use Cases<br /> | Tech Team<br /> | Collection of use cases and then prioritization on the ones that will be addressed in the 2.0 specification.<br /> | COMPLETE<br /> |<br /> |-<br /> | Requirements Overview<br /> | Kirsten Newcomer<br /> | High level requirements overview.<br /> | April 2014<br /> | Has been reviewed and pushed to the Tech report Framework. Need to publish to main site an dlink from this page as well.<br /> |-<br /> | Data Models<br /> | Tech Team<br /> | Modelling to support the new use cases. This is the model we are using: [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|Merged Model Proposal]]<br /> | June 1 2014<br /> | <br /> |-<br /> | Draft specification to start tool development<br /> | Tech Team<br /> | First draft of the specification. Can start tool development and get initial reviews by communnity. Ideally soecification should be somewhat stable to start tool development: i.e. no big changes anticipated. [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> | June 1 2014<br /> | Working through polishing the data model which was reviewed at Linux Collab. We have made a lot of progress recently and there are a few artifacts that you can look at to give you an idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25] <br /> |-<br /> | Validate Use cases<br /> | Tech Team<br /> | See use cases here: [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]. Need to valaidate these against the data model.<br /> | June 1 2014<br /> | In Progress. Several of the use cases were reviewed at Linux Collab.<br /> |-<br /> | SPDX Tools and Examples Updates<br /> | Tech Team<br /> | All SPDX tools and examples updated to support 2.0<br /> | start July 1 - August 13 (D-7days)<br /> | Need to recruit someone for the tag-value format tools<br /> |-<br /> | Migration Plan Draft Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Draft Review Period<br /> | Tech Team<br /> | Specification is out for review by the general community<br /> | tentative June 1-June 30<br /> |<br /> |-<br /> | SPDX 2.0 Best and Final Review Period<br /> | Tech Team<br /> | Best and final version of the specification is out for a final blessing.<br /> | tentative July 1-July 15<br /> |<br /> |-<br /> | Migration Plan Best and Final Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Launch Plan<br /> | Business Team<br /> | Launch Plan devised and in place for 2.0 release. If we want to submit papers to LinuxCons or do something at them we need to decide before May 2nd!<br /> | June 2014<br /> |<br /> |-<br /> | Press release drafted and sent to LF <br /> | Business Team<br /> | Press release announcing 2.0 is drafted and sent to LF to review and publish.<br /> | TBD<br /> |}<br /> <br /> &lt;br /&gt;<br /> <br /> = Useful Links =<br /> <br /> The following are links to useful information around the 2.0 Specification.<br /> * [[Technical_Team/Spec_Release_Process|What is a Specification Release Checklist]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]] <br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> * Bug reports (may be useful to look at those targeted against 2.0 for completion)<br /> <br /> &lt;br /&gt;<br /> <br /> = Specification Release Checklist =<br /> <br /> This checklist will be used as the Specification approaches release. It is to make sure we do no forget something.<br /> <br /> == Specification Review Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Review Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification of start of work on a new version to the General List (with summary)<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version (points to google doc repro)<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that draft is under way<br /> |Web Admin<br /> |<br /> |}<br /> <br /> == SPDX Specification / Document Collateral Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Release Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification on general list that the specification is approved<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version<br /> |Web Admin<br /> |<br /> |-<br /> |RDF terms page updated<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that there is a new version<br /> |Web Admin<br /> |<br /> |-<br /> |Press release (via Linux Foundation) for the new version<br /> |Business Team<br /> |<br /> |-<br /> |Roadmap updated to show specification release<br /> |Business Team<br /> |<br /> |}<br /> <br /> <br /> == SPDX Tools Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Tool Release Checklist<br /> |-<br /> |Tool<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Spreadsheet Template and Examples updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |SPDX Compare updated<br /> |Tech team tools group<br /> |<br /> |--<br /> |SPDX Viewer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet Template and Examples posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |SPDX Compare posted to web site<br /> |SPDX Web Admin<br /> |<br /> |--<br /> |SPDX Viewer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |}<br /> <br /> [[Category:Business]]</div>

Bschineller https://wiki.spdx.org/view/Business_Team/SPDX_2_0_Project 2014-04-15T18:26:54Z

<p>Bschineller: /* Milestones */</p> <hr /> <div><br /> '''&lt;big&gt;SPDX 2.0 Specification Project Overview&lt;/big&gt;'''<br /> <br /> __TOC__<br /> <br /> &lt;br /&gt;<br /> <br /> = Objectives =<br /> <br /> This is the next major release of the specification. SPDX 2.0 will extend the specification beyond the package level scope and enhance it to address relationships between artifacts.<br /> <br /> &lt;br /&gt;<br /> <br /> == Overall Status ==<br /> <br /> Our current plan is to try and get 2.0 done before LinuxCon North America which is roughly August 20th of this tear. Our go or no go date to see if we can make it is to have a first draft of the specification y June 1st.<br /> <br /> The specification is still under development, so we would not recommend downloading the version from this wiki page until it is further developed.<br /> <br /> We have made a lot of progress recently and there are a few artifacts that you can look at to give you and idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [[http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25 LinuxCollab Meeting Minutes ]]<br /> <br /> The current goal is to have a first draft by June of this year.<br /> <br /> <br /> &lt;br /&gt;<br /> <br /> = Milestones =<br /> <br /> The target date is set by the Milestone owner. When completed, the date will be changed to say COMPLETE. The milestone owner should also update the Status column as appropriate.<br /> <br /> {| class=&quot;wikitable sortable&quot; border=&quot;1&quot;<br /> |+ 2.0 Milestones<br /> ! align=&quot;left&quot; width=12% | Milestone<br /> ! align=&quot;left&quot; width=12% | Owner<br /> ! class=&quot;unsortable&quot; | Details<br /> ! | Target Date<br /> ! class=&quot;unsortable&quot; | Current Status<br /> |-<br /> | Use Cases<br /> | Tech Team<br /> | Collection of use cases and then prioritization on the ones that will be addressed in the 2.0 specification.<br /> | COMPLETE<br /> |<br /> |-<br /> | Requirements Overview<br /> | Kirsten Newcomer<br /> | High level requirements overview.<br /> | April 2014<br /> | Has been reviewed and pushed to the Tech report Framework. Need to publish to main site an dlink from this page as well.<br /> |-<br /> | Data Models<br /> | Tech Team<br /> | Modelling to support the new use cases. This is the model we are using: [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|Merged Model Proposal]]<br /> | June 1 2014<br /> | <br /> |-<br /> | Draft specification to start tool development<br /> | Tech Team<br /> | First draft of the specification. Can start tool development and get initial reviews by communnity. Ideally soecification should be somewhat stable to start tool development: i.e. no big changes anticipated. [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> | June 1 2014<br /> | Working through polishing the data model which was reviewed at Linux Collab. We have made a lot of progress recently and there are a few artifacts that you can look at to give you an idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25] <br /> |-<br /> | Validate Use cases<br /> | Tech Team<br /> | See use cases here: [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]. Need to valaidate these against the data model.<br /> | June 1 2014<br /> | In Progress. Several of the use cases were reviewed at Linux Collab.<br /> |-<br /> | SPDX Tools and Examples Updated<br /> | Tech Team<br /> | All SPDX tools and examples updated to support 2.0<br /> | target August 13 (D-7days)<br /> |<br /> |-<br /> | Migration Plan Draft Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Draft Review Period<br /> | Tech Team<br /> | Specification is out for review by the general community<br /> | tentative June 1-June 30<br /> |<br /> |-<br /> | SPDX 2.0 Best and Final Review Period<br /> | Tech Team<br /> | Best and final version of the specification is out for a final blessing.<br /> | tentative July 1-July 15<br /> |<br /> |-<br /> | Migration Plan Best and Final Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Launch Plan<br /> | Business Team<br /> | Launch Plan devised and in place for 2.0 release. If we want to submit papers to LinuxCons or do something at them we need to decide before May 2nd!<br /> | June 2014<br /> |<br /> |-<br /> | Press release drafted and sent to LF <br /> | Business Team<br /> | Press release announcing 2.0 is drafted and sent to LF to review and publish.<br /> | TBD<br /> |}<br /> <br /> &lt;br /&gt;<br /> <br /> = Useful Links =<br /> <br /> The following are links to useful information around the 2.0 Specification.<br /> * [[Technical_Team/Spec_Release_Process|What is a Specification Release Checklist]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]] <br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> * Bug reports (may be useful to look at those targeted against 2.0 for completion)<br /> <br /> &lt;br /&gt;<br /> <br /> = Specification Release Checklist =<br /> <br /> This checklist will be used as the Specification approaches release. It is to make sure we do no forget something.<br /> <br /> == Specification Review Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Review Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification of start of work on a new version to the General List (with summary)<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version (points to google doc repro)<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that draft is under way<br /> |Web Admin<br /> |<br /> |}<br /> <br /> == SPDX Specification / Document Collateral Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Release Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification on general list that the specification is approved<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version<br /> |Web Admin<br /> |<br /> |-<br /> |RDF terms page updated<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that there is a new version<br /> |Web Admin<br /> |<br /> |-<br /> |Press release (via Linux Foundation) for the new version<br /> |Business Team<br /> |<br /> |-<br /> |Roadmap updated to show specification release<br /> |Business Team<br /> |<br /> |}<br /> <br /> <br /> == SPDX Tools Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Tool Release Checklist<br /> |-<br /> |Tool<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Spreadsheet Template and Examples updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |SPDX Compare updated<br /> |Tech team tools group<br /> |<br /> |--<br /> |SPDX Viewer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet Template and Examples posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |SPDX Compare posted to web site<br /> |SPDX Web Admin<br /> |<br /> |--<br /> |SPDX Viewer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |}<br /> <br /> [[Category:Business]]</div>

Bschineller https://wiki.spdx.org/view/Business_Team/SPDX_2_0_Project 2014-04-15T18:20:29Z

<p>Bschineller: /* Milestones */</p> <hr /> <div><br /> '''&lt;big&gt;SPDX 2.0 Specification Project Overview&lt;/big&gt;'''<br /> <br /> __TOC__<br /> <br /> &lt;br /&gt;<br /> <br /> = Objectives =<br /> <br /> This is the next major release of the specification. SPDX 2.0 will extend the specification beyond the package level scope and enhance it to address relationships between artifacts.<br /> <br /> &lt;br /&gt;<br /> <br /> == Overall Status ==<br /> <br /> Our current plan is to try and get 2.0 done before LinuxCon North America which is roughly August 20th of this tear. Our go or no go date to see if we can make it is to have a first draft of the specification y June 1st.<br /> <br /> The specification is still under development, so we would not recommend downloading the version from this wiki page until it is further developed.<br /> <br /> We have made a lot of progress recently and there are a few artifacts that you can look at to give you and idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [[http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25 LinuxCollab Meeting Minutes ]]<br /> <br /> The current goal is to have a first draft by June of this year.<br /> <br /> <br /> &lt;br /&gt;<br /> <br /> = Milestones =<br /> <br /> The target date is set by the Milestone owner. When completed, the date will be changed to say COMPLETE. The milestone owner should also update the Status column as appropriate.<br /> <br /> {| class=&quot;wikitable sortable&quot; border=&quot;1&quot;<br /> |+ 2.0 Milestones<br /> ! align=&quot;left&quot; width=12% | Milestone<br /> ! align=&quot;left&quot; width=12% | Owner<br /> ! class=&quot;unsortable&quot; | Details<br /> ! | Target Date<br /> ! class=&quot;unsortable&quot; | Current Status<br /> |-<br /> | Use Cases<br /> | Tech Team<br /> | Collection of use cases and then prioritization on the ones that will be addressed in the 2.0 specification.<br /> | COMPLETE<br /> |<br /> |-<br /> | Requirements Overview<br /> | Kirsten Newcomer<br /> | High level requirements overview.<br /> | April 2014<br /> | Has been reviewed and pushed to the Tech report Framework. Need to publish to main site an dlink from this page as well.<br /> |-<br /> | Data Models<br /> | Tech Team<br /> | Modelling to support the new use cases. This is the model we are using: [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|Merged Model Proposal]]<br /> | June 1 2014<br /> | <br /> |-<br /> | Draft specification to start tool development<br /> | Tech Team<br /> | First draft of the specification. Can start tool development and get initial reviews by communnity. Ideally soecification should be somewhat stable to start tool development: i.e. no big changes anticipated. [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> | June 1 2014<br /> | Working through polishing the data model which was reviewed at Linux Collab. We have made a lot of progress recently and there are a few artifacts that you can look at to give you an idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25] <br /> |-<br /> | Validate Use cases<br /> | Tech Team<br /> | See use cases here: [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]. Need to valaidate these against the data model.<br /> | June 1 2014<br /> | In Progress. Several of the use cases were reviewed at Linux Collab.<br /> |-<br /> | SPDX Tools and Examples Updated<br /> | Tech Team<br /> | All SPDX tools and examples updated to support 2.0<br /> | TBD<br /> |<br /> |-<br /> | Migration Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Draft Review Period<br /> | Tech Team<br /> | Specification is out for review by the general community<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Best and Final Review Period<br /> | Tech Team<br /> | Best and final version of the speicification is out for a final blessing.<br /> | TBD<br /> |<br /> |-<br /> | Migration Plan Best and Final Review Period<br /> | Tech Team<br /> | How to go from v1.2 documents to 2.0 format <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Launch Plan<br /> | Business Team<br /> | Launch Plan devised and in place for 2.0 release. If we want to submit papers to LinuxCons or do something at them we need to decide before May 2nd!<br /> | June 2014<br /> |<br /> |-<br /> | Press release drafted and sent to LF <br /> | Business Team<br /> | Press release announcing 2.0 is drafted and sent to LF to review and publish.<br /> | TBD<br /> |}<br /> <br /> &lt;br /&gt;<br /> <br /> = Useful Links =<br /> <br /> The following are links to useful information around the 2.0 Specification.<br /> * [[Technical_Team/Spec_Release_Process|What is a Specification Release Checklist]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]] <br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> * Bug reports (may be useful to look at those targeted against 2.0 for completion)<br /> <br /> &lt;br /&gt;<br /> <br /> = Specification Release Checklist =<br /> <br /> This checklist will be used as the Specification approaches release. It is to make sure we do no forget something.<br /> <br /> == Specification Review Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Review Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification of start of work on a new version to the General List (with summary)<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version (points to google doc repro)<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that draft is under way<br /> |Web Admin<br /> |<br /> |}<br /> <br /> == SPDX Specification / Document Collateral Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Release Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification on general list that the specification is approved<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version<br /> |Web Admin<br /> |<br /> |-<br /> |RDF terms page updated<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that there is a new version<br /> |Web Admin<br /> |<br /> |-<br /> |Press release (via Linux Foundation) for the new version<br /> |Business Team<br /> |<br /> |-<br /> |Roadmap updated to show specification release<br /> |Business Team<br /> |<br /> |}<br /> <br /> <br /> == SPDX Tools Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Tool Release Checklist<br /> |-<br /> |Tool<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Spreadsheet Template and Examples updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |SPDX Compare updated<br /> |Tech team tools group<br /> |<br /> |--<br /> |SPDX Viewer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet Template and Examples posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |SPDX Compare posted to web site<br /> |SPDX Web Admin<br /> |<br /> |--<br /> |SPDX Viewer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |}<br /> <br /> [[Category:Business]]</div>

Bschineller https://wiki.spdx.org/view/Business_Team/SPDX_2_0_Project 2014-04-15T18:19:06Z

<p>Bschineller: /* Milestones */</p> <hr /> <div><br /> '''&lt;big&gt;SPDX 2.0 Specification Project Overview&lt;/big&gt;'''<br /> <br /> __TOC__<br /> <br /> &lt;br /&gt;<br /> <br /> = Objectives =<br /> <br /> This is the next major release of the specification. SPDX 2.0 will extend the specification beyond the package level scope and enhance it to address relationships between artifacts.<br /> <br /> &lt;br /&gt;<br /> <br /> == Overall Status ==<br /> <br /> Our current plan is to try and get 2.0 done before LinuxCon North America which is roughly August 20th of this tear. Our go or no go date to see if we can make it is to have a first draft of the specification y June 1st.<br /> <br /> The specification is still under development, so we would not recommend downloading the version from this wiki page until it is further developed.<br /> <br /> We have made a lot of progress recently and there are a few artifacts that you can look at to give you and idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [[http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25 LinuxCollab Meeting Minutes ]]<br /> <br /> The current goal is to have a first draft by June of this year.<br /> <br /> <br /> &lt;br /&gt;<br /> <br /> = Milestones =<br /> <br /> The target date is set by the Milestone owner. When completed, the date will be changed to say COMPLETE. The milestone owner should also update the Status column as appropriate.<br /> <br /> {| class=&quot;wikitable sortable&quot; border=&quot;1&quot;<br /> |+ 2.0 Milestones<br /> ! align=&quot;left&quot; width=12% | Milestone<br /> ! align=&quot;left&quot; width=12% | Owner<br /> ! class=&quot;unsortable&quot; | Details<br /> ! | Target Date<br /> ! class=&quot;unsortable&quot; | Current Status<br /> |-<br /> | Use Cases<br /> | Tech Team<br /> | Collection of use cases and then prioritization on the ones that will be addressed in the 2.0 specification.<br /> | COMPLETE<br /> |<br /> |-<br /> | Requirements Overview<br /> | Kirsten Newcomer<br /> | High level requirements overview.<br /> | April 2014<br /> | Has been reviewed and pushed to the Tech report Framework. Need to publish to main site an dlink from this page as well.<br /> |-<br /> | Data Models<br /> | Tech Team<br /> | Modelling to support the new use cases. This is the model we are using: [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|Merged Model Proposal]]<br /> | June 1 2014<br /> | <br /> |-<br /> | Draft specification to start tool development<br /> | Tech Team<br /> | First draft of the specification. Can start tool development and get initial reviews by communnity. Ideally soecification should be somewhat stable to start tool development: i.e. no big changes anticipated. [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> | June 1 2014<br /> | Working through polishing the data model which was reviewed at Linux Collab. We have made a lot of progress recently and there are a few artifacts that you can look at to give you an idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25] <br /> |-<br /> | Validate Use cases<br /> | Tech Team<br /> | See use cases here: [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]. Need to valaidate these against the data model.<br /> | June 1 2014<br /> | In Progress. Several of the use cases were reviewed at Linux Collab.<br /> |-<br /> | SPDX Tools and Examples Updated<br /> | Tech Team<br /> | All SPDX tools and examples updated to support 2.0<br /> | TBD<br /> |<br /> |-<br /> | Migration Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Draft Review Period<br /> | Tech Team<br /> | Specification is out for review by the general community<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Best and Final Review Period<br /> | Tech Team<br /> | Best and final version of the speicification is out for a final blessing.<br /> | TBD<br /> |<br /> |-<br /> | Migration Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Launch Plan<br /> | Business Team<br /> | Launch Plan devised and in place for 2.0 release. If we want to submit papers to LinuxCons or do something at them we need to decide before May 2nd!<br /> | June 2014<br /> |<br /> |-<br /> | Press release drafted and sent to LF <br /> | Business Team<br /> | Press release announcing 2.0 is drafted and sent to LF to review and publish.<br /> | TBD<br /> |}<br /> <br /> &lt;br /&gt;<br /> <br /> = Useful Links =<br /> <br /> The following are links to useful information around the 2.0 Specification.<br /> * [[Technical_Team/Spec_Release_Process|What is a Specification Release Checklist]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]] <br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> * Bug reports (may be useful to look at those targeted against 2.0 for completion)<br /> <br /> &lt;br /&gt;<br /> <br /> = Specification Release Checklist =<br /> <br /> This checklist will be used as the Specification approaches release. It is to make sure we do no forget something.<br /> <br /> == Specification Review Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Review Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification of start of work on a new version to the General List (with summary)<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version (points to google doc repro)<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that draft is under way<br /> |Web Admin<br /> |<br /> |}<br /> <br /> == SPDX Specification / Document Collateral Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Release Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification on general list that the specification is approved<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version<br /> |Web Admin<br /> |<br /> |-<br /> |RDF terms page updated<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that there is a new version<br /> |Web Admin<br /> |<br /> |-<br /> |Press release (via Linux Foundation) for the new version<br /> |Business Team<br /> |<br /> |-<br /> |Roadmap updated to show specification release<br /> |Business Team<br /> |<br /> |}<br /> <br /> <br /> == SPDX Tools Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Tool Release Checklist<br /> |-<br /> |Tool<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Spreadsheet Template and Examples updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |SPDX Compare updated<br /> |Tech team tools group<br /> |<br /> |--<br /> |SPDX Viewer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet Template and Examples posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |SPDX Compare posted to web site<br /> |SPDX Web Admin<br /> |<br /> |--<br /> |SPDX Viewer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |}<br /> <br /> [[Category:Business]]</div>

Bschineller https://wiki.spdx.org/view/Business_Team/SPDX_2_0_Project 2014-04-15T18:18:23Z

<p>Bschineller: /* Useful Links */</p> <hr /> <div><br /> '''&lt;big&gt;SPDX 2.0 Specification Project Overview&lt;/big&gt;'''<br /> <br /> __TOC__<br /> <br /> &lt;br /&gt;<br /> <br /> = Objectives =<br /> <br /> This is the next major release of the specification. SPDX 2.0 will extend the specification beyond the package level scope and enhance it to address relationships between artifacts.<br /> <br /> &lt;br /&gt;<br /> <br /> == Overall Status ==<br /> <br /> Our current plan is to try and get 2.0 done before LinuxCon North America which is roughly August 20th of this tear. Our go or no go date to see if we can make it is to have a first draft of the specification y June 1st.<br /> <br /> The specification is still under development, so we would not recommend downloading the version from this wiki page until it is further developed.<br /> <br /> We have made a lot of progress recently and there are a few artifacts that you can look at to give you and idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [[http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25 LinuxCollab Meeting Minutes ]]<br /> <br /> The current goal is to have a first draft by June of this year.<br /> <br /> <br /> &lt;br /&gt;<br /> <br /> = Milestones =<br /> <br /> The target date is set by the Milestone owner. When completed, the date will be changed to say COMPLETE. The milestone owner should also update the Status column as appropriate.<br /> <br /> {| class=&quot;wikitable sortable&quot; border=&quot;1&quot;<br /> |+ 2.0 Milestones<br /> ! align=&quot;left&quot; width=12% | Milestone<br /> ! align=&quot;left&quot; width=12% | Owner<br /> ! class=&quot;unsortable&quot; | Details<br /> ! | Target Date<br /> ! class=&quot;unsortable&quot; | Current Status<br /> |-<br /> | Use Cases<br /> | Tech Team<br /> | Collection of use cases and then prioritization on the ones that will be addressed in the 2.0 specification.<br /> | COMPLETE<br /> |<br /> |-<br /> | Requirements Overview<br /> | Kirsten Newcomer<br /> | High level requirements overview.<br /> | April 2014<br /> | Has been reviewed and pushed to the Tech report Framework. Need to publish to main site an dlink from this page as well.<br /> |-<br /> | Data Models<br /> | Tech Team<br /> | Modelling to support the new use cases. This is the model we are using: [[Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal|Merged Model Proposal]]<br /> | June 1 2014<br /> | <br /> |-<br /> | Draft specification to start tool development<br /> | Tech Team<br /> | First draft of the specification. Can start tool development and get initial reviews by communnity. Ideally soecification should be somewhat stable to start tool development: i.e. no big changes anticipated.<br /> | June 1 2014<br /> | Working through polishing the data model which was reviewed at Linux Collab. We have made a lot of progress recently and there are a few artifacts that you can look at to give you an idea on the 2.0 spec. The best starting point is the minutes from the Linux Collab Summit: [http://wiki.spdx.org/view/Technical_Team/Minutes/2014-03-25] <br /> |-<br /> | Validate Use cases<br /> | Tech Team<br /> | See use cases here: [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]]. Need to valaidate these against the data model.<br /> | June 1 2014<br /> | In Progress. Several of the use cases were reviewed at Linux Collab.<br /> |-<br /> | SPDX Tools and Examples Updated<br /> | Tech Team<br /> | All SPDX tools and examples updated to support 2.0<br /> | TBD<br /> |<br /> |-<br /> | Migration Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in <br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Draft Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Draft Review Period<br /> | Tech Team<br /> | Specification is out for review by the general community<br /> | TBD<br /> |<br /> |-<br /> | SPDX 2.0 Best and Final Review Period<br /> | Tech Team<br /> | Best and final version of the speicification is out for a final blessing.<br /> | TBD<br /> |<br /> |-<br /> | Migration Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Transition Plan Best and Final Review Period<br /> | Tech Team<br /> | Fill me in<br /> | TBD<br /> |<br /> |-<br /> | Launch Plan<br /> | Business Team<br /> | Launch Plan devised and in place for 2.0 release. If we want to submit papers to LinuxCons or do something at them we need to decide before May 2nd!<br /> | June 2014<br /> |<br /> |-<br /> | Press release drafted and sent to LF <br /> | Business Team<br /> | Press release announcing 2.0 is drafted and sent to LF to review and publish.<br /> | TBD<br /> |}<br /> <br /> &lt;br /&gt;<br /> <br /> = Useful Links =<br /> <br /> The following are links to useful information around the 2.0 Specification.<br /> * [[Technical_Team/Spec_Release_Process|What is a Specification Release Checklist]]<br /> * [[Technical_Team/Use_Cases/2.0|SPDX 2.0 Use Cases]] <br /> * [[Technical_Team/Proposals/SPDX_2.0_Model_Proposals|SPDX 2.0 Model Proposals]]<br /> * [[Technical_Team/SPDX_Specification_Versions| SPDX_Specification_Versions (see dated 2.0 drafts)]]<br /> * Bug reports (may be useful to look at those targeted against 2.0 for completion)<br /> <br /> &lt;br /&gt;<br /> <br /> = Specification Release Checklist =<br /> <br /> This checklist will be used as the Specification approaches release. It is to make sure we do no forget something.<br /> <br /> == Specification Review Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Review Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification of start of work on a new version to the General List (with summary)<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version (points to google doc repro)<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that draft is under way<br /> |Web Admin<br /> |<br /> |}<br /> <br /> == SPDX Specification / Document Collateral Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Specification Release Checklist<br /> |-<br /> |Item<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Notification on general list that the specification is approved<br /> |Tech team lead<br /> |<br /> |-<br /> |Web site updated with page to hold new spec version<br /> |Web Admin<br /> |<br /> |-<br /> |RDF terms page updated<br /> |Web Admin<br /> |<br /> |-<br /> |Web site news announcement (in banner area) that there is a new version<br /> |Web Admin<br /> |<br /> |-<br /> |Press release (via Linux Foundation) for the new version<br /> |Business Team<br /> |<br /> |-<br /> |Roadmap updated to show specification release<br /> |Business Team<br /> |<br /> |}<br /> <br /> <br /> == SPDX Tools Release Checklist ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;text-align: left; border-spacing: 0; border: 1px solid #000; padding: 4px;&quot; <br /> |+Tool Release Checklist<br /> |-<br /> |Tool<br /> |Who is Responsible<br /> |Status<br /> |-<br /> |Spreadsheet Template and Examples updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |SPDX Compare updated<br /> |Tech team tools group<br /> |<br /> |--<br /> |SPDX Viewer updated<br /> |Tech team tools group<br /> |<br /> |-<br /> |Spreadsheet Template and Examples posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to Tag and Tag to RDF Translators posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |RDF to HTML Pretty Printer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |Spreadsheet to RDF and RDF to spreadsheet posted to web site<br /> |SPDX Web Admin<br /> |<br /> |-<br /> |SPDX Compare posted to web site<br /> |SPDX Web Admin<br /> |<br /> |--<br /> |SPDX Viewer posted to web site<br /> |SPDX Web Admin<br /> |<br /> |}<br /> <br /> [[Category:Business]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Minutes/2014-01-07 2014-01-14T19:15:56Z

<p>Bschineller: /* 2014 Kickoff / Schedule */</p> <hr /> <div>Jan 7, 2014<br /> == Attendees ==<br /> * Bill Schineller<br /> * Kate Stewart<br /> * Mark Gisi<br /> * Marshall Clow<br /> * Scott Sterling<br /> == Agenda ==<br /> Recap recent events<br /> 2014 Kickoff / Schedule of Events<br /> SPDX 2.0 Draft editing logistics<br /> == Recent events ==<br /> * Open Compliance Summit (Japan)<br /> ** Kate and Mark Germonprez presented SPDX / fossology work<br /> ** Samsung presented<br /> ** wide awareness of SPDX in Asia<br /> ** Mike Dolan of Linux Foundation: &quot;what's needed by SPDX&quot;?<br /> ** Q by Mark Gisi on our call: what's behind fear of producing SPDX?<br /> *** size of files, work to produce (Kate did show UNO and Windriver tools), lack of expressiveness of binary-source package connection<br /> == 2014 Kickoff / Schedule ==<br /> * March 26-28 Linux Collab Summit<br /> * Schedule idea for the year:<br /> ** Collab: Draft 2.0 and reference examples<br /> ** LinuxCon: Release 2.0<br /> *** Spec and tools<br /> ** Q4: plug fest<br /> *** a supply-chain example? (producer-&gt; consumer-&gt; producer -&gt; consumer...)<br /> <br /> == SPDX 2.0 Draft editing logistics==<br /> * 2 documents:<br /> ** Kate to attach a '2.0 Draft' Word doc to wiki (start out as exact 1.2, awaiting edits)<br /> ** 1.2 -&gt; 2.0 Migrations Google Spreadsheet</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Minutes/2014-01-07 2014-01-14T19:13:33Z

<p>Bschineller: </p> <hr /> <div>Jan 7, 2014<br /> == Attendees ==<br /> * Bill Schineller<br /> * Kate Stewart<br /> * Mark Gisi<br /> * Marshall Clow<br /> * Scott Sterling<br /> == Agenda ==<br /> Recap recent events<br /> 2014 Kickoff / Schedule of Events<br /> SPDX 2.0 Draft editing logistics<br /> == Recent events ==<br /> * Open Compliance Summit (Japan)<br /> ** Kate and Mark Germonprez presented SPDX / fossology work<br /> ** Samsung presented<br /> ** wide awareness of SPDX in Asia<br /> ** Mike Dolan of Linux Foundation: &quot;what's needed by SPDX&quot;?<br /> ** Q by Mark Gisi on our call: what's behind fear of producing SPDX?<br /> *** size of files, work to produce (Kate did show UNO and Windriver tools), lack of expressiveness of binary-source package connection<br /> == 2014 Kickoff / Schedule ==<br /> * March 26-28 Linux Collab Summit<br /> * Schedule idea for the year:<br /> ** Collab: Draft 2.0 and reference examples<br /> ** LinuxCon: Release 2.0<br /> ** Q4: tools implementation and plug fest<br /> *** a supply-chain example? (producer-&gt; consumer-&gt; producer -&gt; consumer...)<br /> == SPDX 2.0 Draft editing logistics==<br /> * 2 documents:<br /> ** Kate to attach a '2.0 Draft' Word doc to wiki (start out as exact 1.2, awaiting edits)<br /> ** 1.2 -&gt; 2.0 Migrations Google Spreadsheet</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Minutes/2014-01-07 2014-01-14T19:06:13Z

<p>Bschineller: Created page with &quot;Jan 7, 2014 == Attendees == * Bill Schineller * Kate Stewart * Mark Gisi * Marshall * Scott Sterling == Agenda == Recap recent events 2014 Kickoff / Schedule of Events SPDX 2....&quot;</p> <hr /> <div>Jan 7, 2014<br /> == Attendees ==<br /> * Bill Schineller<br /> * Kate Stewart<br /> * Mark Gisi<br /> * Marshall<br /> * Scott Sterling<br /> == Agenda ==<br /> Recap recent events<br /> 2014 Kickoff / Schedule of Events<br /> SPDX 2.0 Draft editing logistics<br /> == Recent events ==<br /> * Open Compliance Summit (Japan)<br /> ** Kate and Mark Germanprende presented SPDX / fossology work<br /> ** Samsung presented<br /> ** wide awareness of SPDX in Asia<br /> ** Mike Dolan of Linux Foundation: &quot;what's needed by SPDX&quot;?<br /> ** Q by Mark Gisi on our call: what's behind fear of producing SPDX?<br /> *** size of files, work to produce (Kate did show UNO and Windriver tools), lack of expressiveness of binary-source package connection<br /> == 2014 Kickoff / Schedule ==<br /> * March 26-28 Linux Collab Summit<br /> * Schedule idea for the year:<br /> ** Collab: Draft 2.0 and reference examples<br /> ** LinuxCon: Release 2.0<br /> ** Q4: tools implementation and plug fest<br /> *** a supply-chain example? (producer-&gt; consumer-&gt; producer -&gt; consumer...)<br /> == SPDX 2.0 Draft editing logistics==<br /> * 2 documents:<br /> ** Kate to attach a '2.0 Draft' Word doc to wiki (start out as exact 1.2, awaiting edits)<br /> ** 1.2 -&gt; 2.0 Migrations Google Spreadsheet</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/Build_System_Yocto 2013-05-21T18:18:50Z

<p>Bschineller: </p> <hr /> <div>'''Title:''' Yocto Build System<br /> <br /> UPDATE 05/21/2013: Yocto project is actively trying to utilize SPDX. Here's a writeup they did https://bugzilla.yoctoproject.org/show_bug.cgi?id=4516<br /> <br /> '''Background:'''<br /> <br /> Note: This is not a detailed background. You are encouraged to read up on the Yocto Project by using the following link: http://www.yoctoproject.org/docs/1.0/yocto-quick-start/yocto-project-qs.html<br /> <br /> The Yocto Project provides a build system which can be used to provide, as an example, a file system/kernel/boot loader image that can be downloaded onto a device and executed. When Yocto builds a package the package source can come from various sources such as source code control system like GIT, a tarball, patches and so forth. Entities providng a Yocto build for their hardware may also be providing pacthes for the package.Whenever a build is executed, it is possible that the files in a package are updated (added, modified, removed, etc).<br /> <br /> Yocto uses recipes to build packages. These recipes do contain a License field. The current short names do not match SPDX short names and likely will not. It was rather difficult to get alignment on the current ones used. There is talk on the Yocto project about converting the Yocto short names into SPDX ones.<br /> <br /> '''Primary Actors:'''<br /> <br /> Yocto User: Receives a Yocto build for a device. Executes the build.<br /> <br /> Package Maintainer: These are upstream projects that a Yocto based build consumes. This upstream project could be a company that provides a package as well. A Package Maintainer could be viewed as having a secondary interest in this use case as their package may be consumed by a Yocto build even though they as packages maintainers have no vested interest in Yocto.<br /> <br /> the Yocto Project: Provides the Yocto build system.<br /> <br /> Build System Provider: They provide a Yocto based build, for example for their product. They may also provide patches to Packages that the recipes pull or may even add their own packages.<br /> <br /> '''Goal in Context:''' To execute a Yocto based build and generate an image for a hardware device or simulator and to have SPDX documents that describe the licensing for all copyrightable artifacts pulled in by the build system and used to generate that image (i.e. not just artifacts that make it into the image, everything and everything that it pulls including the build system). Note: envision we could be talking about 1000's of related SPDX documents<br /> <br /> '''Stakeholders and Interests:'''<br /> <br /> Yocto User:<br /> <br /> A. To receive accurate and clear information of licensing for all copyrightable<br /> <br /> elements used in the build and for the build system.<br /> <br /> B. To be able to comply easily with licenses for all copyrightable elements used in<br /> <br /> the build and the build system.<br /> <br /> 2. Package Maintainer:<br /> <br /> A. To communicate the license information for their package.<br /> <br /> B. To have their licenses respected.<br /> <br /> 3. the Yocto Project:<br /> <br /> A. To communicate the license information for their build system and the licensing of each package<br /> <br /> (currently via the license field in a recipe).<br /> <br /> B. To have their licenses respected.<br /> <br /> 4. Build System Provider:<br /> <br /> A. To communicate the licensing information for the build they are providing.<br /> <br /> B. To comply with all the licenses used in the build the system they are providing.<br /> <br /> '''Preconditions:'''<br /> <br /> # A yocoto build is created.<br /> # Packages used in the Yocoto build have SPDX documents describing the copyrigthable elements of the package.<br /> # A patch for a package used in the build is created.<br /> <br /> '''Main Success Scenario:''' A user executing a Yocto based build gets SPDX documents that describe the licensing for all copyrightable elements that were used to create the build and are the result of a build.<br /> <br /> '''Failed End Condition:''' Inaccurate or incomplete licensing information is provided for all packages used in the build and/or for the Yocto build system.<br /> <br /> '''Trigger:'''<br /> <br /> A Yocto user executes a build.<br /> <br /> Note: I forgot a point around RPMs when doing this and need to follow up again with the Yocto Project.<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-05-21T18:17:20Z

<p>Bschineller: </p> <hr /> <div>We have several sources to begin pulling for SPDX Use Cases:<br /> <br /> # The Pad from earlier conversations collected at [[Technical_Team/Old/Use_Cases_Collected_during_1.x_timeframe|Use Cases For SPDX 2.0 Discussion]]<br /> # 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]].<br /> <br /> == Use Cases ==<br /> <br /> 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.<br /> <br /> # Code commits (original work intended for the project)<br /> ## [[Technical_Team/Use_Cases/2.0/Committers_provides_SPDX_data_for_a_code_being_committed|Committer provides SPDX data]] [OK]<br /> ## [[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]<br /> # [[Technical_Team/Use_Cases/2.0/Committer_annotates_source_files_with_SPDX_data|Committer annotates source files with SPDX data]] [OK]<br /> # Patches (original work intended for the project)<br /> ## [[Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch|Patch provider provides SPDX data for the patch]] [OK]<br /> ## [[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]<br /> ## [[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]<br /> # Patch provider provides a patch that modifies existing SPDX data of project<br /> ## [[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]<br /> ## [[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]<br /> # [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data|Upstream maintainer providing SPDX data]]<br /> ## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_source_archive|Upstream maintainer providing SPDX data in source archive]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_in_SCM|Upstream maintainer providing SPDX data in SCM]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_providing_SPDX_data_at_a_URL|Upstream maintainer providing SPDX data at a URL]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Upstream_maintainer_preparing_release_artifacts_(including_SPDX_data)|Upstream maintainer preparing release artifacts (including SPDX data).]] [OK]<br /> # Project maintainer incorporates another project<br /> ## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_source|Project maintainer incorporates another project by including source]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Project_maintainer_incorporates_another_project_by_including_binary|Project maintainer incorporates another project by including binary]] [OK]<br /> ## [[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]<br /> # Ease adoption<br /> ## [[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]<br /> ## [[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]<br /> # Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data<br /> ## Intermediate packager builds source package from upstream source<br /> ### [[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]<br /> ### [[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]<br /> ## Intermediate packager builds binary package from upstream source<br /> ### [[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]<br /> ### [[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]]<br /> ## Intermediate packager adds patches to upstream source<br /> ### [[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]<br /> ### [[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]]<br /> ## Intermediate packager adds someone else's patches to upstream source<br /> ### [[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]<br /> ### [[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]<br /> ## Intermediate packager subsetting upstream source<br /> ### [[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]<br /> ### [[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]]<br /> # Build systems (build systems want to pass on SPDX data for the thing they are building)<br /> ## [[Technical_Team/Use_Cases/2.0/Build_System_Yocto|Yocto]] [OK]<br /> ## Linking<br /> ### [[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]<br /> ## I just made a binary out of some source<br /> ### [[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]<br /> # Aggregator aggregating many 'copyrightable items' for redistribution<br /> ## [[Technical_Team/Use_Cases/2.0/Linux_Distros|Linux Distros]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Embedded_Images_(e.g._router_images,_switch_images)|Embedded Images (e.g. router images, switch images)]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Reference_Implementations|Reference implementations]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_documentation_and_media_and_software|Application which ships with documentation + media + software]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_a_contrib_libraries|Application which ships with a contrib libraries]] [OK]<br /> ## [[Technical_Team/Use_Cases/2.0/Application_which_ships_with_development_tools|Application which ships with development tools]] [OK]<br /> ## [[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]<br /> ## [[Technical_Team/Use_Cases/2.0/Aggregators_aggregating_other_aggregations_for_redistribution|Aggregators aggregating other aggregations for redistribution]] [OK]<br /> # Consumers receiving SPDX data<br /> ## [[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]<br /> # [[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]<br /> # Signoff/multiple signoff on SPDX data<br /> ## [[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]<br /> # Third party does licensing analysis<br /> ## [[Technical_Team/Use_Cases/2.0/Third_party_produces_bill_of_materials_for_software_package|Third party generates license analysis]] [OK]<br /> ## [[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]<br /> # Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed<br /> ## [[Technical_Team/Use_Cases/2.0/Backtrack_from_binary_to_source_files|Backtrack from compiled/binary file to constituent files]] [MORE STUDY NEEDED]<br /> ## outbound: validate that SPDX goes hand in hand with what's being shipped (Kirsten Newcomer)<br /> ### [[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]<br /> # Extensions:<br /> ## [[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]<br /> ## [[Technical_Team/Use_Cases/2.0/License_list_extension|License list extensions, how do you handle folks who have more licenses than SPDX]] [OK]<br /> ## [[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]<br /> # Other arising during vetting...<br /> ## 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]<br /> <br /> == Cross-cutting concerns ==<br /> <br /> # Provenance (the need to optionally use signing to validate who said what)<br /> # Trust<br /> # Handling staleness of data<br /> # Composite licensing<br /> # Ease of sharing information<br /> ## Collecting tribal knowledge along the way<br /> # Guarding against file bloat<br /> # Simple simple simple<br /> # SPDX-Lite: here's interest in something SPDX-Lite like https://bugzilla.yoctoproject.org/show_bug.cgi?id=4516 <br /> # Clarity<br /> # Automation/toolifiability<br /> # Regionality<br /> <br /> ==Themes==<br /> <br /> Looking at these Use Cases, there are some underlying themes:<br /> <br /> # Root of data (closer to upstream the better)<br /> # Subsetting of copyrightable things (and their SPDX data) ('''Note''': Subsets of copyrightable things are usually also copyrightable things)<br /> # Aggregation of copyrightable things (and their SPDX data) ('''Note''': Aggregations of copyrightable things are usually also copyrightable things).<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Minutes/2013-04-16 2013-04-23T18:20:18Z

<p>Bschineller: </p> <hr /> <div><br /> == '''Agenda for Technical Team meeting at Linux Collab 4/16''' ==<br /> <br /> === Participants ===<br /> <br /> * Gary O'Neall (Source Auditor)<br /> * Jack Manbeck (TI)<br /> * Kate Stewart (Linaro)<br /> * Dennis Clark (NexB)<br /> * Kirsten Newcomer (Blackduck)<br /> * Liang Cao (UNO)<br /> * Martin Michelmayer (HP)<br /> * Daniel German (UVic)<br /> * Norman Glaude (protecode)<br /> * Beth &quot;Pidge&quot; Flanagan (intel/yocto)<br /> * Michael Neuling (NexB)<br /> * Daniel Coley (Juniper)<br /> * Brandon (Cisco)<br /> <br /> === Agenda ===<br /> * Best Practices/Usage of SPEC document <br /> ** get to outline and see who's interest in participaing in filling it in.<br /> * SPDX 2.0 planning<br /> ** Review straw man model - Gary<br /> ** Instance diagram review? - Jack/Bill<br /> ** Distribution of packages use case <br /> *** will straw man handle? - cross check with Yocto<br /> *** reasonable abstraction of elements - consistent<br /> ** Other key use cases want to cross check?<br /> <br /> == Minutes ==<br /> <br /> ===Reviewed Proposed Merged model. ===<br /> * Current model: http://wiki.spdx.org/index.php/File:Model-4-16-2013.png<br /> * Decision to merge Document and Element.<br /> * Decision to consider Document, Package, File, Snippet as sub classes of Elements.<br /> * Snippets: byte ranges as sub class of Element. Multiple elements, overlap range.<br /> ** Not required, but permit and support, as sub case of elements. <br /> ** File is 0..#(EOF byte). <br /> ** snippet is '''only''' valid if it has a relationship to a file. &quot;is part of&quot;.<br /> <br /> === SPDX Element===<br /> * relationship: see Relationship Enumeration (w/Verification code of other element)<br /> * usage : see Element Usage Enumeration<br /> * license: see Licence classe<br /> * verification code<br /> * comment (by creator) 0:1<br /> * annotation (by reviewer) 0:* - text, property of reviewer <br /> * sub classes:<br /> ** Document:<br /> ** Package:<br /> ** File:<br /> ** Snippet: <br /> <br /> ===Reviewer===<br /> * property of a Document.<br /> * comments are reflected as annotation<br /> <br /> ===Relationship Enumeration===<br /> * &quot;is part of&quot; <br /> * &quot;contains&quot;<br /> * &quot;generated from&quot;<br /> * &quot;generates&quot;<br /> * &quot;is same as&quot; -- snippet discussion<br /> * &quot;modifies&quot;<br /> * &quot;modified by&quot;<br /> * &quot;revision of&quot; -- may want to evolove reviewer, document, code, auditor, intent of modifier....<br /> <br /> ?? how represent a revision of an SPDX file? provenance, adjustments?? derived from.<br /> <br /> ===Element Usage Enumeration===<br /> * source<br /> * executable<br /> * dynamic library<br /> * static library<br /> * data files (image, audio, visuals, etc.)<br /> * test (data, frameworks)<br /> * build tools<br /> * documentation (man, README, SPDX, DEP5, etc.)<br /> * reference implementation<br /> * <br /> <br /> '''WORKFLOW''' is a 3.1 issue.</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Proposals/2012-02-01/Merged_Model_Proposal 2013-04-23T18:16:45Z

<p>Bschineller: </p> <hr /> <div>Below is a class diagram merging Ed Warnicke's proposed SPDX Element model with the 1.0 model. Definately a work in progress. Most of the class definitions can be found in the 1.0 spec in the RDF appendix (model) or in [[Technical_Team/Proposals/Rough_proposal_for_provenance,_hierarchy_and_aggregation,_and_supply_chain_friendliness_in_SPDX_2.0|Ed's proposal]].<br /> <br /> The goals of this proposal are to:<br /> <br /> * Support the use cases for the 2.0 spec<br /> * Support the supply chain use cases<br /> * Support the &quot;hierarchical&quot; or embedded package use cases<br /> * Provide a more abstract model which can simplify the application of SPDX to some of the more complex use cases<br /> <br /> This proposal extends the existing proposals by adding an SPDX Element Relationship which describes the type of relationship from one SPDX element to another.<br /> <br /> See the attached document for the mapping between the SPDX 1.0 properties and this proposal.<br /> <br /> See the attached document for a proposal on creating RDF references to other Licensable documents which can be verified through checksums.<br /> <br /> Model updated per minutes of 2013 Linux Collab Summit:<br /> <br /> http://wiki.spdx.org/view/Technical_Team/Minutes/2013-04-16<br /> <br /> [[Image:Model-4-16-2013.png|909px|Class Diagram]]<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team 2013-04-23T18:04:33Z

<p>Bschineller: </p> <hr /> <div>This is the working area for the technical team. This team has primary responsibility for drafting the specification and developing documentation, templates, samples and tools.<br /> <br /> The Technical Team meets weekly on Tuesdays at 19:00 GMT (11:00AM PT, 12:00 MT, 1:00PM CT, 2:00PM ET).<br /> Dial-in number: 8.77.4350230 (U.S. and Canada) or 1.253.336.6732 (International)<br /> Conference code: 7833942033<br /> <br /> Screenshare:<br /> https://blackducksoftware.adobeconnect.com/spdxrdf/<br /> <br /> * [[Technical_Team/SPDX_RDF_Vocabularies_and_Terms|SPDX RDF Vocabularies and Terms]]<br /> * [[Technical_Team/SPDX_Specification_Versions|SPDX Specification Versions]]<br /> * [[Technical_Team/Priorities|Current Priorities and Work in Progress for the Technical Team]]<br /> * [[Technical_Team/Minutes|Meeting Minutes for the Technical Team]]<br /> * [[Technical_Team/Old|Older Items for the Technical Team]]<br /> * [[Technical_Team/Field_Names|Field Names]]<br /> * [[Technical_Team/Spreadsheet_Template|Spreadsheet Template]]<br /> <br /> [[Category:Technical]]</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-04-02T19:55:45Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/File:Spdx-usecase-satisfaction-20130402.xls 2013-04-02T19:54:48Z

<p>Bschineller: </p> <hr /> <div>spdx-usecase-satisfaction-20130402.xls added a column noting Use Cases to try modeling at 2013 Linux CollabSummit</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-04-02T18:20:16Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/File:Spdx-usecase-satisfaction-20130212.xls 2013-04-02T18:19:51Z

<p>Bschineller: </p> <hr /> <div></div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-02-07T14:53:24Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/File:Spdx-usecase-satisfaction-20130205.xls 2013-02-07T14:52:58Z

<p>Bschineller: </p> <hr /> <div></div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-01-29T20:08:12Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/File:Spdx-usecase-satisfaction-20130129.xls 2013-01-29T20:07:46Z

<p>Bschineller: </p> <hr /> <div></div>

Bschineller https://wiki.spdx.org/view/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 2013-01-22T22:01:33Z

<p>Bschineller: </p> <hr /> <div>&lt;ol&gt;&lt;li&gt;&lt;strong&gt;Title:&lt;/strong&gt; Check to see if the SPDX data provided matches the files provided&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Primary Actor:&lt;/strong&gt; Downstream consumer of a package&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Goal in Context:&lt;/strong&gt; Verify that the license obligations for code provided by the upstream supplier matches the licensing information provided by the supplier&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Stakeholders and Interests:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;strong&gt;Upstream Supplier: &lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Express the contents of the delivered software and the license obligations in a manner which can be easily verified by the consumer&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Downstream Consumer:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Verify the files match the description provided&lt;/li&gt;&lt;li&gt;Verify the origin of the files match&lt;/li&gt;&lt;li&gt;Verify the license obligations match&lt;/li&gt;&lt;li&gt;Provide the verified information to further downstream consumers&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Preconditions:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Upstream provider provides an SPDX file along with the package&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Main Success Scenario:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Supplier provides package and SPDX file.&lt;/li&gt;&lt;li&gt;Consumer runs runs file checksums against received files and compares to the SPDX file to validate file origin.&lt;/li&gt;&lt;li&gt;Consumer compares SPDX author and reviewer information and compares to a &quot;trusted&quot; list of authors.&amp;nbsp; Reviewer and supplier information is confirmed by verifying their signatures. (signing)&lt;/li&gt;&lt;li&gt;Consumer searches for any later revisions of the SPDX file which may contain corrections.&lt;/li&gt;&lt;li&gt;Consumer runs independent tools verifying information.&amp;nbsp; If any corrections are required, an updated SPDX file is produced and sent back to the supplier for comment.&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Failed End Condition:&lt;/strong&gt; No SPDX file provided.&amp;nbsp; No signatures for author and/or reviewers.&amp;nbsp; Internally inconsistent SPDX file.&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Trigger:&lt;/strong&gt;&lt;ol&gt;&lt;li&gt;Delivery of a software package&lt;/li&gt;&lt;/ol&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Notes:&lt;/strong&gt;&amp;nbsp; &lt;/li&gt;&lt;ol&gt;&lt;li&gt;The scenerio could work without an initial SPDX file if all of the information is provided in a different format.&amp;nbsp; In this scenario, an SPDX file would be created as an output and the input pre-conditions would be essentially all of the required fields of the SPDX document.&lt;/li&gt;&lt;li&gt;Possibly related/required functionality: the ability to easily compute the differences between different SPDX documents about the same or slightly different packages.&amp;nbsp; e.g. two different SPDX producers provide&amp;nbsp; SPDX documents for package 'time'.&amp;nbsp; If they are indeed for the same exact package / set of files, do they agree on the overall licensing and per-file licensing?&amp;nbsp; If they are for slightly different packages (e.g. 'time' package version X vs. time package Y, which files are different from in each SPDX doc and which licensing has changed? &lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-01-22T21:05:44Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2013-01-22T21:04:35Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/File:Spdx-usecase-satisfaction-20130122.xls 2013-01-22T21:03:04Z

<p>Bschineller: </p> <hr /> <div>spdx-usecase-satisfaction-20130122.xls Spreadsheet of which use cases satisfied by which SPDX model thru 2012-01-22 tech call</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-09T18:37:09Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-09T18:21:00Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [Bill Schineller]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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.&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/Collecting_enough_information_to_allow_auditor_to_make_recommendations_to_remove_or_not_a_component 2012-10-09T18:20:02Z

<p>Bschineller: </p> <hr /> <div>&lt;ol&gt;&lt;li&gt;&lt;strong&gt;Title:&lt;/strong&gt; Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Primary Actor:&lt;/strong&gt; Auditor of open source code&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Goal in Context:&lt;/strong&gt; To provide the consumer of the code audit sufficient information to make changes to the copyrighted materials in order to comply with the consumers policies regarding open source compliance.&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Stakeholders and Interests: &lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;p&gt;&lt;strong&gt;Consumer of the audit: &lt;/strong&gt;&lt;/p&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Organization which has an interest in the license obligations of the copyrighted materials&lt;/li&gt;&lt;li&gt;Will typically have policies (either formal or informal) on the use of open source&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Preconditions:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Access to souce code tree by auditor&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Main Success Scenario:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Source code is analyzed by the auditor and the origin for code and associated license is created&lt;/li&gt;&lt;li&gt;Policy violations are identified to the file (at least) level&lt;/li&gt;&lt;li&gt;Information on the audit is provided in an SPDX file + additional information (e.g. report) [the additional, external report would for example be able to reference items in the SPDX file, and externally capture which company policy is being violated and how]&lt;/li&gt;&lt;li&gt;Remediations are made to the source to comply with the policy&lt;/li&gt;&lt;li&gt;Source code is re-analyzed and an SPDX file describing the compliant code is produced&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Failed End Condition:&lt;/strong&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Trigger:&lt;/strong&gt;Audit&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Notes:&lt;/strong&gt;&amp;nbsp;A data element missing from SPDX 1.x which may be generally needed to establish policy violations is &quot;Code Usage information (e.g. statically vs. dynamically linked)&quot;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Example:&lt;/strong&gt; Company has a policy not to deploy any GPL code compiled into their proprietary commercial software.&amp;nbsp; Audit is performed to identify any GPL code and comply with the policy prior to a product release.&lt;/li&gt;&lt;/ol&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-02T18:59:18Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[MORE INFO REQUESTED]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [Bill Schineller]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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.&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/License_list_extension 2012-10-02T18:58:44Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;An organization that does a lot of compliance work is likely to have a license list already which is a superset of the SPDX license list. Such an organization probably will have policies for how to deal with at least some of these licenses. It is important that organizations be able identify the equivalency of these non-SPDX listed license texts/notices.&lt;/p&gt;&lt;p&gt;[Use Case request is that there be possibility to convey non-SPDX (or not-yet SPDX) licensing in an SPDX doc exchanged between knowing partners referencing a short-form license identifier from that non-SPDX list namespace]&lt;/p&gt;&lt;h2&gt;Stakeholders and interests&lt;/h2&gt;&lt;h3&gt;Analyzer&lt;/h3&gt;&lt;p&gt;A person or organization which produced the SDPX file and maintains their own license list.&lt;/p&gt;&lt;h3&gt;Consumer&lt;/h3&gt;&lt;p&gt;A person, organization or tool which wants to consume SPDX files produced by one or more analyzer. This entity maintains its own license list and policies for those licenses. This license list partially overlaps with each of the Analyzers' license lists. The Consumer maintains mappings between its list and those of the analyzers from which it receives SPDX files.&lt;/p&gt;&lt;h2&gt;Main Scenario&lt;/h2&gt;&lt;ol&gt;&lt;li&gt;Analyzer analyzes a package and finds licenses it recognizes that are not listed on &amp;lt;http://spdx.org/licenses&amp;gt;&lt;/li&gt;&lt;li&gt;Analyzer passes SPDX data to Consumer&lt;/li&gt;&lt;li&gt;For each SPDX listed license Consumer performs appropriate action based on its policy for that license&lt;/li&gt;&lt;li&gt;For each non-SPDX listed license Consumer maps from the globally unique id of the license in the Anaylzer's license list to the license in it's list and performs appropriate action based on its policy for that license&lt;/li&gt;&lt;/ol&gt;&lt;h2&gt;Alternate scenario A&lt;/h2&gt;&lt;ol&gt;&lt;li&gt;Analyzer generates SPDX data referencing its license list for non-SPDX listed licenses&lt;/li&gt;&lt;li&gt;Later one of the licenses in that SPDX file is added to SPDX license list&lt;/li&gt;&lt;li&gt;Consumer detects non-SPDX listed license and maps it to the now SPDX listed license&lt;/li&gt;&lt;/ol&gt;&lt;h2&gt;Alternate scenario B&lt;/h2&gt;&lt;ol&gt;&lt;li&gt;Analyzer analyzes a package and finds licenses it recognizes that are not listed on &amp;lt;http://spdx.org/licenses&amp;gt;&lt;/li&gt;&lt;li&gt;Analyzer passes SPDX data to Consumer&lt;/li&gt;&lt;li&gt;For each SPDX listed license Consumer performs appropriate action based on its policy for that license&lt;/li&gt;&lt;li&gt;Consumer encounters license from Analyzers list that it does not have a mapping for&lt;/li&gt;&lt;li&gt;Consumer fetches license data from Analyzer's license list and adds that license to its license list&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;&lt;strong&gt;Failed scenario&lt;/strong&gt;&lt;/p&gt;&lt;ol&gt;&lt;li&gt;Failed scenario if there ends up being a collision between references to SPDX standard license list and reference to another license list.&lt;/li&gt;&lt;/ol&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-02T18:43:43Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[MORE INFO REQUESTED]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [Bill Schineller]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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.&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/Communicate_data_beyond_what_is_described_in_spec 2012-10-02T18:43:14Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;A vendor wants to embed information about a package in its SPDX file that is not representable using standard SPDX fields (and/or classes).&lt;/p&gt;&lt;h3&gt;Stakeholders and interests&lt;/h3&gt;&lt;ul&gt;&lt;li&gt;&lt;strong&gt;SPDX producer&lt;/strong&gt;&lt;p&gt;The person or organization that is producing the SPDX and wish to extend it with non-standard information.&lt;/p&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;standard SPDX consumer&lt;/strong&gt;&lt;p&gt;A person, organization or tool that can read and process standard SPDX data but is not aware of the non-standard extensions being used by &quot;SPDX producer&quot;.&lt;/p&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;extended SPDX consumer&lt;/strong&gt;&lt;p&gt;A person, organization or tool that can read and process the non-standard extensions used by &quot;SPDX producer&quot; as well as standard SPDX data.&lt;/p&gt;&lt;/li&gt;&lt;/ul&gt;&lt;h3&gt;Main scenario&lt;/h3&gt;&lt;ol&gt;&lt;li&gt;SPDX producer analyzes the package for all the standard SPDX data&lt;/li&gt;&lt;li&gt;SPDX producer analyzes the package for the list actions they believe are required to comply with the licensing of the package&lt;/li&gt;&lt;li&gt;SPDX producer generates an SPDX file which included both the standard SPDX data and the compliance checklist&lt;/li&gt;&lt;li&gt;SPDX producer publishes this file on their website as a &quot;SPDX file for package X&quot;&lt;/li&gt;&lt;li&gt;An extended SPDX consumer downloads the SPDX file and uses the checklist to ensure they are meeting their licensing obligations&lt;/li&gt;&lt;/ol&gt;&lt;h3&gt;Alternate scenario A&lt;/h3&gt;&lt;ol&gt;&lt;li&gt;SPDX producer analyzes the package for all the standard SPDX data&lt;/li&gt;&lt;li&gt;SPDX producer analyzes the package for the list actions they believe are required to comply with the licensing of the package&lt;/li&gt;&lt;li&gt;SPDX producer generates an SPDX file which included both the standard SPDX data and the compliance checklist&lt;/li&gt;&lt;li&gt;SPDX producer publishes this file on their website as a &quot;SPDX file for package X&quot;&lt;/li&gt;&lt;li&gt;A standard SPDX consumer downloads the SPDX file and uses the standard data as input into their compliance processes&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;&lt;strong&gt;Failed scenario&lt;/strong&gt;&lt;/p&gt;&lt;ol&gt;&lt;li&gt;&lt;strong&gt;Fails if the extensions &quot;break&quot; 'standard consumer/tools' such that they can't even process the standard stuff.&lt;/strong&gt;&lt;/li&gt;&lt;/ol&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-02T18:40:09Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[MORE INFO REQUESTED]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot; title=&quot;Check to see if the SPDX data provided matches the files provided and is trustworthy and most current for package&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&amp;nbsp;[OK larger scope]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [Bill Schineller]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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.&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/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 2012-10-02T18:38:06Z

<p>Bschineller: </p> <hr /> <div>&lt;ol&gt;&lt;li&gt;&lt;strong&gt;Title:&lt;/strong&gt; Check to see if the SPDX data provided matches the files provided&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Primary Actor:&lt;/strong&gt; Downstream consumer of a package&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Goal in Context:&lt;/strong&gt; Verify that the license obligations for code provided by the upstream supplier matches the licensing information provided by the supplier&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Stakeholders and Interests:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;strong&gt;Upstream Supplier: &lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Express the contents of the delivered software and the license obligations in a manner which can be easily verified by the consumer&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Downstream Consumer:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Verify the files match the description provided&lt;/li&gt;&lt;li&gt;Verify the origin of the files match&lt;/li&gt;&lt;li&gt;Verify the license obligations match&lt;/li&gt;&lt;li&gt;Provide the verified information to further downstream consumers&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Preconditions:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Upstream provider provides an SPDX file along with the package&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Main Success Senario:&lt;/strong&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Supplier provides package and SPDX file.&lt;/li&gt;&lt;li&gt;Consumer runs runs file checksums against received files and compares to the SPDX file to validate file origin.&lt;/li&gt;&lt;li&gt;Consumer compares SPDX author and reviewer information and compares to a &quot;trusted&quot; list of authors.&amp;nbsp; Reviewer and supplier information is confirmed by verifying their signatures. (signing)&lt;/li&gt;&lt;li&gt;Consumer searches for any later revisions of the SPDX file which may contain corrections.&lt;/li&gt;&lt;li&gt;Consumer runs independent tools verifying information.&amp;nbsp; If any corrections are required, an updated SPDX file is produced and sent back to the supplier for comment.&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;strong&gt;Failed End Condition:&lt;/strong&gt; No SPDX file provided.&amp;nbsp; No signatures for author and/or reviewers.&amp;nbsp; Internally inconsistent SPDX file.&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Trigger:&lt;/strong&gt;&lt;ol&gt;&lt;li&gt;Delivery of a software package&lt;/li&gt;&lt;/ol&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Notes:&lt;/strong&gt;&amp;nbsp; The scenerio could work without an initial SPDX file if all of the information is provided in a different format.&amp;nbsp; In this scenario, an SPDX file would be created as an output and the input pre-conditions would be essentially all of the required fields of the SPDX document.&lt;/li&gt;&lt;/ol&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-02T18:29:47Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[MORE INFO REQUESTED]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;[MORE STUDY NEEDED]&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [Bill Schineller]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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.&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0/Backtrack_from_binary_to_source_files 2012-10-02T18:28:40Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;As an &lt;a href=&quot;../stakeholders#auditor&quot;&gt;auditor&lt;/a&gt; in order to be certain that the licensing and provenance information regarding a binary, or compiled, file is correct i want a manifest of the files used to create it.&lt;/p&gt;&lt;h3&gt;Stakeholders and interests&lt;/h3&gt;&lt;ul&gt;&lt;li&gt;&lt;strong&gt;&lt;strong&gt;Auditor&lt;strong&gt;&lt;/strong&gt;&lt;/strong&gt;&lt;/strong&gt;&lt;p&gt;The person or organization performing an audit on the licensing and provenance information of a package.&lt;/p&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Project maintainer&lt;/strong&gt;&lt;p&gt;The person pr organization which maintains the open source software in question.&lt;/p&gt;&lt;/li&gt;&lt;li&gt;&lt;strong&gt;Developer&lt;/strong&gt;&lt;p&gt;The person or organization using the software package provided by Project maintainer.&lt;/p&gt;&lt;/li&gt;&lt;/ul&gt;&lt;h3&gt;Main Scenario&lt;/h3&gt;&lt;ol&gt;&lt;li&gt;Project maintainer builds binary files keeping track of which source files are included in the binary.&lt;/li&gt;&lt;li&gt;Project maintainer publishes package with SPDX that provides references to every source used to create each compiled file in the package.&lt;/li&gt;&lt;li&gt;Developer downloads binary/compiled package from Package maintainer.&lt;/li&gt;&lt;li&gt;Developer requests audit of code base before shipping.&lt;/li&gt;&lt;li&gt;Auditor wants to verify that provided licensing and provenance info for compiled files are actually what the provided SPDX file claims.&lt;/li&gt;&lt;li&gt;Auditor uses the built from file list for the compiled file to narrow the analysis to particular files and specific versions of those files.&lt;/li&gt;&lt;li&gt;Auditor performs deep analysis to ensure the that the licensing and provenance of the files are indeed as claimed&lt;/li&gt;&lt;li&gt;Auditor provides clean bill of health&lt;/li&gt;&lt;/ol&gt;&lt;h3&gt;Alternate Scenario A&lt;/h3&gt;&lt;ol&gt;&lt;li&gt;Project maintainer builds binary files keeping track of which source files are included in the binary.&lt;/li&gt;&lt;li&gt;Project maintainer publishes package with SPDX that provides references to every source used to create each compiled file in the package.&lt;/li&gt;&lt;li&gt;Developer downloads binary/compiled package from Package maintainer.&lt;/li&gt;&lt;li&gt;Developer requests audit of code base before shipping.&lt;/li&gt;&lt;li&gt;Auditor wants to verify that provided licensing and provenance info for compiled files are actually what the provided SPDX file claims.&lt;/li&gt;&lt;li&gt;Auditor uses the built from package list for the compiled file to narrow the analysis to particular packages and specific versions of those packages.&lt;/li&gt;&lt;li&gt;Auditor performs deep analysis to ensure the that the licensing and provenance of the files are indeed as claimed&lt;/li&gt;&lt;li&gt;Auditor provides clean bill of health&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;&lt;strong&gt;NOTES: on 2012-10-02 having difficulty understanding the distinction between Main Scenario and Alternate A. &amp;nbsp;versions of files vs. versions of Packages? (step 6)&lt;/strong&gt;&lt;/p&gt;</div>

Bschineller https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 2012-10-02T18:17:11Z

<p>Bschineller: </p> <hr /> <div>&lt;p&gt;We have several sources to begin pulling for SPDX Use Cases:&lt;/p&gt;&lt;ol&gt;&lt;li&gt;The Pad from earlier conversations collected at &lt;a href=&quot;http://spdx.org/wiki/use-cases-collected-20-discussion&quot;&gt;Use Cases For SPDX 2.0 Discussion&lt;/a&gt;&lt;/li&gt;&lt;li&gt;The old &lt;a href=&quot;http://spdx.org/wiki/spdx-use-case-1&quot;&gt;SPDX 1.0 Use Cases&lt;/a&gt;&amp;nbsp;as well as the &lt;a href=&quot;http://spdx.org/system/files/ecosystem.jpg&quot;&gt;SDPX 1.0 Use Case Picture&lt;/a&gt;.&lt;/li&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;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. &amp;nbsp; Note, these use cases should be *&lt;strong&gt;doable&lt;/strong&gt;* but in general not *&lt;strong&gt;required&lt;/strong&gt;*. &amp;nbsp;Any item listed here that is not a link, should have a child page created for it.&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Code commits (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committers-provides-spdx-data-code-being-committed&quot;&gt;Committer provides SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/contributor-makes-commit-subject-existing-spdx-data-project&quot;&gt;Contributor makes commit &amp;nbsp;subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/committer-annotates-source-files-spdx-data&quot;&gt;Committer annotates source files with SPDX data&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Patches (original work intended for the project)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch&quot;&gt;Patch provider provides SPDX data for the patch&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-spdx-data-patch-indicating-it-licensed-however-hell-its-applied&quot;&gt;Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/patch-provider-provides-patch-subject-existing-spdx-data-project&quot;&gt;Patch provider provides patch subject to existing SPDX data of project&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Patch provider provides a patch that modifies existing SPDX data of project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-spdx-data-upstream-doesnt-have-it&quot;&gt;Downstream consumers contributing patches to provide SPDX data to an upstream that doesn't have it.&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/downstream-consumers-contributing-patches-provide-corrections-spdx-data-upstream-does-have-it&quot;&gt;Downstream consumers contributing patches to provide corrections to SPDX data for an upstream that does have it.&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-upstream-maintainer-providing-spdx-data&quot;&gt;Upstream maintainer providing SPDX data&lt;/a&gt;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-source-archive&quot;&gt;Upstream maintainer providing SPDX data in source archive&lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-scm&quot;&gt;Upstream maintainer providing SPDX data in SCM&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-providing-spdx-data-url&quot;&gt;Upstream maintainer providing SPDX data at a URL&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/upstream-maintainer-preparing-release-artifacts-including-spdx-data&quot;&gt;Upstream maintainer preparing release artifacts (including SPDX data).&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Project maintainer incorporates another project&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-source&quot;&gt;Project maintainer incorporates another project by including source&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-incorporates-another-project-including-binary&quot;&gt;Project maintainer incorporates another project by including binary&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/project-maintainer-pulling-individual-files-out-another-project-subsetting&quot;&gt;Project maintainer pulling individual files out of another project (subsetting)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Ease adoption&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/low-cost-spdx-file&quot;&gt;Allow a low investment SPDX producer to produce valid SPDX data&lt;/a&gt;&amp;nbsp;[OK-fathomed but not Approved for Implementation]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/producing-valid-spdx-files-face-missing-data&quot;&gt;Produce a valid SPDX dataset even if some data is missing&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager (rpm, deb, etc) passing on and adding to SPDX Data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Intermediate packager builds source package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source&amp;nbsp;that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-source-package-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager builds source package from upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager builds binary package from upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-builds-binary-package-upstream-source-does-not-provides-spdx-data&quot;&gt;Intermediate packager builds binary package from upstream source that does not provides SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds patches to upstream source&amp;nbsp;&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds patches to upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager adds someone else's patches to upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-adds-someone-elses-patches-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager adds someone else's patches to upstream source that does not provide SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Intermediate packager subsetting upstream source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-provides-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that provides SPDX data&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/intermediate-packager-subsetting-upstream-source-does-not-provide-spdx-data&quot;&gt;Intermediate packager subsetting upstream source that does not provide SPDX data [OK]&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Build systems (build systems want to pass on SPDX data for the thing they are building)&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://www.spdx.org/wiki/spdx-use-case-build-systems-yocto&quot;&gt;Yocto&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;Linking&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/debian-has-interest-only-building-things-are-linking-license-compatible&quot;&gt;Debian has an interest in only building things that are linking license compatible&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;I just made a binary out of some source&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-data-indicating-subset-source-made-it-particular-binary-or-binary-package&quot;&gt;SPDX data indicating subset of the source that made it into a particular binary or binary package&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Aggregator aggregating many 'copyrightable items' for redistribution&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a title=&quot;Linux Distro&quot; href=&quot;https://spdx.org/wiki/linux-distro&quot;&gt;Linux Distros&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/embedded-images-eg-router-images-switch-images&quot;&gt;Embedded Images (e.g. router images, switch images)&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-reference-implementations&quot;&gt;Reference implementations &lt;/a&gt;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/spdx-20-usecase-application-which-ships-documentation-media-software&quot;&gt;Application which ships with documentation + &amp;nbsp;media + software&lt;/a&gt; [OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-contrib-libraries&quot;&gt;Application which ships with a contrib libraries&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a title=&quot;Use case details&quot; href=&quot;http://spdx.org/wiki/application-which-ships-development-tools&quot;&gt;Application which ships with development tools&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/subsetting-out-only-shippable-bits-stuff-coming-sdk&quot;&gt;Subsetting out only the shippable bits of stuff coming from an SDK&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/aggregators-aggregating-other-aggregations-redistribution&quot;&gt;Aggregators aggregating other aggregations for redistribution&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Consumers receiving SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/provide-sufficient-data-allow-consumer-comply-licenses-redistribution&quot;&gt;Provide sufficient data to allow consumer to comply with licenses on redistribution&lt;/a&gt;&amp;nbsp;Alcatel-Lucent requirements attached&amp;nbsp;[OK]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/consuming-code-snippets&quot;&gt;Consuming code snippets &lt;/a&gt;(God help us all) (subfile pieces of code not originally intended for the project) [OK]&lt;/li&gt;&lt;li&gt;Signoff/multiple signoff on SPDX data&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a target=&quot;_blank&quot; title=&quot;Contracts with multiple parties requiring signoff by all&quot; href=&quot;https://spdx.org/wiki/multi-party-contracts&quot;&gt;Contracts with multiple parties requiring signoff by al&lt;/a&gt;l [MORE INFO REQUESTED Kate Stewart]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Third party does licensing analysis&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/third-party-produces-bill-materials-software-package&quot;&gt;Third party generates license analysis&lt;/a&gt;&amp;nbsp;[OK]&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/collecting-enough-information-allow-auditor-make-recommendations-remove-or-not-component&quot;&gt;Collecting enough information to allow auditor to make recommendations to remove or not a component&lt;/a&gt;&amp;nbsp;[MORE INFO REQUESTED]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Auditor Analyzing/Sanity-checking/correcting Bill of Material he's handed&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/use-case-backtrack-binary-source-files&quot;&gt;Backtrack from compiled/binary file to constituent files&lt;/a&gt;&amp;nbsp;&lt;/li&gt;&lt;li&gt;outbound: validate that SPDX goes hand in hand with what's being shipped [Kirsten Newcomer]&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/check-see-if-spdx-data-provided-matches-files-provided&quot;&gt;Check to see if the SPDX data provided matches the files provided&lt;/a&gt;&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;li&gt;Extensions:&lt;/li&gt;&lt;ol&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/communicate-data-beyond-what-described-spec&quot;&gt;Communicate data beyond what is described in spec between consenting parties w/o breaking consumers that are not in the know&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/license-list-extension&quot;&gt;License list extensions, how do you handle folks who have more licenses than SPDX&lt;/a&gt;&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;http://spdx.org/wiki/decorating-already-produces-and-signed-spdx-dataset-extension-data&quot;&gt;Decorating an already produces and signed SPDX dataset with extension data&lt;/a&gt; [Bill Schineller]&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Other arising during vetting...&lt;/li&gt;&lt;ol&gt;&lt;li&gt;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.&lt;/li&gt;&lt;/ol&gt;&lt;/ol&gt;&lt;div&gt;&amp;nbsp;Cross-cutting concerns:&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Provenance (the need to optionally use signing to validate who said what)&lt;/li&gt;&lt;li&gt;Trust&lt;/li&gt;&lt;li&gt;Handling staleness of data&lt;/li&gt;&lt;li&gt;Composite licensing&lt;/li&gt;&lt;li&gt;Ease of sharing information&lt;/li&gt;&lt;ol&gt;&lt;li&gt;Collecting tribal knowledge along the way&amp;nbsp;&lt;/li&gt;&lt;/ol&gt;&lt;li&gt;Guarding against file bloat&lt;/li&gt;&lt;li&gt;Simple simple simple&lt;/li&gt;&lt;li&gt;SPDX-Lite:&lt;/li&gt;&lt;li&gt;Clarity&lt;/li&gt;&lt;li&gt;Automation/toolifiability&lt;/li&gt;&lt;li&gt;Regionality&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;h2&gt;Themes:&lt;/h2&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;Looking at these Use Cases, there are some underlying themes:&lt;/div&gt;&lt;div&gt;&lt;ol&gt;&lt;li&gt;Root of data (closer to upstream the better)&lt;/li&gt;&lt;li&gt;Subsetting of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Subsets of copyrightable things are usually also copyrightable things)&lt;/li&gt;&lt;li&gt;Aggregation of copyrightable things (and their SPDX data) (&lt;strong&gt;Note&lt;/strong&gt;: Aggregations of copyrightable things are usually also copyrightable things).&lt;/li&gt;&lt;/ol&gt;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;div&gt;&amp;nbsp;&lt;/div&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;</div>

Bschineller