Legal Team/Minutes/2016-01-21

Attendees

• Dennis Clark
• Kyle Mitchell
• Mark Gisi
• Jilayne Lovejoy
• Alas Tse
• Eric Weddington

Agenda

1) Summary from joint call on Jan 19 with tech team - see notes posted here:

• Key next step: Kris to post actual example of new markup and joint call with tech team on Tuesday, Feb 2 @ Tuesdays at 18:00 GMT (10:00AM PT, 11:00 MT, 12:00PM CT, 1:00PM ET) - Jilayne to send invite to Legal team
• Kyle able to help from tech and legal side - he'll confer with Kris after Feb 2 call
• discussed that anything that enables people to contribute is a good thing (not everyone can make calls, etc.), but care needs to be taken at opening the fire hose on the license list via Github as Github may create "drive-by" pull requests and mailing list might be still better for some things
• will be good to have nailed down documentation of process for various changes; in trying to articulate process, will help us think through these potential issues
• Gary O'Neall has put up a Google doc with proposal of process: add comments there and we'll schedule time to discuss more thoroughly on upcoming call(s): https://docs.google.com/document/d/115Lis1SJV7Rp-XuNjIysU61urzFGjUOBPqEdVyGLsfI/edit
• Note: Collab Summit is Mar 29-31, Squaw Valley, CA - would be good to have as many people there as possible

2) new licenses on OSI list: review to add to SPDX, decide on short identifiers

• if OSI adds a license, should it automatically be added to SPDX list? all assumed this was the case, but not articulated. At that point, it meets OSD (no reason for us to re-hash that!) and it's just a matter of coming up with short identifier and mechanics of getting it on license list. Need to add a sentence to this effect on the overview page: http://spdx.org/spdx-license-list/license-list-overview (Jilayne to come up proposed text to add and where to add it - email to group for vetting).
• OSI has become active with adding licenses as of recently; need to define process to get heads up so we can come up with short identifiers for them to add to their website in consistent fashion - working on this. (OSI displays SPDX short identifiers in ( ) next to license name in list and on license page and as URL
• maybe good to give OSI something as placeholder: to put in parenthesis, e.g., (SPDX identifier to come) and something to put on the page itself, e.g., a notification that SPDX identifier is coming and that URL might change. Kyle to provide Kate with some proposed language.
• http://opensource.org/licenses/OPL-2.1 - somewhat problematic because OSET Public License in their exhibit uses "OPL" but this is already an abbreviation and short identifier for the Open Public License, which is an older license that is already on SPDX and Fedora list (http://spdx.org/licenses/OPL-1.0.html). Suggestion to reach out to OSET authors to ask to change short identifiers. Eric volunteered to do this. We will also let OSI that we are undertaking this route.
• http://opensource.org/licenses/LiLiQ-P-1.1 - accept for next SPDX License List with LiLiQ-P-1.1 as short identifier, no markup, in French with link to English
• http://opensource.org/licenses/LiLiQ-R-1.1 - accept for next SPDX License List with LiLiQ-R-1.1 as short identifier, no markup, in French with link to English
• http://opensource.org/licenses/LiLiQ-Rplus-1.1 - accept for next SPDX License List, don't want "+" in short identifier b/c of operators (also may be problematic to use in URL), will use: LiLiQ-Rplus-1.1, no markup, in French with link to English