Skip to content

Business Team/Process for Adding to License List Draft

Archived page

Read-only copy of the SPDX wiki. The wiki is no longer active; its content has moved to https://github.com/spdx. Last edited 2013-02-28 by MartinMichlmayr.

  • Process
  • First validation/vetting for complete/correct info - contact person who submitted
  • 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 requester/"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
  • Allow people to submit directly to Bugzilla or via a form on the site
    • To use Bugzilla, you have to register, so that might filter people out, so if we had a form on the site that would work. That form could send an email and then someone can manually enter in the bug database
  • Automatically send comments to mailing list when bugzilla form is updated
  • For bulk groups of licenses we could put them thru in bulk -- and have a bit of a different process
  • Need to discuss how we will turn the license list spreadsheet into the web pages. Right now it's a multi-person process and we will need to streamline.
  • 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

Categories: Archived, Business