License expression detection not working (for npm packages) in ProGet 2023.34?

sebastian...

Hi there,

detection of license expressions containing more than one license (e.g. (MIT OR Apache-2.0)) was introduced to ProGet last year and it seemed to work fine. However, I'm currently looking at a few npm packages with SPDX tags like (AFL-2.1 OR BSD-3-Clause), (Apache-2.0 OR MPL-1.1) or (BSD-3-Clause OR GPL-2.0) and none of them seem to be detected.

Here is a list of npm packages and their license expressions, none of which seem to get detected correctly:

Here is a screenshot for one of those packages within ProGet:

Strangely enough, for Nuget packages it seems to work fine:

Any ideas? We are currently on ProGet 2023.34. I'm pretty sure this worked in an earlier version. I mean, looking back at the other thread, I apparently tested this in ProGet 2023.1 and it worked fine. So something must have happened between 2023.1 and 2023.34.

stevedennis

Hi @sebastian ,

Thanks for all of the details, this is indeed a regression. We'll get this fixed via PG-2679 in teh upcoming maintenance release , ideally later this week (Friday).

Thanks,
Steve

sebastian...

Hi @stevedennis

We updated to 2023.35, and while OR expressions now seem to get recognized, I think the interpretation of those combinations is now incorrect. In earlier versions of ProGet, when a package had an allowed and a blocked license (combined with "OR"), the package itself was not blocked, which was OK because at least one of the licenses you could choose from was compliant. Now those packages seem to get blocked, which seems incorrect.

Let's take a look at the npm package jszip 3.10.1 for example. Its package.json entry is "license": "(MIT OR GPL-3.0-or-later)". This somehow translates to "(MIT, GPL-3.0-or-later)" on the package's Metadata page:

The individual licenses (MIT and GPL-3) are correctly identified. What's incorrect, though, is that the package is being blocked due to it using the non-compliant GPL-3.0-or-later license:

While that license is indeed configured as non-compliant (and any package solely under that license would correctly be blocked), the MIT package is configured as compliant:

Thus, that package should not be blocked from being downloaded. However, not only is the package blocked, it also shows up as as issue in our SCA reports:

What's even more weird is that on the package's general page (the non version-specific under "URL/feeds/FEEDNAME/jszip/versions") it says that the MIT license is actually the one that is non-compliant, which is definitely incorrect.

Note that this problem is not specific to jszip or those specific licenses. Another example would be the npm package node-forge, which is dual licensed under BSD-3-Clause (compliant) and GPL-2.0 (non-compliant). The corresponding license expression is (BSD-3-Clause OR GPL-2.0), but the package is blocked, its usage shows up as an issue in our reports and BSD-3-Clause is incorrectly shown as non-compliant on the package's page:

stevedennis

Hi @sebastian ,

This was fixed in ProGet 2024 via PG-2630 (FIX: Dual License Packages should show as compliant if one or more licenses are compliant). It was a bug in the implementation of policies, so it wouldn't work in ProGet 2023 either.

So this should get fixed once you upgrade :)

Thanks,
Steve

sebastian...

@stevedennis
Any chance that this will get fixed in ProGet 2023? We can't upgrade to 2024 at the moment due to the "1000 active builds" limitation.

atripp

Hi @sebastian,

I took a quick look, but its not a simple cherry-pick; this is a bug in the code that does policy analysis, and there were enough changes between ProGet 2023 and ProGet 2024 in that to make it a bit risky / time-consuming to bring over...

Thanks,
Alana