Repository navigation
Clarify license metadata guidelines - #8179
kemitchell wants to merge 5 commits into
Conversation
ddf797e to
5da3f5a
Compare
|
The vast majority of |
|
Of the 1,000 most-depended-upon npm modules, only the following have
|
|
👍 This is so much better. @kemitchell thanks for taking the lead on cleaning up this mess :) |
|
@sindresorhus: Thanks for your work on spdx-license-list! Thanks to @shinnn, it's is now an indirect dependency of spdx.js. I'd love to make this metadata guidance part of npm@3 if at all possible. Given the growth rate of npm packages, I get the feeling it's early or never for compliance as the norm. |
5da3f5a to
e5be5f2
Compare
|
I force-pushed a small change that makes clear that license identifiers should come from the most recent SPDX license identifier list (http://spdx.org/licenses), while the syntax for license expressions is version 2.0 of the spec. |
e5be5f2 to
e4e508a
Compare
There was a problem hiding this comment.
Can you add a little to this deprecation, including a terse explanation of how to rewrite the above into SPDX syntax?
There was a problem hiding this comment.
It might be useful to make the second example an actual array with two licenses so you can show another example of using a conjunction in an SPDX expression.
There was a problem hiding this comment.
Will they still get a warning in these cases, or are your changes to normalize-package-data aware of the existence of a LICENSE file? i.e. how can we make sure that users don't get a warning when they're doing what these docs recommend?
There was a problem hiding this comment.
Great point. It didn't think about making sure warning scenarios are coextensive with guidelines noncompliance.
I take it normalize-package-data should remain a pure function of the package.json object, so hitting the file system or the API to stat a LICENSE is out.
That leaves us at least three ways to go at the problem:
- SPDX does provide for a way to reference licenses that don't have assigned identifiers,
LicenseRef-X, but they are designed as references to other RDF objects within a larger package definition, of which license IDs and expressions are just a part. npm could define a special value, likeLicenseRef-LICENSEthat means "check the LICENSE file" in the ecosystem. - Acknowledge that failure to indicate common license terms is a warning-worthy offense. But ... private modules.
- Don't issue warnings when
licenseis missing. Accept a far greater number of false negatives (should havelicense, doesn't see a warning) for fewer false positives (shouldn't havelicensefor lack of a way to specify it as an SPDX expression, but warn anyway).
There was a problem hiding this comment.
I think it may make sense to do some special filtering of the warnings reported by init-package-json in npm itself to do something commonsense, like looking for "see LICENSE file" (or some other, bikesheddable phrase) in that field and then verifying that ./LICENSE does in fact exist. I've been meaning to do some work on how those warnings are handled for a while now, because I'm not sure it's useful to print the warnings for dependencies on install.
I don't think those changes need to be part of landing this change, though. We can get to them later. It just means that npm's install warnings are going to be noisier than usual for a while.
There was a problem hiding this comment.
I am down for getting this done right the first time. LicenseRef-LICENSE is Magic Words, but it works.
Alas, even detecting whether a LICENSE file exists is messy. Sometimes LICENSE, other times LICENSE.md, LICENSE.markdown, LICENSE.BSD, &c. That's ignoring case and licenses pasted at the end of README, which has the same problem.
There was a problem hiding this comment.
Even if npm checked for LICENSE, the guidelines recommend that all packages have a LICENSE file. It won't be clear when a LICENSE file exists whether package.json should have an SPDX expression or not, since the LICENSE file could contain a standard or non-standard license.
Though GitHub and others are trying it, detection of standard licenses in plaintext is non-trivial. I may go there someday, but I doubt npm really wants to, or should.
There was a problem hiding this comment.
I also don't think that getting fancy and trying to parse things out of LICENSE is a good idea. I think we should follow the lead of fstream-npm and use a similar regexp or glob pattern to just verify that if "license" in package.json says LicenseRef-LICENSE, that glob pattern matches a file. It's heuristic, but all of this behavior must be documented anyway, so as long as those docs exist, I see only upside to making the rules very simple and deterministic.
c69986d to
fb16d7b
Compare
fb16d7b to
266771a
Compare
|
@othiym23, I have pushed a commit explaining the use of |
|
@othiym23, would it help if I sent a first-stab PR to implement the |
|
I went ahead and rebased, squashed, and landed what you had so far as 8669f7d and b01ba1a. I also landed eb18245, so npm no longer warns on missing READMEs or invalid license stanzas on transitive dependencies (it logs them at If you want to take a shot at implementing the logic behind |
This PR changes the documentation visible with
npm help 7 package.jsonto make a few clarifications about license metadata inpackage.json:"license"should be a string SPDX license expression. Thus"GNU Public License"is not good metadata, while"GPL-3.0"is fine. So is"(MIT OR GPL-2.0)"for a "multi-licensed" project.{type:..., url:...}objects and"licenses"arrays are deprecated."license"out, and make sure you include aLICENSEfile in the package.There are a couple of open issues on point, both of which would benefit by an official word: #6241 and #4473.
I have also opened PRs to make SPDX expression validation part of
npm initand metadata normalization: npm/init-package-json#42 and npm/normalize-package-data#61.There are several ways to to specify machine-readable license metadata that would seem "right". Past affirmatively requiring a valid SPDX identifier, it's a bikeshed, since so few projects are multi-licensed. Some important ones are, but they are few.
I only bring this up early because so many of the most-used npm packages are older, and haven't had their metadata updated since the
licenses: [{...}]days. Normalizing those packages would help spread the word, and give us a shot at making machine-readable licensing the norm on npm.