General Meeting/Minutes/2016-02-04

• Attendance: 11
• Lead by Kirsten Newcomer

• Minutes of previous meeting were not reviewed

Special Presentation - Jack Manbeck[edit]

• Jack spoke about Texas Instrument’s (TI) process for generating and content of the manifest (attribution) file. Below are my notes from the presentation. Jack, please send corrections as needed!!

• Jack shared an example file in HTML format. There is a section for licenses and TI is considering replacing this section with an SPDX document showing file-level data. 

• TI considered using the yocto integration to generate SPDX files, but the output was too big. They decided to scale back and start with the project and a more narrow scope.

• The goal is for any engineer to be able to generate an SPDX document. Which means tooling that is easy to use and integrated with multiple build tools and / or CI tools. It also needs to run on multiple platforms. 

• There are a series of steps in the TI process
  • Grab OSS and evaluate for use. It doesn’t make sense to generate SPDX at this time although you need some of that info to evaluate the open source. But things that SPDX requires change too quickly, such as location of the file, checksum (bug fixes to file).
  • So, it makes more sense to generate the SPDX file when you’re ready to ship
  • Then you have to edit the doc; it’s not usable as is, in part due to incomplete copyright strings, or possibly extracted license text
  • If files need to be edited, or the code needs to be re-built, the SPDX file needs to be re-generated and then re-edited. So, a tool that retains and re-applies previous edits that still apply is very much needed.
  • Would like to share / re-use generated SPDX docs, but the best way to share isn’t clear.
  • TI is looking at SPDX 2.0 and considering whether relationships between generated SPDX docs can help
  • Don’t want to have to use multiple tools for compliance and SPDX
  • Consider SPDX to be a good supplement to their manifest file but doesn’t replace it.
  • They still need to vet the process and polish
  • Jack mentioned a copyright snippet example where the output was not good enough. They’re evaluating different tools to use. They like the SPDX tools from UNO. 
  • They’d like, in some cases, to provide file by file list which could be done through a link to SPDX doc. 
  • They’re looking at Fossology and SPDX plugin. Also mentioned that it would be nice to get an idea of license spread at the beginning. 

• Matt mentioned additional tools built by UNO, including DoSocks (spelling?) and Gary’s maven plugin which generates SPDX docs based on maven POM content. 

• Kate mentioned Fossology 3.0 and Deb sources as well as FOSDEM and notion of a shared database of SPDX documents. 

• Matt said that the UNO tools don’t store SPDX docs but instead store the data so the docs can be generated when required. Jack sees this as the right approach.

• TI’s plan is to first build a repeatable process and then they can do more to enhance it. The checksum in SPDX documents is a challenge because files change right up to the last minute. 

• Dave Marr commented that the model he’s interested in is having SPDX perpetuate through a development cycle with minimum impact on the team. Would like to be able to check code in with meta-data so that the meta-data travels with the file. 

• Gary said that he’s seen this approach both work and not work. Tried an integration with IDEs but there was too much change for it to work. Says the Maven plugin seems to be pretty effective in maintaining the meta-data and the integration recalculates the checksum. Solution does assume that the data in the POM is correct. POMs are stored in the repository and the SPDX is generated at build time. Developers are used to editing POM files. 

• Jack commented that in a structured environment that works, but TI needs a solution that works across multiple environments. 

• Dave commented that training for engineering is needed — when you add or subtract content, here’s what you need to do. 

• Jilayne would like engineering training for lawyers, with graphs, not just text. 

• Everyone thought this would be a good overall topic for Collab Summit. 

Tech Team Report - Kate/Gary[edit]

• Team is continuing discussions on External References. The work is close to being ready for a broader review. 
• Joint tech / legal call on license markup planned for 2/9.
• Discussions happening with Richard Fontana at OSI

Outreach Team Report - Jack/Kate[edit]

• Planning for Collab Summit: 1/2 day Tech team and 1/2 day Legal, with SPDX “Office Hours” for folks to bring questions, issues. 
• Good mentions of SPDX @ FOSDEM
• LF says new website is close to being staged for review; Jack hopes it will be up for Collab Summit
• Planning webinars in first quarter. Pierre has volunteered and the first will be on the license list. 

Legal Team Report - Jilayne/Paul[edit]

• Working on proposal for license matching
• Working on tighter communication with OSI

Cross Functional Topics - Kate[edit]

• Save the date for Collab Summit in Lake Tahoe- March 29-31
  • http://events.linuxfoundation.org/events/collaboration-summit/program/about
• Google Summer of Code: Gary will be coordinating for the SPDX team. We’re looking for ideas for good projects. 

Attendees[edit]

• Kirsten Newcomer, Black Duck
• Gary O’Neall, SourceAuditor 
• Scott Sterling, Palamida
• Kate Stewart, Linux Foundation
• Pierre LaPointe, nexB 
• Jilayne Lovejoy, ARM
• Kirsten Newcomer, Black Duck
• Jack Manbeck, TI
• Dave Marr, Qualcomm
• Eric Weddington
• Hassib Khanafer, Protecode
• Matt Germonprez, UNO