Legal Team/Minutes/2019-09-05

2019-09-05

Attendees

• Mark Atwood
• Mark Baushke
• Richard Fontana
• John Horan
• Jilayne Lovejoy
• Paul Madick
• Philippe Ombredanne
• Steve Winslow

Minutes

Discussed workflow for PRs coming in without a corresponding issue

• New licenses should always have an issue
• for minor changes, e.g. markup fixes, PR only is fine
• CONTRIBUTING file should be expanded to explain this, e.g.: non-substantive changes or corrections to existing licenses

Polyform / License Inclusion Principles: Move Polyform to next release (3.8).

1. Solidify license inclusion principles as currently exists; point website to GitHub docs
2. Then, discuss in Github issue

Comments during call:

• Include source available licenses, where intended for widespread use, and written by someone “third party” go on list; by companies for their own projects, goes in their own namespace
• Some interest in including source available licenses on the list, whether b/c of use case for using that license for one’s own project, or to facilitate other FOSS projects being able to avoid them
• Concern about SPDX license list being used as a mechanism to promote hitherto-not-heavily-used licenses
• Maybe another factor is: If a license doesn’t substantially comply, then maybe it can still be added but has to meet these other criteria: e.g. not company-specific; maintained in a versioned way; significant enough use in the wild; and/or license steward’s “constellation” of licenses has significant enough use in the wild

Current issue for discussion of updates to license inclusion guidelines: https://github.com/spdx/license-list-XML/issues/925

Python-2.0: Discussed whether should be split up into separate versioned licenses; earlier SPDX participant did a whole forensic analysis of Python license pieces. May not want to re-open but should at least document earlier decisions that were previously made.