Blue Oak license in dependency tree is not OSI approved

[JSMike]

Command

new

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

Recent changes to glob result in issues with licenses. glob now depends on jackspeak and path-scurry which are using the new Blue Oak license. The Blue Oak license is not approved by OSI. This is impacting my company's ability to pull in @angular-devkit/build-angular@16 and @angular/cli@15, along with any other company that relies on OSI standards for legal.

isaacs/path-scurry#7

Minimal Reproduction

npx @angular/cli@latest new blueoak16 --interactive=false

Mike@DESKTOP ~/dev/blueoak16 (master)
$ npm ls jackspeak
blueoak16@0.0.0 C:\Users\Mike\dev\blueoak16
└─┬ @angular-devkit/build-angular@16.1.0
  └─┬ cacache@17.1.3
    └─┬ glob@10.2.7
      └── jackspeak@2.2.1

Mike@DESKTOP ~/dev/blueoak (master)
$ npm ls path-scurry
blueoak16@0.0.0 C:\Users\Mike\dev\blueoak16
└─┬ @angular-devkit/build-angular@16.1.0
  └─┬ cacache@17.1.3
    └─┬ glob@10.2.7
      └── path-scurry@1.9.2

or:

npx @angular/cli@l15.2.4 new blueoak15 --interactive=false

Mike@DESKTOP ~/dev/blueoak15 (master)
$ npm ls jackspeak
blueoak15@0.0.0 C:\Users\Mike\dev\blueoak15
└─┬ @angular/cli@15.2.8
  └─┬ pacote@15.1.0
    └─┬ read-package-json@6.0.4
      └─┬ glob@10.2.7
        └── jackspeak@2.2.1

Mike@DESKTOP ~/dev/blueoak15 (master)
$ npm ls path-scurry
blueoak15@0.0.0 C:\Users\Mike\dev\blueoak15
└─┬ @angular/cli@15.2.8
  └─┬ pacote@15.1.0
    └─┬ read-package-json@6.0.4
      └─┬ glob@10.2.7
        └── path-scurry@1.9.2

Exception or Error

No response

Your Environment

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 16.1.0
Node: 18.16.0
Package Manager: npm 9.5.1
OS: win32 x64

Angular: 16.1.1
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1601.0
@angular-devkit/build-angular   16.1.0
@angular-devkit/core            16.1.0
@angular-devkit/schematics      16.1.0
@angular/cli                    16.1.0
@schematics/angular             16.1.0
rxjs                            7.8.1
typescript                      5.1.3

Anything else relevant?

May also apply to Angular 14.

Unable to pull in any bug fixes or enhancements due to automated OSI enforcement at my company.

[JSMike]

Reviewed this issue with @jelbourn while at ng-conf.

[JSMike]

Pinning dependencies to version that use glob up to ^8.1.0 it would resolve the issue.

For Angular 16:
cacache@17.0.4 (17.0.5 is where it breaks)

For Angular 15:
pacote@14.0.0

[JSMike]

FYI, my organization assumed the risk (on a case by case basis) for the Blue Oak License. This may still impact other organizations that are struggling with accepting the license.

[clydin]

One of the reasons that cacache and pacote were originally chosen for use within the Angular CLI was that they are used and managed by the npm command/package itself. As a result, the packages are extensively used throughout the Node.js ecosystem; especially considering Node.js ships npm as part of its install.

As to the direct usage of these packages by the Angular CLI, the upcoming v16.2 will no longer use cacache. The package was only being used in one area in a limited capacity and the feature set of the package was not needed for the use case.
However, pacote is currently an integral part of the ng update command. But, we are planning a refactoring of the overall update experience in the future, and we can consider the usage and/or need of the package during that process.

[dgp1130]

@clydin already said a lot of this, but ultimately there's not a whole lot Angular can do about this. glob is pretty broadly used in the NPM ecosystem and even vendored in NPM itself. Trying to do anything in the web space without inadvertently depending on this would be quite difficult.

Angular has always valued being a part of the open source ecosystem and we do our best to use tools with open licenses, however our options here are fairly limited. When a heavily viral transitive dependency changes it's license, projects either need to solve the legal problem of working with that license or the technical problem of moving the ecosystem away from it. Evolving ecosystems is among the most difficult technical problems given the number of actors and motivations at play. Angular is only one part of this ecosystem, so while we can do our best to push for an open web, we only have so much impact in this space. Change takes time, and halting all upgrades of affected dependency packages in order to avoid this license is likely to cause more security and maintainability problems than it will solve.

Given the existing prevalence of path-scurry in the ecosystem due to glob as well the maintainer's publicly stated intention to continue using Blue Oak for future projects, avoiding this in Angular seems impractical and likely would not actually help organizations trying to avoid the license given NPM's usage.

We will continue to be judicious about our dependencies and their licenses to the best of our ability. We have rejected taking on dependencies in the past due to license restrictions and even have internal tooling to ensure we remain compliant. Angular will do what it can to avoid increasing its dependency on non-standard licenses like this as well as reduce our current dependencies where possible, and this will be a iterative and ongoing process rather than a simple fix we can land. For now, the best solution for most organizations is to go through the legal process of evaluating and complying with the license itself.

If this is an unsatisfying answer, then I would suggest asking organizations like OSI to evaluate and vet Blue Oak or requesting that more foundational parts of the web toolchain like NPM and glob move away from non-OSI dependencies until those compliance issues are resolved.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}