On Fri, Nov 24, 2017 at 09:33:23PM +0000, Wheeler, David A wrote:
> Many package managers use SPDX license expressions
> to indicate the package license.  E.g., NPM does:
>   https://docs.npmjs.com/files/package.json
> by using the "license:" field - which is *NOT* a SPDX license file.
> According to <http://modulecounts.com/>, *just* the NPM ecosystem
> has 550,951 modules as of Nov 24, with 535 new packages a day on
> average.  I don't know what percentage of modules have a "license:"
> entry (is someone willing to find out?) - but for discussion, I'll
> guess it's at *least* 10%..  That would mean that there are 55,095
> NPM packages that use SDPX license expressions.

But how many of those authors would use a partial-conclusion syntax if
it existed?

I expect most npm package authors are also core developers for the
packaged software and know the package license.  They won't need to be
able to express a partial conclusion.

Distibution-specific package managers, on the other hand, seem more
likely to be third parties who are not directly related to the
development team.  They are more likely to need to express partial
conclusions.  Project developers who inherit an ambiguously-licensed
package from some previous authors would be in the same boat.  In
those cases, ideally they'd track down the copyright holders and get
to the bottom of the licensing.  In the absence of that, they'd want
some way to express their partial conclusions.

I'm fine with the SPDX deciding that structured partial conclusions
are out of scope, and leaving it to packaging systems, etc. to define
their own (e.g. an array of SPDX license expressions with confidence
scores).  Folks who extract license claims from those packages would
have to write per-packaging-system tooling to convert the partial
conclusion into their own format, but that's ok.  And if it turns out
to be a problem, anyone can try to talk folks into whatever
partial-conclusion model they prefer.

I'm also fine with the SPDX defining it's own partial-conclusion model
and syntax, and trying to talk folks into using it where appropriate.
But I don't think the SPDX needs to take that up if it doesn't want
to.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to