Business Team/Beta Program/Feedback - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-02-28T22:24:21Z

Convert to MediaWiki syntax

Kweins at 16:07, 7 July 2011

2011-07-07T16:07:20Z

Kweins at 15:44, 7 July 2011

2011-07-07T15:44:01Z

Kweins at 15:42, 7 July 2011

2011-07-07T15:42:22Z

Kweins at 15:05, 7 July 2011

2011-07-07T15:05:08Z

Slamons at 14:47, 7 July 2011

2011-07-07T14:47:27Z

Slamons at 14:27, 7 July 2011

2011-07-07T14:27:58Z

Fmunoz at 10:26, 7 July 2011

2011-07-07T10:26:20Z

Fmunoz at 10:26, 7 July 2011

2011-07-07T10:26:02Z

Kweins at 15:29, 28 June 2011

2011-06-28T15:29:04Z

New page

Add your Beta Feedback Here.  Put your name & company at the beginning of your feedback. My Company -- My Name<ol><li>feedback item 1</li><li>feedback item 2</li></ol>

@@ Line 1: / Line 1: @@
-<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p>&nbsp;</p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.&nbsp; SPDX potentially provides a better and&nbsp; more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.&nbsp;&nbsp; We did encounter a few bugs but I believe these have since been corrected.<strong>&nbsp;</strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.&nbsp;&nbsp; Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.&nbsp;&nbsp; </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p>Issue: Spearate package name and version fields</p><ul><li>Several people want this</li><li>Should be a Must-Do for 1.0</li><li>Version should be optional or allow for an "Unknown"</li></ul><p>Issue: Confusion/Disagreement over package level licenses - what they mean, how they should be used, what's important</p><ul><li>Still confusion over which license fields are valuable and how</li><li>Scott L - He sees value of Declared and Licenses in File.&nbsp; Not sure about Concluded</li><li>Mark G - He uses the concept of an "aasociated" license -- what the community thinks</li><li>We need to make this a Must-Do for 1.0.</li></ul><p>Issue: Time it takes to do the analysis</p><ul><li>Mark G - Had to be more careful with analysis because he knew that there would be more eyeballs on the results</li><li>Scott L -- uses package level data more.&nbsp; file by file is useful, but package is more important.</li><li>Mark G. - to really get it right, you have to go down to the file level</li></ul><p>&nbsp;</p><p>
+Beta Feedback Meeting 7/7/2011
-<span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px; font-weight: bold;">Antelink -- Freddy Munoz</span></p>
+* Kim Weins, OpenLogic
-<p><span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px;">&nbsp;</span></p><ol><li style="font-weight: normal;"><strong>How well did the SPDX format cover information you need to exchange?<br /></strong>The format provides reliable information about licenses (based on human analysis) and the distinction between the licences who are declared by the package creator and those which are found in files.</li><li style="font-weight: normal;"><strong>What was effort involved in converting to/from SPDX format?<br /></strong>The conversion from the SPDX file format to an object model was easily made.</li><li style="font-weight: normal;"><strong>Did the SPDX format help you understand what was in the software?<br /></strong>The SPDX file format gives declarative fine scale information about the licenses and the origin of each file in the package.</li><li style="font-weight: normal;"><strong>How did the standard license information work for you?<br /></strong>For us the standard license information is very important because is much more precise and reliable than a simple declaration of the licence's name with no standard formatting.</li><li style="font-weight: normal;"><strong>Can you see how using SPDX could save your organization time/money?<br /></strong>When we collect information about open source projects, it would be easier to parse information if the licence information were completely machine readable. SPDX format provides this feature.</li><li style="font-weight: normal;"><strong>Are any changes needed to make SPDX meet your needs?<br /></strong>If any file's licence cannot be defined ("none") it would be better if the format allowed to use "none" as one of concluded licenses.<br />It's necessary to impose every concluded license to be the concluded license of at least one file, otherwise some licenses could be considered as concluded licenses of the package but we cannot know from which file (component) they come from.</li></ol><ul><li>Was pretty happy with the format</li><li>Some concern with different types of licenses - Global license might be overridden by file level license</li><li>If conclusion at file leve is that you are not able to determine a license, how can you create a package level info.</li><li>If you have a match against source code, should that go into concluded license.</li><li>Discussion about "no assertion" vs "none" and what they mean.&nbsp;</li><li>Must-do for 1.0 -- provide guidelines about when to use none vs no-assertion at file level licenses</li><li>Must-do for 1.0 -- provide guidelines on concluded license at file level vis a vis source code matches</li><li>Few artifacts of were tagged.</li></ul><p>&nbsp;</p><p>Additional issues:</p><ul><li>Issue of standardization on package names</li></ul><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p>
+== HP - Scott Lamons ==

@@ Line 1: / Line 1: @@
-<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p>&nbsp;</p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.&nbsp; SPDX potentially provides a better and&nbsp; more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.&nbsp;&nbsp; We did encounter a few bugs but I believe these have since been corrected.<strong>&nbsp;</strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.&nbsp;&nbsp; Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.&nbsp;&nbsp; </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p>Issue: Spearate package name and version fields</p><ul><li>Several people want this</li><li>Should be a Must-Do for 1.0</li><li>Version should be optional or allow for an "Unknown"</li></ul><p>Issue: Confusion over package level licenses</p><ul><li>Still confusion over which license fields are valuable and how</li><li>Scott L - He sees value of Declared and Licenses in File.&nbsp; Not sure about Concluded</li><li>Mark G - He uses the concept of an "aasociated" license -- what the community thinks</li><li>We need to make this a Must-Do for 1.0.</li></ul><p>&nbsp;</p><p>
+<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p>&nbsp;</p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.&nbsp; SPDX potentially provides a better and&nbsp; more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.&nbsp;&nbsp; We did encounter a few bugs but I believe these have since been corrected.<strong>&nbsp;</strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.&nbsp;&nbsp; Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.&nbsp;&nbsp; </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p>Issue: Spearate package name and version fields</p><ul><li>Several people want this</li><li>Should be a Must-Do for 1.0</li><li>Version should be optional or allow for an "Unknown"</li></ul><p>Issue: Confusion/Disagreement over package level licenses - what they mean, how they should be used, what's important</p><ul><li>Still confusion over which license fields are valuable and how</li><li>Scott L - He sees value of Declared and Licenses in File.&nbsp; Not sure about Concluded</li><li>Mark G - He uses the concept of an "aasociated" license -- what the community thinks</li><li>We need to make this a Must-Do for 1.0.</li></ul><p>Issue: Time it takes to do the analysis</p><ul><li>Mark G - Had to be more careful with analysis because he knew that there would be more eyeballs on the results</li><li>Scott L -- uses package level data more.&nbsp; file by file is useful, but package is more important.</li><li>Mark G. - to really get it right, you have to go down to the file level</li></ul><p>&nbsp;</p><p>
 <span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px; font-weight: bold;">Antelink -- Freddy Munoz</span></p>
-<p><span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px;">&nbsp;</span></p><ol><li style="font-weight: normal;"><strong>How well did the SPDX format cover information you need to exchange?<br /></strong>The format provides reliable information about licenses (based on human analysis) and the distinction between the licences who are declared by the package creator and those which are found in files.</li><li style="font-weight: normal;"><strong>What was effort involved in converting to/from SPDX format?<br /></strong>The conversion from the SPDX file format to an object model was easily made.</li><li style="font-weight: normal;"><strong>Did the SPDX format help you understand what was in the software?<br /></strong>The SPDX file format gives declarative fine scale information about the licenses and the origin of each file in the package.</li><li style="font-weight: normal;"><strong>How did the standard license information work for you?<br /></strong>For us the standard license information is very important because is much more precise and reliable than a simple declaration of the licence's name with no standard formatting.</li><li style="font-weight: normal;"><strong>Can you see how using SPDX could save your organization time/money?<br /></strong>When we collect information about open source projects, it would be easier to parse information if the licence information were completely machine readable. SPDX format provides this feature.</li><li style="font-weight: normal;"><strong>Are any changes needed to make SPDX meet your needs?<br /></strong>If any file's licence cannot be defined ("none") it would be better if the format allowed to use "none" as one of concluded licenses.<br />It's necessary to impose every concluded license to be the concluded license of at least one file, otherwise some licenses could be considered as concluded licenses of the package but we cannot know from which file (component) they come from.</li></ol><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p>
+<p><span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px;">&nbsp;</span></p><ol><li style="font-weight: normal;"><strong>How well did the SPDX format cover information you need to exchange?<br /></strong>The format provides reliable information about licenses (based on human analysis) and the distinction between the licences who are declared by the package creator and those which are found in files.</li><li style="font-weight: normal;"><strong>What was effort involved in converting to/from SPDX format?<br /></strong>The conversion from the SPDX file format to an object model was easily made.</li><li style="font-weight: normal;"><strong>Did the SPDX format help you understand what was in the software?<br /></strong>The SPDX file format gives declarative fine scale information about the licenses and the origin of each file in the package.</li><li style="font-weight: normal;"><strong>How did the standard license information work for you?<br /></strong>For us the standard license information is very important because is much more precise and reliable than a simple declaration of the licence's name with no standard formatting.</li><li style="font-weight: normal;"><strong>Can you see how using SPDX could save your organization time/money?<br /></strong>When we collect information about open source projects, it would be easier to parse information if the licence information were completely machine readable. SPDX format provides this feature.</li><li style="font-weight: normal;"><strong>Are any changes needed to make SPDX meet your needs?<br /></strong>If any file's licence cannot be defined ("none") it would be better if the format allowed to use "none" as one of concluded licenses.<br />It's necessary to impose every concluded license to be the concluded license of at least one file, otherwise some licenses could be considered as concluded licenses of the package but we cannot know from which file (component) they come from.</li></ol><ul><li>Was pretty happy with the format</li><li>Some concern with different types of licenses - Global license might be overridden by file level license</li><li>If conclusion at file leve is that you are not able to determine a license, how can you create a package level info.</li><li>If you have a match against source code, should that go into concluded license.</li><li>Discussion about "no assertion" vs "none" and what they mean.&nbsp;</li><li>Must-do for 1.0 -- provide guidelines about when to use none vs no-assertion at file level licenses</li><li>Must-do for 1.0 -- provide guidelines on concluded license at file level vis a vis source code matches</li><li>Few artifacts of were tagged.</li></ul><p>&nbsp;</p><p>Additional issues:</p><ul><li>Issue of standardization on package names</li></ul><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p>

← Older revision		Revision as of 15:44, 7 July 2011
Line 1:		Line 1:
−	<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p>Issue: Spearate package name and version fields</p><ul><li>Several people want this</li><li>Should be a Must-Do for 1.0</li><li>Version should be optional or allow for an "Unknown"</li></ul><p>Issue: Confusion over package level licenses</p><ul><li>Still confusion over which license fields are valuable and how</li><li>Scott L - He sees value of Declared and Licenses in File.  Not sure about Concluded</li><li>Mark G - He uses the concept of an "aasociated" license -- what the community thinks</li><li></li></ul><p> </p><p>	+	<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p>Issue: Spearate package name and version fields</p><ul><li>Several people want this</li><li>Should be a Must-Do for 1.0</li><li>Version should be optional or allow for an "Unknown"</li></ul><p>Issue: Confusion over package level licenses</p><ul><li>Still confusion over which license fields are valuable and how</li><li>Scott L - He sees value of Declared and Licenses in File.  Not sure about Concluded</li><li>Mark G - He uses the concept of an "aasociated" license -- what the community thinks</li><li>We need to make this a Must-Do for 1.0.</li></ul><p> </p><p>

← Older revision		Revision as of 15:42, 7 July 2011
Line 1:		Line 1:
−	<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p> </p><p>	+	<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p>Issue: Spearate package name and version fields</p><ul><li>Several people want this</li><li>Should be a Must-Do for 1.0</li><li>Version should be optional or allow for an "Unknown"</li></ul><p>Issue: Confusion over package level licenses</p><ul><li>Still confusion over which license fields are valuable and how</li><li>Scott L - He sees value of Declared and Licenses in File.  Not sure about Concluded</li><li>Mark G - He uses the concept of an "aasociated" license -- what the community thinks</li><li></li></ul><p> </p><p>

← Older revision		Revision as of 15:05, 7 July 2011
Line 1:		Line 1:
−	<p>~~Add your~~ Beta Feedback ~~Here.  Put your name & company at the beginning of your feedback.~~</p><p>~~ ~~</p><p><~~strong~~>~~My Company -- My Name~~</~~strong~~></p><ol><li>~~feedback item 1~~</li><li>~~feedback item 2~~</li></ol><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p> </p><p>	+	<p><strong>Beta Feedback Meeting 7/7/2011</strong></p><p>Attendees</p><ul><li>Kim Weins, OpenLogic</li><li>Nicholas, Protecode</li><li>Mark Gisi, Wind River</li><li>Kirsten Newcomer, Black Duck</li><li>Bill Schineller, Balck Duck</li><li>Phil Koltun, Kinux Foundation</li><li>Scott Lamons, HP</li><li>Peter Williams, OpenLogic</li><li>Gary O'Neall, Source Auditor</li><li>Phil Odence, Black Duck</li><li>Guillaume Rousseau, Antelilnk</li><li>Freddy Munoz, Antelink</li><li>Pierre Lapointe, nexB</li><li>Jilyane Lovejoy, OpenLogic</li><li>Steve Cropper, Cisco</li><li>Philippe, Antelink</li></ul><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p> </p><p>

← Older revision	Revision as of 14:47, 7 July 2011
(No difference)

← Older revision		Revision as of 14:27, 7 July 2011
Line 1:		Line 1:
−	<p>Add your Beta Feedback Here.  Put your name & company at the beginning of your feedback.</p><p> </p><p><strong>My Company -- My Name</strong></p><ol><li>feedback item 1</li><li>feedback item 2</li></ol><p> </p><hr /><p> </p><p>	+	<p>Add your Beta Feedback Here.  Put your name & company at the beginning of your feedback.</p><p> </p><p><strong>My Company -- My Name</strong></p><ol><li>feedback item 1</li><li>feedback item 2</li></ol><p> </p><hr /><p>HP - Scott Lamons</p><p><strong>How well did the SPDX format cover information you need to exchange?</strong></p><p>The most useful part for our review process is the higher level package information because we require product/project teams to enter information into our tracking system about the open source package they are using/distributing -- often these teams make mistakes or enter incomplete information.  SPDX potentially provides a better and  more trustworthy way for teams to enter this information into our system. </p><p><strong>What was effort involved in converting to/from SPDX format?</strong></p><p>Very straight forward using the tools that Gary provided although it might be helpful to have a GUI based tool for non-expert users.   We did encounter a few bugs but I believe these have since been corrected.<strong> </strong></p><p><strong>Did the SPDX format help you understand what was in the software?</strong></p><p>Yes, the spreadsheet format is well organized and easy to follow.<strong><br /></strong></p><p><strong>How did the standard license information work for you?</strong></p><p><strong>Can you see how using SPDX could save your organization time/money?</strong></p><p><strong>Are any changes needed to make SPDX meet your needs?</strong></p><p>Separate package name and version fields would be helpful.   Combining name and version into the PackageName field will require additional processing and interpretation which we would rather not do since our system has seperate fields for FOSS name and version.   </p><p>Some corrections and comments in the specification are attached in MS Word format.</p><p> </p><p>

← Older revision		Revision as of 10:26, 7 July 2011
Line 1:		Line 1:
−	<p>Add your Beta Feedback Here.  Put your name & company at the beginning of your feedback.</p><p> </p><p><strong>My Company -- My Name</strong></p><ol><li>feedback item 1</li><li>feedback item 2</li></ol>	+	<p>Add your Beta Feedback Here.  Put your name & company at the beginning of your feedback.</p><p> </p><p><strong>My Company -- My Name</strong></p><ol><li>feedback item 1</li><li>feedback item 2</li></ol><p> </p><p> </p><p> </p><hr /><p> </p><p>
		+
		+
		+	<span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px; font-weight: bold;">Antelink -- Freddy Munoz</span></p>
		+
		+	<p><span style="font-family: Helvetica, Arial, sans-serif; font-size: 13px; line-height: 17px;"><ol><li style="font-weight: normal;"><strong>How well did the SPDX format cover information you need to exchange?<br /></strong>The format provides reliable information about licenses (based on human analysis) and the distinction between the licences who are declared by the package creator and those which are found in files.</li><li style="font-weight: normal;"><strong>What was effort involved in converting to/from SPDX format?<br /></strong>The conversion from the SPDX file format to an object model was easily made.</li><li style="font-weight: normal;"><strong>Did the SPDX format help you understand what was in the software?<br /></strong>The SPDX file format gives declarative fine scale information about the licenses and the origin of each file in the package.</li><li style="font-weight: normal;"><strong>How did the standard license information work for you?<br /></strong>For us the standard license information is very important because is much more precise and reliable than a simple declaration of the licence's name with no standard formatting.</li><li style="font-weight: normal;"><strong>Can you see how using SPDX could save your organization time/money?<br /></strong>When we collect information about open source projects, it would be easier to parse information if the licence information were completely machine readable. SPDX format provides this feature.</li><li style="font-weight: normal;"><strong>Are any changes needed to make SPDX meet your needs?<br /></strong>If any file's licence cannot be defined ("none") it would be better if the format allowed to use "none" as one of concluded licenses.<br />It's necessary to impose every concluded license to be the concluded license of at least one file, otherwise some licenses could be considered as concluded licenses of the package but we cannot know from which file (component) they come from.</li></ol><p> </p><p> </p></span></p>