Downgrade to npm v9.6.4 or v9.6.5 to avoid potential licensing issues

[mcollina]

The update to npm v9.6.6 https://github.com/nodejs/node/pull/47862 introduced a new license BlueOak-1.0.0 that's not approved by the OpenJS Foundation IP policy https://openjsf.org/wp-content/uploads/sites/84/2019/10/OpenJS-Foundation-IP-Policy-2019-10-22.pdf.

The approved licenses are:

• The Apache License, Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0)
• The MIT License (available at https://opensource.org/licenses/MIT),
• The 2-Clause BSD License (https://opensource.org/licenses/BSD-2-Clause), or
• The 3-Clause BSD License (available at https://opensource.org/licenses/BSD-3-Clause).

This mostly matches the typical policy in companies.

I already asked the OpenJS Foundation Board for license approval and notified the npm team (@MylesBorins).

Out of prudence, I think it would be better to revert that PR in Node v18 because it's the only LTS release currently supported, and quite a few of our enterprise users would have trouble using such a license, making it hard for them to use Node.js.

I would also recommend we implement a license checker tool to avoid future issues.

cc @nodejs/releasers @nodejs/tsc

[UlisesGascon]

I would also recommend we implement a license checker tool to avoid future issues.

I am happy to help with this 👍

Update: Starting a fast brainstorming here and first output from the licenses included in all the sub-dependencies from the npm cli main branch.

• ISC
• Apache 2.0
• Apache-2.0
• Artistic-2.0
• BSD-2-Clause
• BSD-3-Clause
• BlueOak-1.0.0
• CC-BY-3.0
• CC0-1.0
• ISC
• MIT

The ones highlighted does not seems OSI Approved Licenses 🤔

Here are the relevant packages:

├─ npm@10.1.0
│  ├─ licenses: Artistic-2.0
│  ├─ repository: https://github.com/npm/cli
│  ├─ publisher: GitHub Inc.
├─ jackspeak@2.2.1
│  ├─ licenses: BlueOak-1.0.0
│  ├─ repository: https://github.com/isaacs/jackspeak
│  ├─ publisher: Isaac Z. Schlueter
├─ path-scurry@1.10.1
│  ├─ licenses: BlueOak-1.0.0
│  ├─ repository: https://github.com/isaacs/path-scurry
│  ├─ publisher: Isaac Z. Schlueter
├─ spdx-exceptions@2.3.0
│  ├─ licenses: CC-BY-3.0
│  ├─ repository: https://github.com/kemitchell/spdx-exceptions.json
│  ├─ publisher: The Linux Foundation
├─ spdx-license-ids@3.0.13
│  ├─ licenses: CC0-1.0
│  ├─ repository: https://github.com/jslicense/spdx-license-ids
│  ├─ publisher: Shinnosuke Watanabe

I believe you have to narrow it down to prod dependencies only @UlisesGascon

Updated! Great catch @ruyadorno. Now is updated

[mcollina]

@ljharb @RafaelGSS is the license checker part of the OpenSSF badge?

[marco-ippolito]

probably worth have a check if license changed in the deps update workflow or license builder? Although its not the case of npm which is an exception

[benjamingr]

cc @isaacs can we have permission to use that dependency under the regular MIT license perhaps?

[ruyadorno]

Update: Starting a fast brainstorming here and first output from the licenses included in all the sub-dependencies from the npm cli main branch.

I believe you have to narrow it down to prod dependencies only @UlisesGascon

[ljharb]

@mcollina its not; but i can trivially create a github action for it with licensee, and i can suggest OpenSSF add the requirement.

[richardlau]

I'm sure there are several packages that do license finding/checking. For example, my team in Red Hat have https://github.com/nodeshift/npcheck which we use for our own modules. Creating a npcheck.json with the following and running npx npcheck will flag two modules using BlueOak-1.0.0 with npm@10.1.0:

{
  "modules": [
    {
      "name": "npm",
      "npmLink": "https://www.npmjs.com/package/npm"
    }
  ],
  "licenses": {
    "allow": [
      "Apache 2.0",
      "Apache-2.0",
      "Artistic-2.0",
      "BSD-2-Clause",
      "BSD-3-Clause",
      "CC-BY-3.0",
      "CC0-1.0",
      "ISC",
      "MIT"
    ],
    "rules": {}
  }
}

NPCheck Report
(1): The module "npm" depends on the "jackspeak@2.2.1" package which is under the non-acceptable license "BlueOak-1.0.0". - ERROR
(2): The module "npm" depends on the "path-scurry@1.10.1" package which is under the non-acceptable license "BlueOak-1.0.0". - ERROR
...

[bricss]

I cannot see any reasons why BlueOak-1.0.0 should not be allowed in FOSS, bcos it very much, such state-of-the-art permissive license. And unless legal team aka practical law object to it, I barely can see any issue here.

[MylesBorins]

FYI rolling back to v9.6.4 doesn't fix this at path-scurry has always been blue-oak

https://github.com/npm/cli/blob/b8006ad61f06495c9ab7e574b513ff04642732c6/node_modules/path-scurry/LICENSE.md

We would have to go back to v9.6.2 which has issues re: vulnerabilities

5 vulnerabilities (4 moderate, 1 high)

I would really like us to move forward with including npm as is. This license issue has been in Node.js 18 since v18.15.0 (released in March) and in Node.js 20 since v20.0.0. It is already impacting both lines and we have had no external complaints yet. This is not to say that we should not figure out a solution, but that I don't think we should block landing npm on this.

Let's figure out if Blue Oak is considered acceptable by OpenJS as discussed in this issue and collaborate on a solution for glob, which is a widely used module in the ecosystem

[tobie]

I cannot see any reasons why BlueOak-1.0.0 should not be allowed in FOSS, bcos it very much, such state-of-the-art permissive license. And unless legal team aka practical law object to it, I barely can see any issue here.

Getting it approved by OSI (which has a thorough review process that includes legal experts) would really help. The process is here: https://opensource.org/licenses/review-process/

Also see related discussion in the mailing list here: https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-July/020901.html

[MylesBorins]

@tobie that discussion is over 4 years old. Ultimately I think the solution we may have to explore here is finding an alternative to glob in npm or forking glob, something that would be a fairly significant under taking.

We need a solution to this today that can work moving forward, pushing a license through to acceptance within the OSI is not a short term solution that can work.

[bricss]

I am afraid there is no solution to replace glob atm. The only solution forking under legal basic will work here. Unless author will change license or FOSS will approve https://blueoakcouncil.org/license/1.0.0

[tobie]

We need a solution to this today that can work moving forward, pushing a license through to acceptance within the OSI is not a short term solution that can work.

The approval process at OSI is fairly short (a few months). It has not been started. That thread is just a discussion about the license. No approval request was ever made as far as I can see.

[MylesBorins]

@bricss glob itself is not Blue Oak, only the two dependencies. So a solution could be (preferably temporarily) to fork glob and replace the two dependencies licensed as blue oak jackspeak and path-scurry. But I'd like to hear from someone over at OpenJS about this before we take on this task. In the mean time I don't think the Node.js project should be blocking npm udpates due to the fact that we have been distributing npm with these dependencies for roughly 6 months already.

[tobie]

Sorry for creating a bunch of confusion earlier. The IP Policy is quite clear about what the process is in a situation like this one:

If an alternative inbound or outbound license is required for compliance with the license for an Upstream Project or is otherwise required to achieve the OpenJS Foundation’s, or an individual Project’s, objectives, the Board may approve the use of an alternative license for inbound or outbound contributions on an exception basis. Please email info@openjsf.org to obtain exception approval.

The Board is sovereign to make those decisions and communicate them privately to the project and the CPC really doesn't need to be involved. Hopefully, you'll hear from the board shortly via @mcollina.

Separately, if folks believe that the lack of OSI certification of the BlueOak license is going to cause issues with users, I detailed the process to follow to get the license approved here. Feel free to reach out if you have questions with the process.

[isaacs]

@benjamingr

cc @isaacs can we have permission to use that dependency under the regular MIT license perhaps?

No.

I am willing to sell proprietary licenses for a reasonable rate to any organizations that are interested, if my choice of oss license is a blocker. But it would not be MIT, because such a license would be granted to everyone receiving it, by design.

Blue Oak gives you all the permissions you need to use, extend, and distribute the code, and has several protections and features that I appreciate. If I am going to manage admin and custom licenses, that is work, not play. I am happy to do it, but not for free.

I do intend to make glob Blue Oak as well, along with the rest of my projects. I haven't gotten around to doing a careful analysis of the codebase and history to ensure I wouldn't be violating any past contributors' rights by doing so, and I like to err on the side of being overly cautious with that sort of thing.

[mcollina]

(@isaacs I didn't tag you in this issue specifically because you made your position pretty clear in the past, so it was moot. I'm mostly concerned about the the policy of the Foundation and the expectations of our downstream consumers).

[ljharb]

If Blue Oak isn't yet OSI-approved, doesn't that mean it's not yet an OSS license?

[isaacs]

If Blue Oak isn't yet OSI-approved, doesn't that mean it's not yet an OSS license?

That is an arbitrary and contradictory position. A license doesn't become "open source" when the OSI approves it. The OSI approves it when it recognizes that it meets the criteria of being open source. If the license is not OSS before being recognized as such, then the recognition by the OSI would be in error.

[ljharb]

While you're certainly the best kind of correct, I think that the commonly understood definition of "open source license" includes the qualifier "OSI-approved".