SPDX Wiki - User contributions [en]

Business Team/SPDX Vision and Mission Discussion Document Final Draft

2012-06-26T18:16:38Z

Mjherzog: Changed "Deliver" to "Develop"

<h3>Proposed SPDX Vision Statement</h3><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><p> </p><h3>Proposed SPDX Mission Statement</h3><p class="MsoNormal"> "Develop and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p>

Wiki Conventions

2012-06-22T15:27:48Z

Mjherzog: corrected strange font change

<h2>First:</h2><ul><li>You need an account in order to edit the wiki pages. If you haven't created an account on FOSSBazaar or spdx.org yet, please <a href="/user/register">sign up</a> for one now. If you already have a FOSSBazaar account, you can use it login here.</li><li>There are three separate SPDX teams (<a href="http://www.spdx.org/wiki/spdx/spec-development">Technical</a>, <a href="http://www.spdx.org/wiki/spdx/biz">Business</a> and <a href="http://www.spdx.org/wiki/spdx/legal">Legal</a>) each of which has its own meetings and mailing list. There is also a regular General Meeting and mailing list, the main purposes of which is to report out on team activities. Here you can subscribe to the <a href="http://lists.spdx.org/mailman/listinfo/spdx">SPDX mailing list</a> which is a good way for anyone with casual interest to participate and be notified of general meetings. To participate on the teams or get on the team mailing lists, go to their respective sections under the Participation tab.</li><li>A good starting point for understanding the spec is the <a href="http://www.linuxfoundation.org/sites/main/files/publications/lf_foss_compliance_spdx.pdf">SPDX whitepaper</a>. This <a href="http://www.blackducksoftware.com/files/spdx/intro_to_spdx.mov">3 minute webinar</a> provides a very concise introduction.</li><li>Another good resource is the <a title="SPDX mailing list archive" href="http://lists.spdx.org/pipermail/spdx/">mailing list archive</a>.</li></ul><h2>Wiki</h2><p>Here are some instructions for using the SPDX wiki. Every user who is logged into spdx.org can modify wiki pages. At the top of a page, you'll see an "Edit" option. You can then edit the page using the HTML editor. When you save the page, make sure to put in a message in "Log message" briefly explaining the change you've made. Then click on "Save" at the bottom of the page to save or on "Preview" or "Preview changes" to preview before saving.</p><p>If a page has been edited more than once, you'll see a "Revisions" link at the top of the page (next to "Edit"). Clicking on this link will allow you to see in detail which changes have been made to the page.</p><p>If you want to create a new page, click on "Add child page".</p><p>If you want to add a visible comment,  please start the comment by indicating the source by your initials, bolded, surrounded by angle brackets.  Then put the comment itself in italics.  For example: <strong><kes></strong> <em>this is a comment or a question?.</em>  The purpose of this is to make sure its clear that this is not part of the official text of the standard at this point, and provides localized context for the discussion.</p>

Business Team/SPDX Vision and Mission Discussion Document Final Draft

2012-06-21T16:59:45Z

Mjherzog:

<h3>Proposed SPDX Vision Statement</h3><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><p> </p><h3>Proposed SPDX Mission Statement</h3><p class="MsoNormal"> "Deliver and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p>

Business Team/Team Role

2012-06-21T16:59:12Z

Mjherzog: Posted current draft to the wiki

<p>Draft as of June 21, 2012</p><p>The SPDX Business Team promotes the adoption of the SPDX specification across software supply chains, collects feedback and requirements from stakeholders, and leads a cross-team effort to develop the SPDX Strategy/Roadmap and update it based on stakeholder feedback.</p>

Business Team/SPDX Vision and Mission Discussion Document Final Draft

2012-06-21T16:54:50Z

Mjherzog:

<h3>Proposed SPDX Vision Statement</h3><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><p> </p><h3>Proposed SPDX Mission Statement</h3><p class="MsoNormal"> "Deliver and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p>

Business Team/SPDX Vision and Mission Discussion Document

2012-06-21T16:54:24Z

Mjherzog: Updated title to discussion document

<p> </p><h2>Background</h2><p>This is a discussion document regarding the vision, mission and charter of SPDX.<span>  </span>This discussion is in the context of planning for version 2.0 of the SPDX specification.</p><h3>Original (Current) Charter</h3><ul><li>Spec 1.1<span>  </span>Charter:</li></ul><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.25in; line-height: normal;">Create a set of data exchange standards that enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><ul><li>Spec 1.2 Why is a common format for data exchange needed?</li></ul><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.5in; line-height: normal;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><p><strong> Key  Themes from SPDX Intro Slides </strong></p><ul><li>Goal: Create a defined format for a file of license fact information describing a software package.</li><li>Guiding Principle: Focus on capturing facts; avoid interpretations.</li></ul><h3>Current SPDX Solution Statement from SPDX Intro Slides</h3><ul><li>A file format for license information to accompany open source packages</li><li>A standardized short form to refer to the official version of common licenses</li><li>Benefits:</li><ul><li>Allows easy exchange of license information between companies reducing burden on both suppliers and consumers.</li><li>Avoids due diligence redundancy where the same source code package is analyzed multiple times by different recipients.</li><li>Provides a unified method for exchanging license information.</li></ul></ul><h3>What is the issue?</h3><p>Our current solution approach may not be sufficient to provide the desired Benefits; e.g. the means do not seem to match the ends. <span> </span>Many current participants do not see how we can get to the desired benefits without expanding the mission and scope to encompass more of the compliance cycle.<span>   </span>If we expand the mission, then we may also need organization changes to support that mission, especially some form of product management across the teams.</p><p>Many SPDX participants are now talking about a broader and deeper mission beyond a data exchange format specification including a broader/deeper role in providing standards and <strong>open source</strong> <strong>software</strong> to facilitate software licensing due diligence and compliance activities across the supply chain:</p><ul><li>Expanding the specification to include comprehensive information for meeting license obligations such as complete attribution data required by open source licenses – e.g. copyright and other notices,</li><li type="_moz">Developing comprehensive open source tools to support many or most due diligence and compliance activities,</li><li>Analyzing licenses in a package using scanning and/or matching techniques to detect the licenses and generate an SPDX file from that analysis,</li><li>Managing large volume of SPDX files – inbound and outbound,</li><li>Automating obligation fulfillment such as generation of attribution text or creation of a source code redistribution package,</li><li>Establishing a trusted repository of more comprehensive data about licenses – e.g. extend the License List to provide data for use by license detection tools,</li><li>Possibly establishing a trusted repository of software components with their origin and license information</li></ul><h3>Specification vs. Implementation</h3><p>There is some fundamental creative tension between our charter to create a Software Package Data Exchange specification and foster its adoption versus a broader mission to create open source software to actively facilitate/enable that adoption.<span> </span></p><ul><li>The SPDX original/current charter is to create a data specification and foster its adoption.</li><li>We agreed early on to create some basic software tools to read and write SPDX files and encourage commercial vendors to support SPDX in their existing products.</li><li>We also agreed to emulate an open source project, but we are not an open source project whose primary “work product” is software – our primary work product is the specification itself.<span>   </span></li><li>As the SPDX specification evolves (and presumably becomes more complex), it may be highly desirable or even necessary to provide some elements of a reference implementation to validate the specification before general release.</li><li>We may be able to better leverage and extend existing open source projects, such as FOSSology, to offer elements of a reference implementation.</li></ul><p>If we change our charter to include development of open source software to support software licensing due diligence and compliance activities across the supply chain, then we need to look closely at our form of organization.</p><h2>Vision and Mission Statements</h2><p>We currently have several documents that document and explain our vision and mission including:</p><ul><li><span style="font-family: Symbol;"><span><span style="font: 7pt 'Times New Roman';"> </span></span></span>The SPDX Charter, Definition and other principles listed in <span style="text-decoration: underline;">Section 1. Rationale</span> of the in the specification itself</li><li>The white paper - <span style="text-decoration: underline;">A Common Software Package Data Exchange Format: 1.0 Release Update and Discussion</span></li><li>Other materials such as several versions of the introductory presentations</li></ul><p class="MsoNormal">Some members have already been thinking about expanding how we talk about our vision, mission, charter, and guiding principles – there are many names for specific elements of how an organization describes itself.</p><p> One approach is to add a Vision statement and a Mission statement for SPDX where the Vision statement describes what the future looks like when you execute on the mission and the Mission statement says what you do on a daily basis (similar to a guiding principle).</p><p>The following draft Vision and Mission statements are recent draft contributions from SPDX members:</p><h3>Proposed Vision Statement</h3><p>Phil Odence has proposed the following Vision statement for the website:</p><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><h3>Proposed Mission Statement</h3><p>The Cisco team has proposed the following Mission statement:</p><p class="MsoNormal">"Deliver and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p><p> </p>

Business Team/SPDX Vision and Mission Discussion Document Final Draft

2012-06-21T16:52:18Z

Mjherzog: formatting change

<h3>Proposed SPDX Vision Statement </h3><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><p> </p><h3>Proposed SPDX Mission Statement</h3><p class="MsoNormal"> "Deliver and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p>

Business Team/SPDX Vision and Mission Discussion Document Final Draft

2012-06-21T16:51:36Z

Mjherzog: Current draft statements as of June 21, 2012

<h3>Proposed SPDX Vision Statement</h3><p> </p><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><p> </p><h3>Proposed SPDX Mission Statement</h3><p> </p><p> </p><p class="MsoNormal">"Deliver and promote adoption of a specification to enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p>

Business Team/SPDX Vision and Mission Discussion Document

2012-06-21T15:22:50Z

Mjherzog: Added preamble to "Deliver and promote..." based on Business Team discussions

Business Team/SPDX Vision and Mission Discussion Document

2012-05-30T15:48:25Z

Mjherzog:

<p> </p><h2>Background</h2><p>This is a discussion document regarding the vision, mission and charter of SPDX.<span>  </span>This discussion is in the context of planning for version 2.0 of the SPDX specification.</p><h3>Original (Current) Charter</h3><ul><li>Spec 1.1<span>  </span>Charter:</li></ul><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.25in; line-height: normal;">Create a set of data exchange standards that enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><ul><li>Spec 1.2 Why is a common format for data exchange needed?</li></ul><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.5in; line-height: normal;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><p><strong> Key  Themes from SPDX Intro Slides </strong></p><ul><li>Goal: Create a defined format for a file of license fact information describing a software package.</li><li>Guiding Principle: Focus on capturing facts; avoid interpretations.</li></ul><h3>Current SPDX Solution Statement from SPDX Intro Slides</h3><ul><li>A file format for license information to accompany open source packages</li><li>A standardized short form to refer to the official version of common licenses</li><li>Benefits:</li><ul><li>Allows easy exchange of license information between companies reducing burden on both suppliers and consumers.</li><li>Avoids due diligence redundancy where the same source code package is analyzed multiple times by different recipients.</li><li>Provides a unified method for exchanging license information.</li></ul></ul><h3>What is the issue?</h3><p>Our current solution approach may not be sufficient to provide the desired Benefits; e.g. the means do not seem to match the ends. <span> </span>Many current participants do not see how we can get to the desired benefits without expanding the mission and scope to encompass more of the compliance cycle.<span>   </span>If we expand the mission, then we may also need organization changes to support that mission, especially some form of product management across the teams.</p><p>Many SPDX participants are now talking about a broader and deeper mission beyond a data exchange format specification including a broader/deeper role in providing standards and <strong>open source</strong> <strong>software</strong> to facilitate software licensing due diligence and compliance activities across the supply chain:</p><ul><li>Expanding the specification to include comprehensive information for meeting license obligations such as complete attribution data required by open source licenses – e.g. copyright and other notices,</li><li type="_moz">Developing comprehensive open source tools to support many or most due diligence and compliance activities,</li><li>Analyzing licenses in a package using scanning and/or matching techniques to detect the licenses and generate an SPDX file from that analysis,</li><li>Managing large volume of SPDX files – inbound and outbound,</li><li>Automating obligation fulfillment such as generation of attribution text or creation of a source code redistribution package,</li><li>Establishing a trusted repository of more comprehensive data about licenses – e.g. extend the License List to provide data for use by license detection tools,</li><li>Possibly establishing a trusted repository of software components with their origin and license information</li></ul><h3>Specification vs. Implementation</h3><p>There is some fundamental creative tension between our charter to create a Software Package Data Exchange specification and foster its adoption versus a broader mission to create open source software to actively facilitate/enable that adoption.<span> </span></p><ul><li>The SPDX original/current charter is to create a data specification and foster its adoption.</li><li>We agreed early on to create some basic software tools to read and write SPDX files and encourage commercial vendors to support SPDX in their existing products.</li><li>We also agreed to emulate an open source project, but we are not an open source project whose primary “work product” is software – our primary work product is the specification itself.<span>   </span></li><li>As the SPDX specification evolves (and presumably becomes more complex), it may be highly desirable or even necessary to provide some elements of a reference implementation to validate the specification before general release.</li><li>We may be able to better leverage and extend existing open source projects, such as FOSSology, to offer elements of a reference implementation.</li></ul><p>If we change our charter to include development of open source software to support software licensing due diligence and compliance activities across the supply chain, then we need to look closely at our form of organization.</p><h2>Vision and Mission Statements</h2><p>We currently have several documents that document and explain our vision and mission including:</p><ul><li><span style="font-family: Symbol;"><span><span style="font: 7pt 'Times New Roman';"> </span></span></span>The SPDX Charter, Definition and other principles listed in <span style="text-decoration: underline;">Section 1. Rationale</span> of the in the specification itself</li><li>The white paper - <span style="text-decoration: underline;">A Common Software Package Data Exchange Format: 1.0 Release Update and Discussion</span></li><li>Other materials such as several versions of the introductory presentations</li></ul><p class="MsoNormal">Some members have already been thinking about expanding how we talk about our vision, mission, charter, and guiding principles – there are many names for specific elements of how an organization describes itself.</p><p> One approach is to add a Vision statement and a Mission statement for SPDX where the Vision statement describes what the future looks like when you execute on the mission and the Mission statement says what you do on a daily basis (similar to a guiding principle).</p><p>The following draft Vision and Mission statements are recent draft contributions from SPDX members:</p><h3>Proposed Vision Statement</h3><p>Phil Odence has proposed the following Vision statement for the website:</p><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><h3>Proposed Mission Statement</h3><p>The Cisco team has proposed the following Mission statement:</p><p class="MsoNormal">"To enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p><p> </p>

Business Team/SPDX Vision and Mission Discussion Document

2012-05-30T15:47:14Z

Mjherzog:

<p> </p><h2>Background </h2><p>This is a discussion document regarding the vision, mission and charter of SPDX.<span>  </span>This discussion is in the context of planning for version 2.0 of the SPDX specification. </p><h3>Original (Current) Charter </h3><ul><li>Spec 1.1<span>  </span>Charter: </li></ul><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.25in; line-height: normal;">Create a set of data exchange standards that enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><ul><li>Spec 1.2 Why is a common format for data exchange needed? </li></ul><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.5in; line-height: normal;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><p><strong> Key  Themes from SPDX Intro Slides </strong></p><ul><li>Goal: Create a defined format for a file of license fact information describing a software package.</li><li>Guiding Principle: Focus on capturing facts; avoid interpretations. </li></ul><h3>Current SPDX Solution Statement from SPDX Intro Slides </h3><ul><li>A file format for license information to accompany open source packages</li><li>A standardized short form to refer to the official version of common licenses</li><li>Benefits:</li><ul><li>Allows easy exchange of license information between companies reducing burden on both suppliers and consumers.</li><li>Avoids due diligence redundancy where the same source code package is analyzed multiple times by different recipients.</li><li>Provides a unified method for exchanging license information. </li></ul></ul><h3>What is the issue? </h3><p>Our current solution approach may not be sufficient to provide the desired Benefits; e.g. the means do not seem to match the ends. <span> </span>Many current participants do not see how we can get to the desired benefits without expanding the mission and scope to encompass more of the compliance cycle.<span>   </span>If we expand the mission, then we may also need organization changes to support that mission, especially some form of product management across the teams. </p><p>Many SPDX participants are now talking about a broader and deeper mission beyond a data exchange format specification including a broader/deeper role in providing standards and <strong>open source</strong> <strong>software</strong> to facilitate software licensing due diligence and compliance activities across the supply chain: </p><ul><li>Expanding the specification to include comprehensive information for meeting license obligations such as complete attribution data required by open source licenses – e.g. copyright and other notices,</li><li type="_moz">Developing comprehensive open source tools to support many or most due diligence and compliance activities,</li><li>Analyzing licenses in a package using scanning and/or matching techniques to detect the licenses and generate an SPDX file from that analysis,</li><li>Managing large volume of SPDX files – inbound and outbound,</li><li>Automating obligation fulfillment such as generation of attribution text or creation of a source code redistribution package,</li><li>Establishing a trusted repository of more comprehensive data about licenses – e.g. extend the License List to provide data for use by license detection tools,</li><li>Possibly establishing a trusted repository of software components with their origin and license information </li></ul><h3>Specification vs. Implementation </h3><p>There is some fundamental creative tension between our charter to create a Software Package Data Exchange specification and foster its adoption versus a broader mission to create open source software to actively facilitate/enable that adoption.<span> </span> </p><ul><li>The SPDX original/current charter is to create a data specification and foster its adoption.</li><li>We agreed early on to create some basic software tools to read and write SPDX files and encourage commercial vendors to support SPDX in their existing products.</li><li>We also agreed to emulate an open source project, but we are not an open source project whose primary “work product” is software – our primary work product is the specification itself.<span>   </span></li><li>As the SPDX specification evolves (and presumably becomes more complex), it may be highly desirable or even necessary to provide some elements of a reference implementation to validate the specification before general release.</li><li>We may be able to better leverage and extend existing open source projects, such as FOSSology, to offer elements of a reference implementation. </li></ul><p>If we change our charter to include development of open source software to support software licensing due diligence and compliance activities across the supply chain, then we need to look closely at our form of organization. </p><h2>Vision and Mission Statements </h2><p>We currently have several documents that document and explain our vision and mission including: </p><ul><li><span style="font-family: Symbol;"><span><span style="font: 7pt 'Times New Roman';"> </span></span></span>The SPDX Charter, Definition and other principles listed in <span style="text-decoration: underline;">Section 1. Rationale</span> of the in the specification itself </li><li>The white paper - <span style="text-decoration: underline;">A Common Software Package Data Exchange Format: 1.0 Release Update and Discussion</span></li><li>Other materials such as several versions of the introductory presentations</li></ul><p class="MsoNormal">Some members have already been thinking about expanding how we talk about our vision, mission, charter, and guiding principles – there are many names for specific elements of how an organization describes itself.</p><p> One approach is to add a Vision statement and a Mission statement for SPDX where the Vision statement describes what the future looks like when you execute on the mission and the Mission statement says what you do on a daily basis (similar to a guiding principle). </p><p>The following draft Vision and Mission statements are recent draft contributions from SPDX members: </p><h3>Proposed Vision Statement </h3><p>Phil Odence has proposed the following Vision statement for the website: </p><p>“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.” </p><h3>Proposed Mission Statement </h3><p>The Cisco team has proposed the following Mission statement: </p><p class="MsoNormal">"To enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p><p> </p>

Business Team/SPDX Vision and Mission Discussion Document

2012-05-30T15:43:45Z

Mjherzog: First draft version

<p> </p><h2>Background</h2><p> </p><p class="MsoNormal">This is a discussion document regarding the vision, mission and charter of SPDX.<span>  </span>This discussion is in the context of planning for version 2.0 of the SPDX specification.</p><p> </p><h3>Original (Current) Charter</h3><p> </p><ul><li>Spec 1.1<span>  </span>Charter:</li></ul><p> </p><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.25in; line-height: normal;">Create a set of data exchange standards that enable companies and organizations to share license and component information (metadata) for software packages and related content with the aim of facilitating license and other policy compliance.</p><p> </p><ul><li>Spec 1.2 Why is a common format for data exchange needed?</li></ul><p> </p><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.5in; line-height: normal;">Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Compliance with the associated licenses requires a set of due diligence activities that each Organization performs independently: a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but they have not yet set-up a way to collaborate on license discovery – many groups are performing the same work leading to duplicated effort and redundancy. This working group seeks to create a data exchange format so that information about software packages and related content, may be collected and shared in a common format with the goal of saving time and improving data accuracy.</p><p> </p><p class="MsoNormal" style="margin: 0in 0in 0.0001pt 0.5in; line-height: normal;"> </p><p> </p><h3>Key<span>  </span>Themes from SPDX Intro Slides</h3><p> </p><ul><li>Goal: Create a defined format for a file of license fact information describing a software package.</li><li>Guiding Principle: Focus on capturing facts; avoid interpretations.</li></ul><p> </p><h3>Current SPDX Solution Statement from SPDX Intro Slides</h3><p> </p><ul><li>A file format for license information to accompany open source packages</li><li>A standardized short form to refer to the official version of common licenses</li><li>Benefits:</li><ul><li>Allows easy exchange of license information between companies reducing burden on both suppliers and consumers.</li><li>Avoids due diligence redundancy where the same source code package is analyzed multiple times by different recipients.</li><li>Provides a unified method for exchanging license information.</li></ul></ul><p> </p><h3>What is the issue?</h3><p> </p><p class="MsoNormal">Our current solution approach may not be sufficient to provide the desired Benefits; e.g. the means do not seem to match the ends. <span> </span>Many current participants do not see how we can get to the desired benefits without expanding the mission and scope to encompass more of the compliance cycle.<span>   </span>If we expand the mission, then we may also need organization changes to support that mission, especially some form of product management across the teams.</p><p> </p><p class="MsoNormal">Many SPDX participants are now talking about a broader and deeper mission beyond a data exchange format specification including a broader/deeper role in providing standards and <strong>open source</strong> <strong>software</strong> to facilitate software licensing due diligence and compliance activities across the supply chain:</p><p> </p><ul><li>Expanding the specification to include comprehensive information for meeting license obligations such as complete attribution data required by open source licenses – e.g. copyright and other notices,</li><li type="_moz">Developing comprehensive open source tools to support many or most due diligence and compliance activities,</li><li>Analyzing licenses in a package using scanning and/or matching techniques to detect the licenses and generate an SPDX file from that analysis,</li><li>Managing large volume of SPDX files – inbound and outbound,</li><li>Automating obligation fulfillment such as generation of attribution text or creation of a source code redistribution package,</li><li>Establishing a trusted repository of more comprehensive data about licenses – e.g. extend the License List to provide data for use by license detection tools,</li><li>Possibly establishing a trusted repository of software components with their origin and license information</li></ul><p> </p><h3>Specification vs. Implementation</h3><p> </p><p class="MsoNormal">There is some fundamental creative tension between our charter to create a Software Package Data Exchange specification and foster its adoption versus a broader mission to create open source software to actively facilitate/enable that adoption.<span>  </span></p><p> </p><ul><li>The SPDX original/current charter is to create a data specification and foster its adoption.</li><li>We agreed early on to create some basic software tools to read and write SPDX files and encourage commercial vendors to support SPDX in their existing products.</li><li>We also agreed to emulate an open source project, but we are not an open source project whose primary “work product” is software – our primary work product is the specification itself.<span>   </span></li><li>As the SPDX specification evolves (and presumably becomes more complex), it may be highly desirable or even necessary to provide some elements of a reference implementation to validate the specification before general release.</li><li>We may be able to better leverage and extend existing open source projects, such as FOSSology, to offer elements of a reference implementation.</li></ul><p> </p><p class="MsoNormal">If we change our charter to include development of open source software to support software licensing due diligence and compliance activities across the supply chain, then we need to look closely at our form of organization.</p><p> </p><h2>Vision and Mission Statements</h2><p> </p><p class="MsoNormal" style="margin-bottom: 0.0001pt;">We currently have several documents that document and explain our vision and mission including:</p><p> </p><p class="MsoListParagraphCxSpFirst" style="margin-bottom: 0.0001pt; text-indent: -0.25in;"><span style="font-family: Symbol;"><span>·<span style="font: 7pt 'Times New Roman';">         </span></span></span>The SPDX Charter, Definition and other principles listed in <span style="text-decoration: underline;">Section 1. Rationale</span> of the in the specification itself</p><p> </p><p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;"><span style="font-family: Symbol;"><span>·<span style="font: 7pt 'Times New Roman';">         </span></span></span>The white paper - <span style="text-decoration: underline;">A Common Software Package Data Exchange Format: 1.0 Release Update and Discussion</span></p><p> </p><p class="MsoListParagraphCxSpLast" style="text-indent: -0.25in;"><span style="font-family: Symbol;"><span>·<span style="font: 7pt 'Times New Roman';">         </span></span></span>Other materials such as several versions of the introductory presentations</p><p> </p><p class="MsoNormal"><span> </span>Some members have already been thinking about expanding how we talk about our vision, mission, charter, and guiding principles – there are many names for specific elements of how an organization describes itself.</p><p> </p><p class="MsoNormal">One approach is to add a Vision statement and a Mission statement for SPDX where the Vision statement describes what the future looks like when you execute on the mission and the Mission statement says what you do on a daily basis (similar to a guiding principle).</p><p> </p><p class="MsoNormal">The following draft Vision and Mission statements are recent draft contributions from SPDX members:</p><p> </p><h3>Proposed Vision Statement</h3><p> </p><p class="MsoNormal">Phil Odence has proposed the following Vision statement for the website:</p><p> </p><p class="MsoNormal">“The vision of SPDX is to achieve license compliance with minimal cost across the supply chain. Ideally, upstream component developers begin the process by supplying SPDX files as part of their downloads. Users of those components therefore have a starting point with the SPDX files that they create for their "customers," and so on. If everything is working properly, the provenance of each piece of code is researched and documented only once during its journey through a supply chain, and that information is passed on in parallel with the code in the SPDX format.”</p><p> </p><h3>Proposed Mission Statement</h3><p> </p><p class="MsoNormal">The Cisco team has proposed the following Mission statement:</p><p> </p><p class="MsoNormal">"To enable any party in a software supply chain, from the original author to the final end user, to accurately communicate the licensing information for any piece of copyrightable material that such party may create, alter, combine, pass on, or receive, and to make such information available in a consistent, understandable, and re-usable fashion, with the aim of facilitating license and other policy compliance."</p><p> </p>

Technical Team/Use Cases/2.0/Aggregators aggregating other aggregations for redistribution

2012-05-22T18:40:42Z

Mjherzog: corrected spelling

<ol style="color: #4d4d4d; font-family: Arial, Helvetica, sans-serif; font-size: 13px;"><li><strong>Title:</strong> Aggregators aggregating other aggregations for redistribution</li><li><strong>Primary Actor: Aggregator of aggregations</strong></li><li><strong>Goal in Context:</strong> To allow an aggregator of aggregations to express in SPDX the internal structure of what the copyrightable artifacts they are shipping are, how they are organized hierarchically, and the licensing information for all of it.</li><li><strong>Stakeholders and Interests:</strong> <ol><li><strong><strong>Aggregator of aggregations</strong>: </strong><ol><li>To communicate the licensing information for their aggregate of aggregations including the internal structure and provenance.</li></ol></li><li><strong>Consumers of Embedded Images:</strong><ol><li>To receive accurate and clear information of licensing of the aggregate and all they contain.</li><li>To be able to comply easily with licenses for the aggregate and all it contains.</li><li>To be able to trust that the aggregate SPDX data is in alignment with the upstream maintainers license assertions of the pieces it contains.</li></ol></li></ol></li><li><strong>Preconditions:</strong> <ol><li>Aggregator of aggregates understands the things it contains, including any SPDX data if provided.</li></ol></li><li><strong>Main Success Senario:</strong> Aggregator of aggregates communicates accurate complete licensing information for their package in an SPDX data format for the Aggregate and all it contains.</li><li><strong>Failed End Condition:</strong> Aggregator of aggregates does not communicates accurate complete licensing information for their package in an SPDX data format for the Aggregate and all it contains.</li><li><strong>Trigger:</strong><ol><li>Release of a new aggregate.</li></ol></li><li><strong>Notes:</strong>  </li></ol>

Old/Linux Collaboration Summit 2011

2011-03-23T22:53:06Z

Mjherzog:

<p>The <a href="http://events.linuxfoundation.org/events/collaboration-summit">Linux Collaboration Summit</a> is in San Francisco, April 6-8. The SPDX <a href="http://events.linuxfoundation.org/events/collaboration-summit/spdx-technical">Technical</a> and <a href="http://events.linuxfoundation.org/events/collaboration-summit/spdx-business">Business</a> teams will be holding face to face meetings. If you would like to participate, please <a href="http://www.regonline.com/Register/Checkin.aspx?EventID=923747">request an invitation</a> to the event from the Linux Foundation. If you alert Phil Koltun pkoltun@linuxfoundation.org that you have requested an invitation because you are interested in SPDX parrticipation, he can streamline the approval process.</p><p> </p><p>And, if you are coming, please edit your name into the RSVP list(s) below:</p><p> </p><p><strong>I'm coming to the SPDX Technical Team Face to Face</strong>:</p><ul><li>Kate Stewart, Canonical</li><li>Phil Odence, Black Duck Software</li><li>Phil Koltun, Linux Foundation</li><li> Peter Williams, OpenLogic</li><li>Michael Herzog, nexB</li></ul><p><strong>I'm coming to the SPDX Business Team Face to Face:</strong></p><ul><li>Kim Weins, Open Logic</li><li>Phil Odence, Black Duck Software</li><li>Phil Koltun, Linux Foundation</li><li>Pierre Lapointe, nexB</li><li>Michael Herzog, nexB</li></ul>