Difference between revisions of "Legal Team/Minutes/2013-11-07"

Latest revision as of 19:12, 7 November 2013

Attendees

• Jilayne Lovejoy
• Jack Manbeck
• Denis Clark
• Zac White
• Phil Odence
• Mark Gisi
• Tom Vidal

Agenda

1) License Matching Guidelines (Jilayne) - The SPDX License List Matching Guidelines have been updated as per previous feedback, please have a look here: http://spdx.org/spdx-license-list/matching-guidelines for one last proof read, as there were a couple changes that no one commented on.

• brought up version numbering for license list - does it need to follow spec (in terms of 1.x and 2.x)? or can it follow it's own numbering? does it matter?
• if own numbering, what constitutes a "major" release? (if doing own version numbering, if follow spec then don't have to define "major" release)
  • when we get the GPL-exceptions resolved
  • when we release all the templates for matching guidelines
• maybe just follow spec numbering b/c license list will change incrementally
• no set decision here, something to keep in mind for next release and can decide then

2) "or later" and other license short identifier modifiers (Mark Gisi) - discussion has been going on via list; Mark in process of scheduling a special meeting for this topic

• Mark will send out a time for the meeting today, based on feedback from people who emailed him directly - will send to invite will go broad
• as for a descriptive name: revisit current SPDX mechanism for describing license info using both the SPDX License List and the Boolean operators (via the spec, i.e., "and" and "or")
• if you haven't responded to Mark re: your interest, please do; Phil will also circulate a plug via the general meeting minutes later today
• discussion on this will begin with common examples and then discuss how to use SPDX to express them; goal to represent as much as possible of what's found without that syntax being too complicated or difficult
• acknowledged practical implementation involves both SPDX License List and spec itself - need to work together effectively, but also need to keep in mind how to execute any changes
• as for SPDX License List - this involves the "or later" issue (in particular for GNU license, but there are others that allow "or later" as well) and then how to best identify exceptions; current approach treats each license as a separate "line item" on SPDX-LL
  • in regards to exceptions - also have to consider matching guidelines - right now, matching on all of text of main license plus exception is probably not all that effective

3) GPL exceptions (Tom V. & Mark Gisi) - update on progress

• Tom and Mark have conferred; Tom was to convert document to a Google drive doc, so everyone can access - he has a few more exceptions he found and then do that and share it
• list is very comprehensive!!
• will discuss for next call

4) Fedora list (Zac) - update, new licenses to cover, and some discussion about short identifiers

• for short identifiers - try to go with Fedora name, unless there's reason to change it
  • obvious scenario with "MIT" licenses - Fedora calls a lot of licenses MIT that will have a different name on SPDX License List
  • example, AMPAS BSD on Fedora, SPDX is calling AMPAS b/c thought it was confusing to use "BSD" as it's not really a BSD
• discussion around rationale for adding to SPDX-LL - if it's on Fedora list, do we just add it to SPDX-LL full-stop or do we put some that are really rare or very one-off on a "waiting list" with idea that we can add it later and with idea that with limited resources, we are not going to add everything all at once. these licenses will be identified as "queued" in the Google doc - meaning we have no major objectino to add them, but they just seem so rare it is not a priority to add at this time
• Aspell-ru License - agreed to add, but have issue of what it the entire license; Fedora has what appears to be "just" the license but Gentoo link Zac found has additional stuff at the top; this could be handled via a template to make such text "omitable" - going to put this on hold, as others like this may come up later and this way, we can ensure that such scenarios are all dealt with in a consistent manner