Business Team/Minutes/2011-03-17

From SPDX Wiki
Jump to: navigation, search


  • Kim Weins
  • Phil Odence
  • Kate Stewart
  • Gary O'Neall
  • Jilayne Lovejoy
  • Kirsten Newcomer
  • Kamal Hassin
  • Mahshad Koohgoli
  • Esteban Rockett
  • Scott Lamons

BMW Questions

We will add these to the FAQ in the Wiki

  • Q: Do you have to include every file in the SPDX file?
  • A: Yes -- although you can define the package to include whatever files you want and can have unknown info
  • Q: Is there a way to include notes on on how files are linked?
  • A: There is a free form comment field that can be used for this

Kim to add these to FAQ in wiki and broadcast to various lists


  • Business training materials -- Kim started with Beta Orientation deck -- will add stuff as needed
  • Technical training materials -- Kim to ping Peter W
  • Tools training materials -- Kristen has materials from Gary and will be working on it

Process for Adding New Standard Licenses.

We did not finish discussion, so will continue at next meeting. Notes so far are below.

  • Anyone can request license to be added through a web form (possibly Bugzilla).
    • Protecode might be able to implement web form to integrate to Bugzilla
  • Information- some will be required fields
    • Person Name
    • Email
    • Organization - community/company
    • License name
    • Actual license text
    • URL for where they found license text
    • Comments -- why they want it
    • Example(s) of open source packages/files that use it
    • Why they want it -- is it their own license or is it something they have encountered in audits
    • Is it going thru OSI approval?
    • Other notes or we need to know
    • Make application as close to Wiki page as possibe
  • Process
    • First validation/vetting for complete/correct info - contact person who submitted it
    • Decision making by group
      • Allow comments in a timeline
      • Start with an open ended time
      • Have business team make decision initially until we see what the volume is
        • Shoot for doing this first year unless it's getting out of hand
      • Way to batch it - handle at biz team meetings
      • Can have some where we decide to "defer" for now.
      • Business team will decide -- likely based on majority vote for people that attended the meeting (at least 5 people and 1 legal)
      • Publish the ones we will vote on 2 weeks in advance to full list. Discussion/comments on biz list.
        • Set up a separate wiki page to keep the list tracked of what we are voting on when
    • Later -- Have a more formal committee that makes a decision - 5-7 people
      • Should have 2 legal spots on community
      • Might want at least one community spot
      • Nominations (including self nominations) make clear the requirements
      • Way to adjust if someone is not participating
    • Assignment of standard name
      • Have pilot propose a standard name (short and long) based on our rules
      • Review and agree on that when we vote
    • Data entered into repo and templatizing is done
      • Templatizing should be automated process
    • Review/QA of the data in the repo
      • Have a legal person look to make sure it's OK and nothing is broken
  • Suggested Criteria
    • Center of gravity is OSS license but will consider freeware or other licenses that are widely encountered. For example would consider Sun Binary Licenses. Things that share many/all of OSI attributes - but may have additional requirements
    • Not for purely commercial licenses (ex EULA, or Oracle license)
    • License must be publicly accessible
    • License that is seen across multiple projects or on a heavily used project
    • License that will be popular in future (eg new version of GPL, Apache)
  • Need a statement that we don't necessarily consider all these licenses to be open source - just trying to facilitate a way to refer to them. Check how Fedora does this (talk to Spot)
  • Who does stuff
    • Could have one person "pilot" assigned to a license and have them follow it through process all the way to finish to put in repo
    • List of volunteers willing to be pilots and rotate through that list -- show list on site
    • Assign the Bugzilla issue to someone (manually initially) -- Kim will assign names manually
    • Automatically send comments to mailing list when bugzilla form is updated
  • Timeframe
    • Will need to set expectations for turnaround time
    • Likely a 2-3 month period (rough target -- not a guarantee)
      • 2 weeks -- Time to vet
      • 2 weeks to comment (min)
      • 2 weeks in advance to schedule a vote
      • 2-4 weeks to enter in repo and QA after approval