When license field in package.json doesn't match LICENSE

[clintandrewhall]

I'm surprised npm doesn't have a check to match the license field in the package.json file to an existing LICENSE file in a repository or package, and prevent publishing if they don't match.

Perhaps it doesn't happen often, but does anyone else thing this something the npm cli could/should do?

References:

https://www.npmjs.com/package/is-localhost-ip
storybookjs/test-runner#122
tinovyatkin/is-localhost-ip#240
tinovyatkin/is-localhost-ip#241

[ljharb]

There's no programatic way to reliably validate the LICENSE file - github's own detection just uses heuristics.

Until there's court precedent that a programmatically explicit SPDX ID in package.json has less weight than a prose license file (which there's not), I think that one could successfully argue that BOTH licenses apply, until a maintainer disambiguates.

Either way, there's no way npm's going to give legal advice here (and IANAL), so you'd need to hire your own attorney to answer that question.

[MylesBorins]

It isn't a requirement that packages published to the registry have a license as such it would seem like overstepping to block publishing based on the license of a package matching the SPDX string in packge.json.

It might be worth surfacing metadata about this on the package landing page... e.g. we use the SPDX string to surface license information, we could also surface if that license data matches the included LICENSE. With that said, this is very error prone and could result in false negatives. I manage a package that is licensed with the spdx string LGPL-3.0-or-later, but a popular tool for checking licenses can't accurately assess the license file and marks my pacakge as a risk because of this.

We don't currently have any recommendation about licensing beyond including the spdx string, so I think that prior to doing anything explicit in our website we would need to consult with our legal team on what we should be recommending to folks.