Thanks Mark, FWIW I believe that Mark Baushke looked at the current version of the net-SNMP package during our call today and found that its constituent parts all pointed to a single top-level license file that contained the license stack at issue. So while your point is well-taken that the stack is not a license but a license file, it may be that it's used in the wild as an actual license.
Mark Baushke, is this a fair characterization of what you saw today? Thanks, Brad -- Brad Edmondson, *Esq.* 512-673-8782 | brad.edmond...@gmail.com On Thu, Dec 22, 2016 at 3:25 PM, Gisi, Mark <mark.g...@windriver.com> wrote: > > > 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-bounces@ > 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_VXM32OmDTk2hKeYExKzsnPjAVM7rLs > tQ8s/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 > >
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
