SPDX and Non SPDX License Support (Technical Steering Committee)

[scriptjs]

I am referencing dialog and a possible solution for the package.json's license property. Recent changes to the requirements of the package.json imposed by NPM require the use of SDPX licenses while excluding non-SPDX licenses from the manifest. This has hit a nerve with a number of developers in the references identified below.

Alternatives have been proposed (including what follows below). The proposed solutions ensure the inclusion of the license type in the metadata in a way that is agnostic while enabling SPDX validation.

At this point, if a non-SPDX license is used it must be excluded from the package.json with a reference that is of no help for developers or search tools. License discovery is an important issue for all developers that work with node and for tooling that extends beyond NPM.

Further, the form of language NPM has put forward to manage non-SPDX licenses is ambiguous – even to people that speak english as a first language. Consider the following:

"license": "SEE LICENSE IN LICENSE"

NPM does not appear interested in evolving to a solution that is agnostic to the type of license. This feels unilateral. We are presently forced to produce license strings that degrade the quality of the metadata.

The solution put in place by NPM for the license property is inadequate. It forces developers to look outside the manifest to when a license is not classified within SPDX. To be clear, several open and closed source licenses fall outside SPDX. This is not a debate about open or closed licenses or license preferences.

This issue was opened as #10479 npm/npm#10479 and closed again without an appropriate resolution.

I am requesting the Node Technical Steering Committee fully examine this issue to bring an appropriate focus and solution that is neutral and properly considered.

The last issue filed concerning the license field and SPDX follows:

---

I am opening this issue that was closed while discussion was ongoing for an appropriate solution to #8918. Discussion has been ongoing for months over this in #8918 as well as #8291, #8557, #8773, #8795 so it has touched a nerve. I urge NPM to listen and collaborate for an appropriately considered solution that will work for everyone.

The latest solution recommended is as follows that has the following benefits:

• backwards compatible
• may be validated with SPDX
• is open and inclusive
• may be validated against other possible license databases/registries in future ie. XYZ('Apple Software License')
• may use "OR" on non SPDX licenses if "license" property cannot be a list
• may emit a warning if it detects SPDX licenses that ought to be enclosed in SPDX()

Valid SPDX licenses

"license": "SPDX(MIT)"

"license":  "SPDX(ISC OR GPL-3.0)"

Non SPDX licenses

"license": "Oculus VR Inc. Software Development Kit License"

"license": "Artistic 2.0 OR StrongLoop Subscription Agreement"

"license": "WTFPL"

May Emit Warning
Backwards compatible but a SPDX License.

"license": "MIT"

My recommendation is to inform NPM users of the change of the license property and give module developers some time before driving everyone crazy with SPDX warnings as has been done when you imposed it. Perhaps blog about the change first to allow voluntary revisions until a certain date where warnings could be emitted. One way or the other, I urge you to engage users before disturbing software and build systems with noise.

I have not heard anyone come out against SPDX, only the way you have chosen to implement it that is not backwards compatible to about 5 years of data, excludes non SPDX licenses from package metadata, and creates a non standard SPDX description of "SEE LICENSE IN" that makes the language of the metadata awkward. ie.

"license": "SEE LICENSE IN LICENSE"

Metadata is a source of truth and these type of phrases are meaningless and only require more investigation into a repo or package.

[chrisdickinson]

I am requesting the Node Technical Steering Committee fully examine this issue to bring an appropriate focus and solution that is neutral and properly considered.

To reiterate some of what @othiym23 said on the original issue: the Node TSC does not control the npm CLI project. The Node project is a downstream consumer of the CLI, similar to our relationship with the V8, c-ares, and libuv projects. While we can make requests of those upstream projects, those requests are in no way binding, and the maintainers of those projects are free to ignore them.

In short, @othiym23 is the person you have to convince; I do not think it is the TSC's place to convince him on your behalf.

I'll leave this issue open for 24 hours, and if no other contributors object in that time, I'll close it.

[jasnell]

@chrisdickinson ... While you are correct about this being an upstream issue, I for one would appreciate giving the @nodejs/ctc an opportunity to review and discuss the issue before closing.

[scriptjs]

@chrisdickinson I disagree. The package.json is integral to node and this impacts upon the experience of all node developers. If would hope that you would be willing to engage on such matters when such collaboration and discussion are warranted. Further, the technical committee is comprised of members including those that produce proprietary software in addition to open sources – whose own code is impacted by these recent decisions. The current solution excludes many forms of licensing directly from the metadata.

We are all interested in appropriate solutions that work for the community. There are times when reason is not being heard. For this, neutral committees can be an appropriate forum to engage, even to recommend on an issue with reaching impact.

No one is suggesting you control NPM or can force any changes. I am suggesting that you give committee members an opportunity to make their own mind up on whether they feel this ought to be debated before prematurely ending this. Please debate the issue, form a consensus and provide a recommendation is what I am suggesting – but I urge you to act on this since it will a long term impact on search and discovery for developers and tooling.

[jasnell]

@chrisdickinson @othiym23 ... perhaps either of you would be willing to at least give the CTC an overview of the changes that were made here and the reasoning behind them? We don't necessarily need to bring it up on the next CTC meeting, it would just be good to make sure everyone is on the same page.

[jasnell]

For context:

• https://github.com/npm/npm/releases/tag/v2.12.0
• https://github.com/npm/npm/releases/tag/v2.10.0
• deps: upgrade to npm 2.11.0 #1829
• deps: upgrade to npm 2.10.1 #1763

[kemitchell]

Howdy, @jasnell. Hi again, @scriptjs.

I've been involved with all the PRs bringing license value validation code into npm and its deps. Wherever this discussion belongs or ends up, just chiming in to say I'll be available to everyone who cares about the topic.

[kemitchell]

Also for context: https://github.com/npm/npm/releases/tag/v2.10.0

cc @jasnell

[jasnell]

Hey @kemitchell ! Thanks for jumping in! I know the SPDX stuff has been in for a while, just want to make sure everyone is aware of the context before we close out the issue, just in case there are questions. I added a few links for context in #3949 (comment). The main thing I'd like to see before closing this is just a quick overview of what the changes basically were and why. As @chrisdickinson said, there's really nothing we can or should do here but it's worth having things documented since there's obviously some question about it.

[othiym23]

Here is some background:

1. @kemitchell (who now provides legal services for npm, but at the time was contributing only on his own behalf) proposed clarifying what should go into the "license" field of package.json.
2. As part of that work, @kemitchell also put together a validator for SPDX license expressions, and proposed that it be upstreamed into npm for use by npm init and in package.json validation.
3. After some feedback, he added support for explicitly marking packages as unlicensed, and also a means for referring to license texts that don't have SPDX identifiers.

I do encourage you to read through those threads – there's a lot of back and forth there, and it took us a little while to get everything right, which was kind of painful for teams, like StrongLoop's, who were doing the right thing but maybe moved a little faster than the npm team was expecting.

My motivation for accepting Kyle's changes was pretty simple: there was no meaningful validation of that field before, which made it very difficult to write automated license checkers and validators for package.json, and as someone who's had to deal with license verification and compliance issues at previous jobs, I have a strong desire to see my fellow engineers spend as little time as possible worrying about them. I believe the current functionality ably balances gentle encouragement to follow good practices without penalizing anyone too harshly for ignoring the feature (it's at worst a warning) or needing something that doesn't fall under the heading of the license vocabulary we chose (SPDX), which is supported by having the SEE LICENSE IN <file> escape hatch.

My primary reason for turning down further requests for changing this behavior is because I do believe that the current tradeoffs imposed by the field are acceptable, and I really don't want to cause more churn around what's a very small corner of npm's functionality, given that the current format has only just now established itself.

I also believe that I've done my utmost to give everyone's concerns and feedback a fair hearing, and that this is an area where, as a product manager, I need to be able to draw a line and say, this work is done for now, and the team (and community it serves) has more important issues to address.

[othiym23]

Also, for documentation of how the feature works in practice, here are the docs that @kemitchell wrote for how the field works.

[jasnell]

@othiym23 ... awesome, thank you. That's likely enough context to make sure everyone is up to speed. As you know the whole commercial license thing is important to me so I wanted to make sure that this was at least discussed here so that we'd have somewhere to point if the conversation came up again.

@chrisdickinson ... no objections to getting this closed whenever you feel it's necessary unless anyone else feels need to weigh in.

[chrisdickinson]

@jasnell Cool, I'll plan on closing this tomorrow around ~4PM PST if there are no objections from contributors.