THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Business Team/Beta Program/Feedback

From SPDX Wiki
Jump to: navigation, search

Beta Feedback Meeting 7/7/2011

Attendees

  • Kim Weins, OpenLogic
  • Nicholas, Protecode
  • Mark Gisi, Wind River
  • Kirsten Newcomer, Black Duck
  • Bill Schineller, Balck Duck
  • Phil Koltun, Kinux Foundation
  • Scott Lamons, HP
  • Peter Williams, OpenLogic
  • Gary O'Neall, Source Auditor
  • Phil Odence, Black Duck
  • Guillaume Rousseau, Antelilnk
  • Freddy Munoz, Antelink
  • Pierre Lapointe, nexB
  • Jilyane Lovejoy, OpenLogic
  • Steve Cropper, Cisco
  • Philippe, Antelink

 


HP - Scott Lamons

How well did the SPDX format cover information you need to exchange?

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.

What was effort involved in converting to/from SPDX format?

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. 

Did the SPDX format help you understand what was in the software?

Yes, the spreadsheet format is well organized and easy to follow.

How did the standard license information work for you?

Can you see how using SPDX could save your organization time/money?

Are any changes needed to make SPDX meet your needs?

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.  

Some corrections and comments in the specification are attached in MS Word format.

Issue: Spearate package name and version fields

  • Several people want this
  • Should be a Must-Do for 1.0
  • Version should be optional or allow for an "Unknown"

Issue: Confusion over package level licenses

  • Still confusion over which license fields are valuable and how
  • Scott L - He sees value of Declared and Licenses in File.  Not sure about Concluded
  • Mark G - He uses the concept of an "aasociated" license -- what the community thinks
  • We need to make this a Must-Do for 1.0.

 


Antelink -- Freddy Munoz

 

  1. How well did the SPDX format cover information you need to exchange?
    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.
  2. What was effort involved in converting to/from SPDX format?
    The conversion from the SPDX file format to an object model was easily made.
  3. Did the SPDX format help you understand what was in the software?
    The SPDX file format gives declarative fine scale information about the licenses and the origin of each file in the package.
  4. How did the standard license information work for you?
    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.
  5. Can you see how using SPDX could save your organization time/money?
    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.
  6. Are any changes needed to make SPDX meet your needs?
    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.
    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.