Legal Team/Minutes/2014-08-07

Attendees

• Dennis Clark
• Mark Gisi
• Tom Vidal
• Phil Odence
• Jilayne Lovejoy
• Oliver Fendt

NOTE: there will not be a legal call on Aug 21, as it is LinuxCon North America. This means the next call will be on Thursday, Sept 4th. Please use the mailing list liberally in the meantime.

Agenda

1) SPDX License List v1.20 will be live tomorrow, Aug 8!!

• 91 new licenses (81 from the Fedora list review) for a total of 306!!
• also formatting improved on license text to be consistent and easier readability

2) Tasks for 2.0 - update on tasks and timeline

• license expression syntax (Mark) - we have a draft, Mark to re-send to legal list for review via email (soon) and discussion on next call (Sept 4)
  • may need a related FAQ - Mark offered to start this; will start on a Google doc so others can contribute (soon). Where this should live? if spdx.org is more for consumers, should probably go there - will discuss further exactly where, probably in the License List section - do we need to add a page or nav link, etc.? --> please help out on this by adding questions and answers!!
• reviewing the draft of the spec itself - generally and for reference to license expression syntax, Tom V. is on this: waiting for more complete iteration of spec to review - check back after LinuxCon (last week of Aug)
• review of website, Paul has completed a first pass identifying areas that will need review, just need to make actual changes before 2.0 release (early October)
• license matching templates, Jilayne - bring any remaining question to next legal call (Sept 4)
• license list itself - identifying licenses to be deprecated and marking as such, Jilayne - to start once v1.20 is live
• exception list, Dennis - available to view here: https://docs.google.com/spreadsheet/ccc?key=0AmVnI0dGKEo1dDF0ajVveUtRMGFseVVjWS1zV2tCNFE&usp=drive_web#gid=0
  • we had decided to take a conservative approach and not add any new exceptions for the 2.0 release to err on the side of caution since it is a big change; existing exceptions are indicated with "2.0" in the release column
  • Dennis has identified suggested next round additions with a "2.1" in the release field - to be discussed as 2.0 release gets closer
  • then need to add to license list spreadsheet and determine how to display on website, Jilayne and Gary to do by 2.0 release
• education for 2.0 - this is a big shift, should we do a webinar? or something to that effect?
  • probably need to give people several opportunities to ask questions; FAQs will help with this
  • timing for a webinar - right after the spec comes out seems like a good time
  • everyone liked the webinar idea - Phil to take lead - plan in advance for date, announcement, and coordinate with LF
  • blog might be good too

3) Oliver's questions from mailing list regarding license identification and proper (or customary) use of various SPDX fields:

1. how to identify the license information (particularly for the Concluded License field) for the license itself, e.g., the LICENSE.txt?
2. how to record or capture additional text that attempts to clarify the terms of the license, e.g., Linus Torvald's notice for Linux kernel and derived works

• summary: we only discussed #1 on point, as well as some general discussion as to the scope of how much "advice" SPDX wants to offer as a workgroup and/or how to best capture user's questions, experiences, and practices
• clarification that SPDX does not purport to provide legal advice or make any interpretation, which these questions could hinge upon.
  • as to #1 - in the case of GPL, the license itself has a copyright notice and license terms of sort, but many open source licenses do not specify this, which begs the question as to whether they are to be treated as any other legal agreement (in terms of whether copying is assumed to be permitted, practical reality, etc.). For the Concluded License field, one might put the same license itself; a LicRef with the specific comment about use of the license (as per Oliver's email) or NOASSERTION (or leave it blank) - which scenario is best will depend on the SPDX user's goals for the document, level of detail desired, and some amount of legal interpretation regarding what is the license for the license. There is really no "right" answer. Community practice may point towards just calling it the same license, but that is not an "answer" or may not be the best way or appropriate way for a particular SPDX user
  • one might come up with different answers to this question whether thinking in terms of legal practice, common practice, community practice or "best" practice
  • do we need a wiki compiling common practices with creating SPDX files that anyone can add to? but how to balance against need for SPDX to not appear to offer advice or interpretations
  • there is always the option for anyone to write a Tech Report on their experiences, which might be the best way to capture such information, see http://wiki.spdx.org/view/Tech_Reports
  • mailing list is always good place to start discussions, but downside is that it's hard to find later (same with meeting minutes to lesser extent)