THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Legal Team/Minutes/2019-06-27

From SPDX Wiki
Jump to: navigation, search

Attendees

  • John Horan
  • Mark Atwood
  • Steve Winslow
  • Jilayne Lovejoy
  • Paul Madick
  • Brad Edmondson
  • Mike Dolan

Agenda

The meeting again focused on reviewing and triaging issues that were tagged for consideration as part of the 3.6 release milestone. Some issues were resolved as noted in the relevant GitHub issue threads. 3 issues remained open to finalize, and following those the 3.6 release will be tagged and pushed.

The attendees briefly discussed the Polyform Project, specifically about the possibility of using “PF-“ prefix for Polyform licenses should certain of the combinations be predominant, and not allocating tags at this time that start with “PF-“ prefix for other licenses. May need to consider what’s reasonable in terms of exponential combination of options, as well how “substantially open source” or “source available” entries on the SPDX list should be.

The attendees discussed requests to have SPDX itself categorize licenses as permissive, etc., or track obligations. The Legal Team consensus is that SPDX’s role is “just the facts” and is focused on identifying and enabling conversations about licensing, to help people talk about licenses consistently. Approaches for e.g. categorizing licenses, providing recommendations or interpretation of obligations, etc. can be useful but should be handled in separate community efforts. Those community efforts would ideally make use of SPDX short-form license identifiers.

There was also a brief discussion, following from the earlier tech team call, about the possibility of adding something like PROPRIETARY / CLOSED, PUBLIC-DOMAIN, etc. as identifiers. If so, this would be as part of the spec itself, not as part of license list (since there would not be particular license texts to match on). Suggest tech / legal joint call to discuss whether this would be a helpful and appropriate use case.