Difference between revisions of "Legal Team/Minutes/2018-05-03"

Latest revision as of 17:25, 17 May 2018

Attendees

• Gary O'Neall
• Paul Madick
• Brad Edmondson
• Steve Winslow
•  ? someone from Amazon

Agenda

1) discussed Google SoC project: We reviewed the use cases in the proposal: https://wiki.spdx.org/images/GSOC_2018_-SPDX_Add_Licenses-Galo_Castillo.pdf

There were three key points made during the review:

• The primary motivation for the tool is to make it easy for the submitters (the Producer actor)
• The legal team would like to continue to use github issues to track new license submittals as opposed to using the tool forms
• To keep the scope of the project achievable, we can take an incremental approach

Discussion prior to the use case reviews:

• Do we want to require a github account for the Producers: We agreed that the Producers would not need a github account and could log in anonymously as long as an email is available
• How do we know if the email is valid? [I believe we decided this didn’t need to be resolved on the first release]
• We should describe why the email is needed for the submittal – e.g. in case there are any questions, follow-up required

UC-001 Submit a license request:

• We should validate the license is valid and is not a duplicate license
• Anonymous login OK as long as email address is captured
• As a post condition, a github issue should be submitted with the proper tags to denote a new license request. The Github API’s can be used for this purpose: https://developer.github.com/v3/issues/#create-an-issue
• We could add some helpful information on the different fields (e.g. what a short-identifier is, pointer to the OSI license list)

UC-002 View submitted license requests:

• Since the legal team will use the github issues list to track, the view function will primarily be used by producers and people interested in the status outside of the legal team itself. We did feel this was still a valuable use case, just with different actors.
• No need to authenticate – could be a public access view
• Suggest the following states for the license: submitted (non-reviewed), submitted (under-review), approved, rejected
• The state could be determined by the tags in the issue within github
• We discussed what we would list under approved – all licenses? Just licenses submitted through the app? We agreed that the list under approved would be all licenses which have been approved but not yet released/published. Once a license is released/published it would no longer be visible. We could add a link to the listed licenses page as a reference for all published licenses.

UC-003 and UC-004 Approve and Deny license request:

• Not needed since the legal team will use github for tracking status

UC-005 View a license request information:

• The actors would include the Producer and also the general public
• Could be a drilldown from the view on UC-002

UC-006 Generate a license XML file

• Actor would be the legal team since the Producer will not be required to have a github account necessary for the pull request.
• Ideally, this could generate a pull request, but it could just download the XML and the user could create the pull request.
• We would need to also download a test file which would be the text of the license.

We also discussed if the original submittal should generate the pull request with the XML file and we decided it should only generate the issue.

We discussed a scenario where there may be a family of licenses submitted together. Should we support multiple licenses submitted in the same issue?