Legal Team/Minutes/2015-01-08

Attendees

• Jilayne Lovejoy, ARM
• Tom Incorvia, Micro Focus
• Dennis Clark, NexB
• Alan Tse, Western Digital
• Daniel German, U. of Victoria
• Gary O'Neall, Source Auditor
• Sam Ellis, ARM
• Mark Gisi, Wind River

Agenda

Confusion as to dial-in (Jilayne's fault). Always use dial-in here: http://wiki.spdx.org/view/Legal_Team New invite for 2015 that is recurring to be sent soon.

1) SPDX License List 2.0-release candidate is up!! see: http://spdx.org/licenses/preview/ - In following the spec, this is a release candidate available for testing, etc., but the official released version is still v1.20 found in the usual places. We looked through the web pages and identified some areas of improvement as follows:

• Add text at top to make clear that this is release candidate, not official release yet for extra clarification
• Deprecated licenses - need to change sentence in description to match reality (links do still work)
• Exceptions page (and link) - need to add better/more descriptive language that ties it to the expression syntax
  • in terms of where to put link to Exceptions - should be higher up, not included with the bullets that are more about process or background info
  • add new paragraph after general description and before "other information relevant"
• add link to License Expression Syntax (to spec) in list of "other relevant information" with explanation
• also need to review (and update as needed) Overview, Matching Guidelines, and and Request a New License
• --> Jilayne to put up above info and edits; people can review before next call on Jan 22

• Daniel brought up idea of license synonyms - no time to discuss fully, so will send description via email for all to review and then discuss on next call

2) Composite Licenses - issue raised by Sam Ellis via mailing list and follow-up questions from Alan Tse

• licenses on SPDX License List that are actual multiple licenses (a stack or composite) that represent the licensing scheme for a particular project or release. Some include:
  • http://spdx.org/licenses/OpenSSL
  • http://spdx.org/licenses/Python-2.0
  • http://spdx.org/licenses/SAX-PD
  • http://spdx.org/licenses/Sleepycat
• These could be described by several licenses using new License Expression Syntax, so should be break it down by those licenses or keep it with the project name?
• Explanation by SPDX License List veterans as to how we got here... long history of sweating over how to deal with some of these (Python example) and some we probably took as is (due to it being that way elsewhere, e.g., OSI / Sleepycat)
• can we go back to more atomic level licenses? especially now that license expression syntax allows this (better)? can we make this a rule? or do we need to review case-by-case?
• discussed Python scenario a bit - may be hard to break apart. What about Sleepycat? - might be like this because its represented this way on the OSI site - could this be cleaned up by including only the Sleepycat part with minimal breaking... good timing to reconsider in any case and really good to have some new perspectives on the issue!! (thanks Sam and Alan!!)
• reality of multiple licenses is an artifact of software that evolved over time
• path forward: have a general rule that a license is one item; but then there are some exceptions to this rule and an explanation as such
  • check list for any other cases of this; review each on case-by-case basis; other considerations, etc.
• timing - no way to get this done for 2.0, but can start working on it

NEXT CALL: Jan 22

• go over 2.0 release candidate web changes, etc.
• new license requests:
  • ICU
  • W3C Document Notice and License
  • W3C W3C Document License
  • W3C Software Notice and License (1998-07-20)