http://net-snmp.sourceforge.net/about/license.html is not a license but a 
license notice file. License expressions were initially designed to represent 
the licensing of a single file whether it be a source file or a binary library 
or program. They each represent a complete atomic integrated (derived) work. 
Packages are collections or aggregates hence very different beasts. For 
example, they could potentially hold a collect of independent works where one 
is a GPL-2.0 file and the other is a proprietary file (which is perfectly 
legitimate. Currently package level licensing is an ill-defined concept. 
Furthermore license expressions as they are defined today at a package level do 
not make sense unless the package contain a single file – e.g.,  binary (or a 
collection of binaries for which a single license express applies to all). Even 
in this case the expression really represents the express of the file.  I been 
waiting to have the package level license discussion so we could move forward 
to augment the license expression language to better accommodate packages. I 
recommended that topic for the SPDX 2017 roadmap. The Net-SNMP package presents 
another reason to have that discussion.

- Mark

Mark Gisi | Wind River | Director, Open Source & Software Assurance
Tel (510) 749-2016 | Fax (510) 749-4552


From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of J Lovejoy
Sent: Thursday, December 22, 2016 11:30 AM
To: spdx-t...@lists.spdx.org
Cc: SPDX-legal
Subject: Net-SNMP license stack v. using license expressions

Hi Tech team,

We had a request to add the Net-SNMP license, which is actually a stack of 6 
licenses: http://net-snmp.sourceforge.net/about/license.html

We’d like to get some input from the tooling and automation on this - notes 
from today’s discussion are pasted below (with links to other relevant input). 
Can you please provide input regarding the questions at the end in red?

Thanks!
Jilayne

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)

_______________________________________________
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Reply via email to