Difference between revisions of "Legal Team/Minutes/2013-04-16"

Latest revision as of 20:06, 6 June 2013

SPDX Legal Team - LF Collab Summit working session, April 16th, Tuesday, 2-4pm

Attendees

• Jilayne Lovejoy, OpenLogic
• Phil Odence, Black Duck
• Dennis Clark, NexB
• Kirsten Newcomer, Black Duck
• Gary O'Neall, Source Auditor, SPDX tooling
• Jack Manbeck, TI
• Samir, Winter Systems
• Jessica Mars, Intel
• Jason Buttura, Cisco
• Daniel German, University of Victoria
• Zak White, Entente
• Michael Herzog, NexB
• Eugene
• Tom Vidal, Abrams Garfinkel Margolis Bergson
• Norm Lode, Protecode
• Scott Lamons, HP
• Paul Madick, HP
• Michael Rhone, VMware
• Adam Cohn, Cisco
• 3 latecomers with no introduction

Overview

Reviewed the current License Matching Guidelines (last reviewed in June 2012) as well as minutes of previous meetings on the topic and where we last left off. SPDX uses a conservative approach to matching licenses (as opposed to Fedora, who defines multiple variants as all being the “MIT License” based on how to comply with the license), that is, a match will be based on the substantive text, not any interpretation related to license compliance. The SPDX License List only includes standard headers, defined as when the license delineates a precise header, either via suggested quoted text or an exhibit to the license. Matching guidelines for standard license headers will be the same as for licenses and the license substantive text. The title of a license, as well as copyright notices, do not affect the substantive text and are not relevant in terms of matching to the license itself, thus can be ignored. Main question is whether: 1) SPDX should offer just guidelines alone and let tool makers free range in how to implement; or 2) go a step further and provide markup for the licenses illustrating what text can be ignored (e.g. copyright notices, title, preambles or other intro text, exhibits at end) or is replaceable (e.g. copyright holder's name in third clause of BSD; third, fourth, and fifth clauses of Apache 1.1; or in disclaimer clauses). And, if the latter, how to provide such markup in a way that is useful to toolmakers yet not resource-intensive for the SPDX Legal Team to create (for the current list) and maintain.

Discussion

If some kind of markup is not provided, this leaves room for interpretation. However, type of markup cannot be too strict or specific as to stifle how toolmakers implement their tool. SPDX goal to identify “replaceable text” and “omittable text” for licenses on the SPDX list. Two options proposed previously for doing this:

1. Using double curly brackets and double straight brackets (or some other character unlikely to be found "in the wild") to identify license text as either “replaceable” or “omittable”
   1. Pros: easy to implement, can use in .txt files
   2. Cons: doesn’t stand out enough, plus it changes formatting
2. Using HTML CSS tags (defined div tags) and highlighting to color-code license text as either “replaceable” or “omittable”
   1. Pros: relatively easy to implement, creates nice visual on website pages
   2. Cons: may not be all that helpful for toolmakers; how to still maintain .txt file versions of license text?

Question: are we making an interpretation of the license by defining what is changeable? Answer: only minimally; just enough to identify the license with tools

Question: can we rely on guidelines to address changeable copyright notices and license titles (rather than marking them); or should we rely on markups and remove those guidelines? Answer: rely on guidelines because there is only one known exception, BSD-4-Clause (UC-specific) Markups are still a type of guideline that toolmakers must use to build their matching tools Working through examples may make us aware of further problems and exceptions

Defining text as changeable leaves room for changes to license terms (e.g. replacing “must” with “must not”) or the addition of additional license terms; legal team may need to provide guidance here as to what it can be replaced with

Question: Since pluralization is sometime okay and sometimes not, do we need to use markups to define all possible variations? Answer: If so, then we would also need to markup equivalent punctuation, contractions, word meanings, etc, which is too burdensome; therefore we need to rely on guidelines

Equivalents to be added to Varietal Word Spelling area:

• Sub-license, sub license, and sublicense
• All types of quotation marks
• Similar forms of punctuation

Requirements group agreed on:

• If we want to provide markups, we need to be able to accommodate TXT files
• Need to be able to maintain ONE file, from which other "versions" (e.g. HTML for webpage) can be generated in some automated fashion.

File Format Options:

1. Text files with inline markup (e.g. use curly brackets and other identifying characters), then render:
   1. a HTML file for the webpage (this is how it works now)
2. Start with an HTML file with markups, then render:
   1. a TXT file stripped of all markups, and
   2. do we also need a TXT file with inline markups?
3. Start with canonical text (in either format), plus provide:
   1. a summary of common changeable text, or tags describing the text to be replaced or ignored and
   2. examples of common variations for licenses that may have changes

The group supported option #1 above, and suggested using markups such as the following:

{ { omit:This software consists of…} }

{ { replace:The Apache Software License, Version 1.1} }

The above markup convention has the added benefit of allowing developers to effectively generate their own license files by inserting the applicable text.

The idea of naming the matched text was discussed. For example, “copyright” could be used to denote the replaceable copyright text in the MIT license. The group generally agreed this would be useful, but no conclusion was reached as to how to implement the proposal.

Further ideas on exact form of markup discussed further after meeting . Daniel German submitted a proposal post-meeting with examples (link to GitHub, see email sent to legal-team mailing list). Specifics of form of markup to be further discussed amongst legal and tech teams.