>> * 1866 of these files have no copyright or license information.
>> * 127 of these files have a pointer to the COPYING file at the top-level.
>> * 13 of these files are copyright by 'Alex Rozin'
>> * 2 of these files are copyright by 'Tali Rozon'
>> * 1 directory (disman/expression) seems to be proprietary.
>> Some number of files in net-snmp-5.7.3/apps/ are only under the CMU
>> copyright and license.
>> Some number of files in net-snmp-5.7.3/apps/snmpnetstat are under a
>> BSD-3-Clause license.
Mark B's analysis above provides yet another data point on why the concept of
a single package (top) level license is not as useful as many would like to
think. In fact, the number one value proposition of SPDX is that it provides
the best representation of a package's licensing. That is, it provides a single
place to look and understand the licensing for 100s (1000s) of files contained
within a package. It is also particularly helpful in the cases where it shows
that files are missing important license notices. The consideration that the
following link:
http://net-snmp.sourceforge.net/about/license.html
represents the licensing of the package is ill-conceived. This example also
demonstrates that SPDX is a "must have" licensing infrastructure component as
opposed to a "nice to have". This example represents more the norm rather than
the exception. This is especially true with highly successful projects that
borrow (build on) open source from other projects under different licensing.
Composite licensing is a good thing but it needs to be better managed by the
open source movement at large and SPDX is an important component of the
solution. The license expression language is particularly good at describing
licensing of individual files (both source and binary) but it is not
particularly good at describing the licensing of a package - which is (I hope)
one of the next areas to focus on in 2017.
- Mark G.
Mark Gisi | Wind River | Director, Open Source & Software Assurance
Tel (510) 749-2016 | Fax (510) 749-4552
-----Original Message-----
From: m...@juniper.net [mailto:m...@juniper.net]
Sent: Saturday, December 24, 2016 7:57 PM
To: brad.edmond...@gmail.com
Cc: Gisi, Mark; spdx-tech@lists.spdx.org; SPDX-legal
Subject: Re: Net-SNMP license stack v. using license expressions
Brad Edmondson <brad.edmond...@gmail.com> writes:
> 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?
There are 2153 files in the net-snmp-5.7.3 file.
Of these:
* 1866 of these files have no copyright or license information.
* 127 of these files have a pointer to the COPYING file at the top-level.
* 13 of these files are copyright by 'Alex Rozin'
* 2 of these files are copyright by 'Tali Rozon'
* 1 directory (disman/expression) seems to be proprietary.
Some number of files in net-snmp-5.7.3/apps/ are only under the CMU copyright
and license.
Some number of files in net-snmp-5.7.3/apps/snmpnetstat are under a
BSD-3-Clause license.
-- Mark
> 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-tech@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-le...@lists.spdx.org
> > https://lists.spdx.org/mailman/listinfo/spdx-legal
> >
> >
_______________________________________________
Spdx-tech mailing list
Spdx-tech@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-tech
