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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal