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

Difference between revisions of "Legal Team/Minutes/2016-12-22"

From SPDX Wiki
Jump to: navigation, search
 
Line 1: Line 1:
 
== Attendees ==
 
== Attendees ==
* Paul Madick
+
* Paul
* Dennis Clark
+
* Dennis
* Brad Edmon
+
* Brad
* Mark B - Juniper
+
* Mark B  
 +
* Jilayne
  
 
== Agenda ==  
 
== Agenda ==  
 
1) Review licenses still "under review" on list: https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681
 
1) Review licenses still "under review" on list: https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681
 
* see notes for LPG-Bolivia-1.0 and Unicode licenses in spreadsheet (to add)
 
* see notes for LPG-Bolivia-1.0 and Unicode licenses in spreadsheet (to add)
* discussed Net-SNMP and corresponding question as to BSD-3-Clause with additional Sun clauses:
+
* Discussed Net-SNMP and corresponding question as to BSD-3-Clause with additional Sun clauses:
** this is a stack of licenses with 6 parts, that includes repetition of BSD-3-Clause, MIT_CMU, and a variation of BSD-3-Clause with additional info at the top (Sun variation). Should we add this as a license stack or rely on license expressions to identify? If the latter, then we'd need to either add BSD-3-Clause-Sun variation or use LicenseRef for that part.  
+
** This is a stack of licenses with 6 parts, that includes repetition of BSD-3-Clause, MIT_CMU, and a variation of BSD-3-Clause with additional info at the top (Sun variation). Should we add this as a license stack or rely on license expressions to identify?   
** People do reproduce this as is, project includes file-level references to full stack in a copying file for recent versions, easier to identify for very common project. This would require matching as a whole.  If added as a whole, would we want to add a note that license expressions could also be used?
+
** As to adding as full stack: People do reproduce this as is, project includes file-level references to full stack in a copying file for recent versions, easier to identify for very common project. This would require matching as a whole. But also have tried to avoid adding license "stacks" unless necessary, as can be messy and also doesn't seem to reflect file-level licensing.  If added as a whole, would we want to add a note that license expressions could also be used?
**  Does adding as a whole undercut automation and use of license expressions? does this cut against or complicate automation for license detection, use of license expression, and otherwise introduce duplication?  
+
** If the latter, then we'd need to either add BSD-3-Clause-Sun variation or use LicenseRef for that part. BSD-3-Clause-Sun only seems to appear by itself (to be able to use on its own) in old version of Net-SNMP, otherwise, appears only as part of license stack.
 
+
** see previous discussion on this at Aug 4 meeting: http://wiki.spdx.org/view/Legal_Team/Minutes/2016-08-04 and email archive: https://lists.spdx.org/pipermail/spdx-legal/2016-August/thread.html
Decision: confer with tech team on this: what is tooling perspective on adding this license stack versus not? is it helpful to add it or does that not add value from a automation/tooling perspective?? (inclination to not add as stack and rely on license expressions - see below re: Sun BSD-3-Clause notes also)"
+
--> Decided to get input from tech team on this: what is tooling perspective on adding this license stack versus not? Does adding as a whole undercut automation and use of license expressions? does this cut against or complicate automation for license detection, use of license expression, and otherwise introduce duplication? Which approach as described above is better from a tooling/automation perspective?
 +
* (hope to resolve via email by end of year and add license accordingly, but will otherwise follow-up in early Jan)
  
 
2) Timing of 2.6 release of license list:  will release in first week of January to Git repo.  Switch over to Github as master will happen end of January, so this will ensure everything is current before that happens.
 
2) Timing of 2.6 release of license list:  will release in first week of January to Git repo.  Switch over to Github as master will happen end of January, so this will ensure everything is current before that happens.

Latest revision as of 19:27, 22 December 2016

Attendees

  • Paul
  • Dennis
  • Brad
  • Mark B
  • Jilayne

Agenda

1) Review licenses still "under review" on list: https://docs.google.com/spreadsheets/d/11AKxLBoN_VXM32OmDTk2hKeYExKzsnPjAVM7rLstQ8s/edit?pli=1#gid=695212681

  • see notes for LPG-Bolivia-1.0 and Unicode licenses in spreadsheet (to add)
  • Discussed Net-SNMP and corresponding question as to BSD-3-Clause with additional Sun clauses:
    • This is a stack of licenses with 6 parts, that includes repetition of BSD-3-Clause, MIT_CMU, and a variation of BSD-3-Clause with additional info at the top (Sun variation). Should we add this as a license stack or rely on license expressions to identify?
    • As to adding as full stack: People do reproduce this as is, project includes file-level references to full stack in a copying file for recent versions, easier to identify for very common project. This would require matching as a whole. But also have tried to avoid adding license "stacks" unless necessary, as can be messy and also doesn't seem to reflect file-level licensing. If added as a whole, would we want to add a note that license expressions could also be used?
    • If the latter, then we'd need to either add BSD-3-Clause-Sun variation or use LicenseRef for that part. BSD-3-Clause-Sun only seems to appear by itself (to be able to use on its own) in old version of Net-SNMP, otherwise, appears only as part of license stack.
    • see previous discussion on this at Aug 4 meeting: http://wiki.spdx.org/view/Legal_Team/Minutes/2016-08-04 and email archive: https://lists.spdx.org/pipermail/spdx-legal/2016-August/thread.html

--> Decided to get input from tech team on this: what is tooling perspective on adding this license stack versus not? Does adding as a whole undercut automation and use of license expressions? does this cut against or complicate automation for license detection, use of license expression, and otherwise introduce duplication? Which approach as described above is better from a tooling/automation perspective?

  • (hope to resolve via email by end of year and add license accordingly, but will otherwise follow-up in early Jan)

2) Timing of 2.6 release of license list: will release in first week of January to Git repo. Switch over to Github as master will happen end of January, so this will ensure everything is current before that happens.