License Usage Overview - Non-compliant Licenses in Use

Valentijn

Hi,

I clicked most builds but just can't find it.
Recently we deleted all projects and started anew using fullbuild numbers as SBOMS's started to accumulate for our quarterly releases. (not all projects have been changed yet though)

Anyway I uploaded ProGetVicrea.zip

Thanks for having a look.

Valentijn

stevedennis

Thanks so much Valentijn!

Looks like this was a display bug, and the code on Licenses Overview was looking at UsedByPackage_Count instead of UsedByBuilds_Count. Easy fix, which will ship via PG-2774 in next maintenance release:

As an FYI, the package with GPL-2.0 is node-forge@1.3.1 in the VicreaNpmJs feed. Looking closer, that package is dual-licensed as BSD-3, so it's not really a problem.

That said, the Licenses Overview page predates Policies, and I don't think the "License Usage Issues" makes a lot of sense anymore. The old model (block/allow) was much simpler with a basic Allow/Block rule. However, Policies are quite a bit more complicated.

We're very open to ideas on what to do in its place, or if you have any suggestions on what could be improved in general in the SCA UI. It's very easy for us to "see" what you're talking about, since we have the backup now :)

Thanks,
Steve

Valentijn

@stevedennis

Should the text not say something like

There are no active builds...

stevedennis

@v-makkenze_6348 whoops, good catch - yes thank you :)

sebastian...

@stevedennis said in License Usage Overview - Non-compliant Licenses in Use:

That said, the Licenses Overview page predates Policies, and I don't think the "License Usage Issues" makes a lot of sense anymore. The old model (block/allow) was much simpler with a basic Allow/Block rule. However, Policies are quite a bit more complicated.

We're very open to ideas on what to do in its place, or if you have any suggestions on what could be improved in general in the SCA UI. It's very easy for us to "see" what you're talking about, since we have the backup now :)

If you don't mind me hijacking this thread: The Licenses Overview page already shows the number of affected packages, builds and projects per license:

Wouldn't it be nice to be able to actually get a list of those packages, builds and projects? For example, each of those numbers could be a link and clicking on it would open a popup or another page with the complete list. Basically like the "Usage & Statistics" page for packages.

We currently have our own little tool which does exactly that (reading the data directly from the ProGet database), but it would be nice to have this build-in in ProGet.

apxltd

@sebastian I like that idea!

That information is readily linked in the database, so it's just a matter of figuring out how to get ProGet to display it.

Did you guys see the "Noncompliant packages" report (i.e. /sca/compliance-report)?

This is by far the easiest pattern: a non-sortable list of the top 100/500/1000 items.

That means your "show packages with Apache-2.0 licenses" wouldn't show everything, but I can't imagine you'd want to do that anyway. I'm thinking, you'd want to see the 7 packages with Artistic-2.0 instead.

I'd also like to ditch the "License Usage Issues" infobox, or at least replace it with something useful. It made sense with the ProGet 2023 license rules, but with policies we cannot easily query why a package/build is noncompliant.

sebastian...

Hi @apxltd

first of all, sorry for the badly cropped screenshot. In this specific scenario, I'm interested in the projects using libraries that are under GPL-2.0 or PolyForm-Noncommercial-1.0.0 license (but they were too far down on the page to fit into the screenshot). So what I'm really looking for is that one project that uses a PolyForm-license and those seven projects that use GPL-2.0 licenses (some of those are internal projects, which would be OK, but I want to make sure no other projects use packages with those licenses).

The /sca/compliance-report isn't really useful for us at the moment, because I can only see a handful of entries, none of which mention one of the two licenses above. I assume that this is due to the "max. 1,000 builds" limit in the package analyzer. That's why the "License Usages Overview" is so helpful (and would be even more helpful if it had a way to quickly navigate to the affected projects/builds/packages ).

apxltd

Thanks for clarifying @sebastian

So I'm not exactly thrilled by this UI, but maybe this is fine.

What do you think?

This is a kind of "quick and dirty" page that would show up if you clicked on that GPL-2.0 license and the "# projects" number.

Here's one for the packages as well:

sebastian...

@apxltd

I thing it looks pretty good, to be honest. It's simple enough and has all the information I would be looking for.

Only minor adjustment maybe for people who have a lot of projects/build affected by a certain license would be to make the list sortable by "Project" or "Package", so it would be easier to scroll through larger lists.

davidroberts63

I would like to add my support for that UI for viewing the Active Builds Using "[license]" and Packages Using "[license]". The recommendation of allowing to sort by the package or the project name would be very helpful. I was looking for this exact view in Proget (2024.12) for the past few days as we have a similar situation.

Also, on the builds page, I'd recommend having a sort and/or filter ability for the Stage. We may want to review production stages as a priority and then the rest as a secondary effort. Filtering or at least sorting would greatly assist in focusing our efforts.

Does there happen to be a PG tracking number that we could follow to be aware when it gets released?

apxltd

@davidroberts63 check out 2024.14... added via PG-2783 :)

Also, on the builds page, I'd recommend having a sort and/or filter ability for the Stage.

Oh yes, I could see that helping... actually i'm not sure if it's even listed on the Build page. How many active builds do you have BTW?

davidroberts63

@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.