THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Legal Team/Minutes/2020-01-16
2020-01-16
Attendees
- Mark Atwood
- Mark Baushke
- Brad Edmondson
- John Horan
- Steve Winslow
Minutes
Much of the meeting focused on reviewing issues tagged for the upcoming 3.8 release. Comments on specific issues are contained in the particular GitHub issue threads at https://github.com/spdx/license-list-XML/issues
A handful of the pending requests for 3.8 are dependent on the next steps with the license inclusion guidelines. In light of Jilayne's absence and Steve not making progress on a revised draft proposal for the guidelines, they are not likely to be changed for 3.8, so the related issues were agreed to be moved to 3.9.
Lengthy discussion occurred regarding various requests over the past couple years that involve licensors' ability to make multiple choices from within a certain license. E.g., where a licensor has chosen to use OFL-1.1, they can also optionally choose to specify a "Reserved Font Name"; if they do, then it has a different set of obligations than if they do not.
For OFL the decision was made to go ahead and add separate entries for the different options. However, as a broader question it was discussed whether the license expression syntax should be modified to accommodate this, and to enable users to be able to better articulate selections or choices of options within a single license. The following possible approaches were discussed:
- Adding separate license entries for each combination
- Use the WITH syntax; change the meaning of the "exceptions" list to something different, since not all of these are "exceptions"
- Create a new syntax, such as USING or SELECT; list the options in a manner separate from the "exceptions" list
- Don't do anything; keep adding separate options to the license list where it seems appropriate, but otherwise let people use LicenseRef- IDs if they want to be more precise
Other comments noted that selections could veer away from what is otherwise an "open source" license, and could be useful but also potentially harmful. In particular, care should be taken to avoid conflating "exceptions" with things that take away rights. The approach here should focus on articulating options within the four corners of the license, not as a mechanism to modify licenses with external texts.
2020-01-30 update: Steve has submitted an issue summarizing this in greater detail at: https://github.com/spdx/license-list-XML/issues/970
