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

[mcollina]

The update to npm v9.6.6 #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