IFOSSLR Tech Watch Submission - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-07T14:47:47Z

Convert to MediaWiki syntax

Show changes

Rockett at 19:29, 19 November 2010

2010-11-19T19:29:55Z

Podence at 17:29, 19 November 2010

2010-11-19T17:29:21Z

K.stewart at 05:33, 19 November 2010

2010-11-19T05:33:32Z

K.stewart at 05:05, 19 November 2010

2010-11-19T05:05:40Z

New page

@@ Line 4: / Line 4: @@
 <br />(a) Kate Stewart works as the Ubuntu Release Manager at Canonical, Inc.  After reviewing way too many standard projects for license and copyright info in her prior job at Freescale Semiconductor, Inc. she found a group of folk equally fustrated, and set out collaborating with them on defining a specification for sharing package licensing and copyright facts between projects and organizations.<br />
 <br />(a) Phil Odence is Vice President of Business Development for Black Duck Software, makers of enterprise application development tools that address management, compliance and security challenges associated with open source. In that role, he is responsible for expanding Black Duck’s reach, image and product breadth by developing partnerships in the multi-source development, legal and open source ecosystem.<br />
-<br />(a) Esteban Rockett is a Senior Counsel at Motorola, Inc.&nbsp;&nbsp; He is responsible for Software, Applications &amp; Digital Content Licensing.</p>
+<br />(a) Esteban Rockett is a Senior Counsel at Motorola Mobility, Inc.&nbsp; He is Mobility's lead software intellectual property counsel, including serving as legal lead for its open source contributions and compliance, mobile application stores, and digital content licensing and delivery.</p>
 <h3>Abstract</h3>

@@ Line 7: / Line 7: @@
 <h3>Abstract</h3>
-<p>The goal of the Software Package Data Exchange (SPDX(TM)) specification is to enable companies and organizations to share license and component information (metadata) for software package and related content with the aim of facilitating license and other policy compliance. The specification is being developed by collaboration between technical, business and legal professionals to create a standard that addressess the needs of these various partcipants in the software supply chain.
+<p>The goal of the Software Package Data Exchange (SPDX(TM)) specification is to enable companies and organizations to share license and component information (metadata) for software package and related content with the aim of facilitating license and other policy compliance. The specification is being developed through collaboration between technical, business and legal professionals from a range of organizations to create a standard that addressess the needs of various partcipants in the software supply chain.
 </p>
 <h3>Background</h3>
-<p>Companies at all points in the software supply chain are becoming conscious of the need to treat open source just like any other third party code.  They need to know and document the components in the products and software they are consuming and distributing for a variety of reasons, not the least of which is to make sure they understand their legal obligations. Thus the need for a common approach to sharing information about software packages and their related content has never been greater. Breaking down information silos is still a work in progress. The Software Package Data Exchange working group was formed originally as FOSSbazaar sponsored effort, and is now a part of the Linux Foundation's Open Compliance Program[3]. The working group's goal is to figure out effective ways to share copyright and license information about a software packages and common licenses in that package down to the file level.
+<p>Companies at all points in the software supply chain are becoming conscious of the need to treat open source just like any other third party code.  They need to know and document the components in the products and software they are consuming and distributing. There are a variety of reasons for this, not the least of which is to make sure they understand their legal obligations. Thus the need for a common approach to sharing information about software packages and their related content has never been greater. Breaking down information silos is still a work in progress. The Software Package Data Exchange working group was formed originally as FOSSBazaar sponsored effort and is now a part of the Linux Foundation's Open Compliance Program[3]. The working group's goal is to define a way to share copyright and license information about a software packages and common licenses in that package down to the file level.
 </p>
 <h3>Why is a standardized specification needed?</h3>
-<p>Innovation happens very rapidly in the open source ecosystem, often by developers by building on top of the work of other developers.  To do this, source code files, that have been created as part of one project under a specific license may be copied and reused in another project, which may be under a different license.  This mixing and matching of licenses, creates problems for those companies reusing and redistributing software packages that have this combined software, when it comes time to figure out what they need to do to comply with the licenses that govern it.  By creating a standard way of summarizing the licensing and copyright information to the file level, and have a way to double check that the summary they're reading actually matches the code, it makes the task of figuring out what license are in effect much easier.  This permits creation of a software "bill of materials" that can be passed with the actual software, throughout the supply chain, saving considerable analysis effort at every step.  Simply saying your company is doing the right thing is not enough: savvy users want proof to limit the risk of non-compliance with licenses.  Suppliers themselves should welcome a single standard format for disclosing open source rather than having to respond to each manufacturer’s request using a unique format.
+<p>Innovation happens very rapidly in the open source ecosystem, often by developers by building on top of the work of other developers.  To do this, source code files, that have been created as part of one project under a specific license may be copied and reused in another project that may be under a different license.  This mixing and matching of licenses, creates problems for those companies reusing and redistributing software packages that contain this combined software. It becomes a real challenge for them to figure out what they need to do to comply with the licenses that govern their software packages.  By creating a standard way of summarizing the licensing and copyright information to the file level and providing a way to double check that the summary actually matches the code, a standard makes the task of figuring out what license are in effect much easier.  This permits creation of a software "bill of materials" that can be passed with the actual software, throughout the supply chain, saving considerable analysis effort at every step.  Simply saying your company is doing the right thing is not enough: Savvy consumers in the supply chain want proof to limit the risk of non-compliance with licenses.  Suppliers themselves welcome a single standard format for disclosing open source rather than having to respond to each customers’s request using a unique format.
 </p>
 <h3>What does the SPDX specification consist of?</h3>
-<p>Although most software licenses convey intent, the SPDX(TM) effort is focused on coming up with a way to summarize the discoverable facts.  By describing the solution to the problem as a ‘defined format of file to accompany any software package,’ the effort eases the exchange of license information between companies by looking at three areas: facts that deal with identification, facts that provide overview information, and facts that provide file-specific information about the software package.
+<p>The SPDX(TM) effort has focused on coming up with a way to summarize discoverable facts about code content and ownership.  By providing a ‘defined format of file to accompany any software package,’ the effort eases the burden of exchange of license information between companies. The standard defines a format for sharing: Facts that deal with identification, facts that provide overview information, and facts that provide file-specific information about the software package.
 </p>
 <p>Facts that deal with a software package’s identification (metadata) included in the specification are:
 </p><ul>
-<li> Which version of the SPDX specification is in use
+<li> Version of the SPDX specification is in use
 </li><li> Unique identifier (based on a cryptographic hash algorithm) representing a unique identifier that correlates with this specific software package
-</li><li> How the information was generated ( who, when, tools used, etc.)
+</li><li> Method by which information was generated (who, when, tools used, etc.)
-</li><li> Has an independent audit been done ( signoff/reviewed by ) process.
+</li><li>Independent audit information (signoff/reviewed by)</li></ul>
-</li></ul>
-<p>&nbsp;</p>
 <p>Facts that provide overview information about a software package’s content include:
@@ Line 38: / Line 36: @@
 </li><li> Declared License(s)
 </li><li> Detected License(s)
-</li><li> Copyrights and Dates
+</li><li> Copyrights and Dates</li></ul>
-</li></ul>
-<p>&nbsp;</p>
 <p>Facts that are specific to a software package’s file-specific properties:
@@ Line 47: / Line 43: @@
 </li><li> File Type (source or binary)
 </li><li> Detected license(s) governing file (from file)
-</li><li> Copyright owners and dates (if listed)
+</li><li> Copyright owners and dates (if listed)</li></ul>
-</li></ul>
-<p>&nbsp;</p>
 <p>Because of the license orientation of the specification, the Working Group is also committed to providing standardized license references. The spec includes:
@@ Line 55: / Line 49: @@
 <li> License names
 </li><li> Unique identifiers for common open source licenses
-</li><li> Mechanisms for handling non-standard licenses.
+</li><li> Mechanisms for handling non-standard licenses.</li></ul>
-</li></ul>
-<p>&nbsp;</p>
-<p>The SPDX(TM) Working Group does not attempt to apply legal judgment, but rather provides a summary of the facts for other tools and professionals to make their judgements from.
+<p>The SPDX(TM) specification does not attempt to allow for legal judgment, but rather provides a format for a summary of the facts from which professionals (perhaps using other tools) may make judgements.
 </p>
 <h3>How far along is the development and what are the next steps?</h3>
-<p>The Version 1.0 beta form of the specification is available for download at [1], but its just a starting point.  It's had some road testing, but hasn't been driven by the public, so the group's focus will shift to driving practical applications and incorporating the inevitable feedback before we release the official version 1.0.  The group is assembling a list of key projects for which to create SPDX(TM) reports, and to get those done by any method possible.  Initially we expect members of the group to roll up their sleves on this live testing, but we're also working hard with other tool vendors, proprietary and open sources (like FOSSology and Ninka) to create other options for generating these reports.  We also anticipate the need for tools (e.g. syntax checkers and reading and displaying tools) to enable this development, as well as training materials for educating others on using the standard.
+<p>The Version 1.0 beta form of the specification is available for download at [1], but it is just a starting point.  It has had some road testing, but has not been driven by the public, so the group's focus is shifting to driving practical applications and incorporating the inevitable feedback before we release the official version 1.0.  The group is assembling a list of key projects for which to create SPDX(TM) reports, and to get create those reports by any method possible.  Initially we expect members of the group to roll up their sleves on this live testing, but we are also working hard with tool vendors (proprietary and open source) to create other options for generating these reports.  We anticipate the need to develop new tools (e.g. syntax checkers and reading and displaying tools) to enable this development, as well as training materials for educating others on using the standard.
 </p>

← Older revision		Revision as of 05:33, 19 November 2010
Line 1:		Line 1:
−	<p>~~Test~~</p>	+	<h1>Software Package Data Exchange(SPDX) Specification</h1><p>
		+	<br />Kate Stewart, Phil Odence, Esteban Rockett<br />
		+
		+	<br />(a) Kate Stewart works as the Ubuntu Release Manager at Canonical, Inc. After reviewing way too many standard projects for license and copyright info in her prior job at Freescale Semiconductor, Inc. she found a group of folk equally fustrated, and set out collaborating with them on defining a specification for sharing package licensing and copyright facts between projects and organizations.<br />
		+	<br />(a) Phil Odence is Vice President of Business Development for Black Duck Software, makers of enterprise application development tools that address management, compliance and security challenges associated with open source. In that role, he is responsible for expanding Black Duck’s reach, image and product breadth by developing partnerships in the multi-source development, legal and open source ecosystem.<br />
		+	<br />(a) Esteban Rockett is a Senior Counsel at Motorola, Inc.   He is responsible for Software, Applications & Digital Content Licensing.</p>
		+
		+	<h3>Abstract</h3>
		+	<p>The goal of the Software Package Data Exchange (SPDX(TM)) specification is to enable companies and organizations to share license and component information (metadata) for software package and related content with the aim of facilitating license and other policy compliance. The specification is being developed by collaboration between technical, business and legal professionals to create a standard that addressess the needs of these various partcipants in the software supply chain.
		+	</p>
		+
		+	<h3>Background</h3>
		+	<p>Companies at all points in the software supply chain are becoming conscious of the need to treat open source just like any other third party code. They need to know and document the components in the products and software they are consuming and distributing for a variety of reasons, not the least of which is to make sure they understand their legal obligations. Thus the need for a common approach to sharing information about software packages and their related content has never been greater. Breaking down information silos is still a work in progress. The Software Package Data Exchange working group was formed originally as FOSSbazaar sponsored effort, and is now a part of the Linux Foundation's Open Compliance Program[3]. The working group's goal is to figure out effective ways to share copyright and license information about a software packages and common licenses in that package down to the file level.
		+	</p>
		+
		+	<h3>Why is a standardized specification needed?</h3>
		+	<p>Innovation happens very rapidly in the open source ecosystem, often by developers by building on top of the work of other developers. To do this, source code files, that have been created as part of one project under a specific license may be copied and reused in another project, which may be under a different license. This mixing and matching of licenses, creates problems for those companies reusing and redistributing software packages that have this combined software, when it comes time to figure out what they need to do to comply with the licenses that govern it. By creating a standard way of summarizing the licensing and copyright information to the file level, and have a way to double check that the summary they're reading actually matches the code, it makes the task of figuring out what license are in effect much easier. This permits creation of a software "bill of materials" that can be passed with the actual software, throughout the supply chain, saving considerable analysis effort at every step. Simply saying your company is doing the right thing is not enough: savvy users want proof to limit the risk of non-compliance with licenses. Suppliers themselves should welcome a single standard format for disclosing open source rather than having to respond to each manufacturer’s request using a unique format.
		+	</p>
		+
		+	<h3>What does the SPDX specification consist of?</h3>
		+	<p>Although most software licenses convey intent, the SPDX(TM) effort is focused on coming up with a way to summarize the discoverable facts. By describing the solution to the problem as a ‘defined format of file to accompany any software package,’ the effort eases the exchange of license information between companies by looking at three areas: facts that deal with identification, facts that provide overview information, and facts that provide file-specific information about the software package.
		+	</p>
		+
		+	<p>Facts that deal with a software package’s identification (metadata) included in the specification are:
		+	</p><ul>
		+	<li> Which version of the SPDX specification is in use
		+	</li><li> Unique identifier (based on a cryptographic hash algorithm) representing a unique identifier that correlates with this specific software package
		+	</li><li> How the information was generated ( who, when, tools used, etc.)
		+	</li><li> Has an independent audit been done ( signoff/reviewed by ) process.
		+	</li></ul>
		+	<p> </p>
		+
		+	<p>Facts that provide overview information about a software package’s content include:
		+	</p><ul>
		+	<li> Formal Name
		+	</li><li> Package File Name
		+	</li><li> Download Location
		+	</li><li> Declared License(s)
		+	</li><li> Detected License(s)
		+	</li><li> Copyrights and Dates
		+	</li></ul>
		+	<p> </p>
		+
		+	<p>Facts that are specific to a software package’s file-specific properties:
		+	</p><ul>
		+	<li> File Name (including subdirectory)
		+	</li><li> File Type (source or binary)
		+	</li><li> Detected license(s) governing file (from file)
		+	</li><li> Copyright owners and dates (if listed)
		+	</li></ul>
		+	<p> </p>
		+
		+	<p>Because of the license orientation of the specification, the Working Group is also committed to providing standardized license references. The spec includes:
		+	</p><ul>
		+	<li> License names
		+	</li><li> Unique identifiers for common open source licenses
		+	</li><li> Mechanisms for handling non-standard licenses.
		+	</li></ul>
		+	<p> </p>
		+
		+	<p>The SPDX(TM) Working Group does not attempt to apply legal judgment, but rather provides a summary of the facts for other tools and professionals to make their judgements from.
		+	</p>
		+
		+	<h3>How far along is the development and what are the next steps?</h3>
		+	<p>The Version 1.0 beta form of the specification is available for download at [1], but its just a starting point. It's had some road testing, but hasn't been driven by the public, so the group's focus will shift to driving practical applications and incorporating the inevitable feedback before we release the official version 1.0. The group is assembling a list of key projects for which to create SPDX(TM) reports, and to get those done by any method possible. Initially we expect members of the group to roll up their sleves on this live testing, but we're also working hard with other tool vendors, proprietary and open sources (like FOSSology and Ninka) to create other options for generating these reports. We also anticipate the need for tools (e.g. syntax checkers and reading and displaying tools) to enable this development, as well as training materials for educating others on using the standard.
		+	</p>
		+
		+	<h3>Interested in Learning More and Helping out?</h3>
		+	<p>If you want to join our volunteer effort, and help make it better, there is information on how to participate available on our web site [1],[2]. Sub-groups with their own mail lists have recently formed around technical, business, and legal issues, and depending where your interests are, all are open and welcome new members to collaborate on the specific topic areas.
		+	</p>
		+
		+	<h3>Conclusion</h3>
		+	<p>Getting the SPDX(TM) specification adopted across the ecosystem will be a challenge. We need participation and support from key Linux distros and package maintainers, legal experts, tool developers (commercial and open source) and package consuming organizations as well. With major players in all those categories already on board, and with the support from FOSSbazaar and the Linux Foundation[3], the pieces are finally coming together to let us achieve our goal of a useful specification.
		+	</p>
		+
		+	<h3>References</h3><p>
		+	[1] http://www.spdx.org/<br />
		+	[2] http://www.spdx.org/wiki/spdx/participation-guidelines<br />
		+	[3] http://www.linuxfoundation.org/programs/legal/compliance</p>