Business Team/SPDX Vision and Mission Discussion Document - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-02-28T22:17:12Z

Convert to MediaWiki syntax

Mjherzog: Updated title to discussion document

2012-06-21T16:54:24Z

Updated title to discussion document

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

2012-06-21T15:22:50Z

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

Mjherzog at 15:48, 30 May 2012

2012-05-30T15:48:25Z

Mjherzog at 15:47, 30 May 2012

2012-05-30T15:47:14Z

Mjherzog: First draft version

2012-05-30T15:43:45Z

First draft version

New page

<h2>Background</h2> This is a discussion document regarding the vision, mission and charter of SPDX.  This discussion is in the context of planning for version 2.0 of the SPDX specification. <h3>Original (Current) Charter</h3> <ul><li>Spec 1.1  Charter:</li></ul> 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. <ul><li>Spec 1.2 Why is a common format for data exchange needed?</li></ul> 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.   <h3>Key  Themes from SPDX Intro Slides</h3> <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> Our current solution approach may not be sufficient to provide the desired Benefits; e.g. the means do not seem to match the ends.  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.   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. 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 open source software to facilitate software licensing due diligence and compliance activities across the supply chain: <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> 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.   <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.   </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> 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. <h2>Vision and Mission Statements</h2> We currently have several documents that document and explain our vision and mission including: ·         The SPDX Charter, Definition and other principles listed in Section 1. Rationale of the in the specification itself ·         The white paper - A Common Software Package Data Exchange Format: 1.0 Release Update and Discussion ·         Other materials such as several versions of the introductory presentations  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. 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). The following draft Vision and Mission statements are recent draft contributions from SPDX members: <h3>Proposed Vision Statement</h3> Phil Odence has proposed the following Vision statement for the website: “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.” <h3>Proposed Mission Statement</h3> The Cisco team has proposed the following Mission statement: "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."

← Older revision		Revision as of 22:17, 28 February 2013
Line 1:		Line 1:
−	~~<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>~~	+	== Background ==
		+
		+	This is a discussion document regarding the vision, mission and charter of SPDX. This discussion is in the context of planning for version 2.0 of the SPDX specification.
		+
		+	=== Original (Current) Charter ===
		+
		+	* Spec 1.1 Charter:
		+
		+	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.
		+
		+	* Spec 1.2 Why is a common format for data exchange needed?
		+
		+	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.
		+
		+	''' Key Themes from SPDX Intro Slides '''
		+
		+	* Goal: Create a defined format for a file of license fact information describing a software package.
		+	* Guiding Principle: Focus on capturing facts; avoid interpretations.
		+
		+	=== Current SPDX Solution Statement from SPDX Intro Slides ===
		+
		+	* A file format for license information to accompany open source packages
		+	* A standardized short form to refer to the official version of common licenses
		+	* Benefits:
		+	** Allows easy exchange of license information between companies reducing burden on both suppliers and consumers.
		+	** Avoids due diligence redundancy where the same source code package is analyzed multiple times by different recipients.
		+	** Provides a unified method for exchanging license information.
		+
		+	=== What is the issue? ===
		+
		+	Our current solution approach may not be sufficient to provide the desired Benefits; e.g. the means do not seem to match the ends. 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. 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.
		+
		+	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 '''open source''' '''software''' to facilitate software licensing due diligence and compliance activities across the supply chain:
		+
		+	* 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,
		+	* Developing comprehensive open source tools to support many or most due diligence and compliance activities,
		+	* Analyzing licenses in a package using scanning and/or matching techniques to detect the licenses and generate an SPDX file from that analysis,
		+	* Managing large volume of SPDX files – inbound and outbound,
		+	* Automating obligation fulfillment such as generation of attribution text or creation of a source code redistribution package,
		+	* 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,
		+	* Possibly establishing a trusted repository of software components with their origin and license information
		+
		+	=== Specification vs. Implementation ===
		+
		+	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.
		+
		+	* The SPDX original/current charter is to create a data specification and foster its adoption.
		+	* 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.
		+	* 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.
		+	* 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.
		+	* We may be able to better leverage and extend existing open source projects, such as FOSSology, to offer elements of a reference implementation.
		+
		+	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.
		+
		+	== Vision and Mission Statements ==
		+
		+	We currently have several documents that document and explain our vision and mission including:
		+
		+	* The SPDX Charter, Definition and other principles listed in Section 1. Rationale of the in the specification itself
		+	* The white paper - A Common Software Package Data Exchange Format: 1.0 Release Update and Discussion
		+	* Other materials such as several versions of the introductory presentations
		+
		+	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.
		+
		+	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).
		+
		+	The following draft Vision and Mission statements are recent draft contributions from SPDX members:
		+
		+	=== Proposed Vision Statement ===
		+
		+	Phil Odence has proposed the following Vision statement for the website:
		+
		+	“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.”
		+
		+	=== Proposed Mission Statement ===
		+
		+	The Cisco team has proposed the following Mission statement:
		+
		+	"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."
		+
		+	[[Category:Business]]
		+	[[Category:Archived]]

← Older revision		Revision as of 15:22, 21 June 2012
Line 1:		Line 1:
−	<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>	+	<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>

← Older revision		Revision as of 15:48, 30 May 2012
Line 1:		Line 1:
−	<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>	+	<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>

← Older revision		Revision as of 15:47, 30 May 2012
Line 1:		Line 1:
−	<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>	+	<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>

← Older revision	Revision as of 16:54, 21 June 2012
(No difference)