Repository navigation
Downgrade to npm v9.6.4 or v9.6.5 to avoid potential licensing issues #49625
Description
Activity
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
mainbranch.- 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 WatanabeI believe you have to narrow it down to prod dependencies only @UlisesGascon
Updated! Great catch @ruyadorno. Now is updated
Reacted by Matteo Collina and Ruy Adorno@ljharb @RafaelGSS is the license checker part of the OpenSSF badge?
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
Reacted by Ulises Gascóncc @isaacs can we have permission to use that dependency under the regular MIT license perhaps?
Update: Starting a fast brainstorming here and first output from the licenses included in all the sub-dependencies from the npm cli
mainbranch.I believe you have to narrow it down to
proddependencies only @UlisesGasconReacted by Ulises GascónI'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.jsonwith the following and runningnpx npcheckwill flag two modules usingBlueOak-1.0.0with 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 ...
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.
FYI rolling back to v9.6.4 doesn't fix this at path-scurry has always been blue-oak
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
Reacted by Yahor Siarheyenka and Ruy AdornoI 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
Reacted by Yahor Siarheyenka@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.
Reacted by Yahor SiarheyenkaI am afraid there is no solution to replace
globatm. 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.0We 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.
@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
jackspeakandpath-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.Reacted by Yahor Siarheyenka, Ruy Adorno and Matteo CollinaSorry 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.
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.
If Blue Oak isn't yet OSI-approved, doesn't that mean it's not yet an OSS license?
Reacted by Gürgün DayıoğluIf 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.
Reacted by Tobias Nießen and Kevin GibbonsWhile you're certainly the best kind of correct, I think that the commonly understood definition of "open source license" includes the qualifier "OSI-approved".
Reacted by Tobias NießenThis issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
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:
http://www.apache.org/licenses/LICENSE-2.0)
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