scratch that bit about attendees - Dennis has sent that info!
> On May 17, 2018, at 11:23 AM, J Lovejoy <opensou...@jilayne.com> wrote: > > HI All, > > I’ve posted these notes and the proposal to the meeting minutes page for May > 3rd here, but I don’t know who else was on the call. Can someone fill that > in? > https://wiki.spdx.org/view/Legal_Team/Minutes/2018-05-03 > <https://wiki.spdx.org/view/Legal_Team/Minutes/2018-05-03> > > thanks, > JIlayne > SPDX Legal Team co-lead > opensou...@jilayne.com <mailto:opensou...@jilayne.com> > > >> On May 3, 2018, at 12:36 PM, g...@sourceauditor.com >> <mailto:g...@sourceauditor.com> wrote: >> >> Hi Paul, Brad and Galo, >> >> Below are my notes from the discussion on the SPDX GSoC project “Add New >> License Submittal Feature to Online Tools”. >> >> We would like to have a follow-up discussion with Galo, Paul, Brad and Gary. >> >> We reviewed the use cases in the proposal (attached). >> >> 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 >> <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? >> >> All: Please let me know if I missed anything. >> >> Thanks, >> Gary >> >> ------------------------------------------------- >> Gary O'Neall >> Principal Consultant >> Source Auditor Inc. >> Mobile: 408.805.0586 >> Email: g...@sourceauditor.com <mailto:g...@sourceauditor.com> >> >> <GSOC_2018 -SPDX_Add_Licenses-Galo >> Castillo.pdf>_______________________________________________ >> Spdx-legal mailing list >> Spdx-legal@lists.spdx.org <mailto:Spdx-legal@lists.spdx.org> >> https://lists.spdx.org/mailman/listinfo/spdx-legal >> <https://lists.spdx.org/mailman/listinfo/spdx-legal> > _______________________________________________ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
