Handle OSS licenses and attribution

[guydc]

Description:
Envoy Gateway should adhere to CNCF guidelines for dependency licenses. As an Apache-2.0 project, EG may have licensing implications from using copyleft dependencies that are licensed under GPLv3.

Some projects enforce these guidelines using tools like go-licenses, e.g. cilium. Automated validation of of approved licenses should be a part of the PR approval flow.

Additionally, the CNCF guidelines for OSS attribution should be followed, by generating and maintaining the appropriate documentation.

[arkodg]

is this something that can be built into the openssf tooling ?

[guydc]

Not sure. At this time, the openssf license validation only checks that a license for the project exists.

There's this issue: ossf/scorecard#3840, but if focuses on the license in use by the project, not its dependencies. There's this issue: ossf/scorecard#2531 that deals with dependencies.

IMHO, this should be a reusable CNCF util, as it's meant to enforce CNCF-specific requirements.

[shahar-h]

Please assign me

[guydc]

@shahar-h - there are two options that we discussed in this context:

• Making permissive dependency license checks part of the OSSF project
• Trying to build a common CNCF util

[shahar-h]

@guydc FOSSA is commonly used by CNCF projects: cncf/foundation#109

[arkodg]

+1 for FOSSA, will reach out to CNCF to get a key

[shahar-h]

@arkodg @guydc
I tested FOSSA on my EG fork repo and have some questions/insights:

1. FOSSA free license supports max 5 dependency depth levels, where business/enterprise license have no limit. EG dependency depth level is 9. Can you tell which license CNCF work with?
2. In order to trigger FOSSA scan also on PRs api key must be hardcoded in the workflow, since GitHub prevents PRs from forks from accessing secrets by default. It is possible to create push only API token that only allow to update builds. See:
   FOSSA scan enabled distribution/distribution#3396 (comment)
   https://docs.fossa.com/docs/api-reference#push-only-api-token
   We have 2 options here:
   1. Trigger FOSSA scan only on push to main events, which will allow us to read the token from secret.
   2. Trigger FOSSA scan only on internal PRs, which will allow us to read the token from secret. See related thread.
   3. Trigger FOSSA scan also on PRs and expose push-only api token, which is a common practice in CNCF repos.
      WDYT?
3. I used FOSSA official GH action , which can be used in 2 modes:
   1. Non-blocking - scans dependencies, uploads report to server but doesn't wait for completion.
   2. Blocking - scans dependencies, uploads report to server and polling the server for status until it's completed.
      I guess that we want to work in blocking mode in order to fail the build on any new issue.
4. The scan found some issues, which all look false positives. I can share my analysis if needed. Because of this I think we should start with non-blocking mode, triage all issues and then switch to blocking mode.

[shahar-h]

Update: FOSSA scan was done against some default license policy which is not compliant with CNCF policy.
Since I can't change the policy in the free version I go over scan results and found 2 license violations:

• github.com/hashicorp/errwrap
• github.com/hashicorp/go-multierror

Both declare MPL-2.0 license which is not included in CNCF approved licenses list.

Both dependencies are transitive and used by helm.sh/helm/v3, which is used by egctl.
Anyway there is an open PR that removes both dependencies and targeted to 3.15.0 release.

BTW osv-scanner which is used by OpenSSF for vulnerability scanning also supports license scanning. I tested it and it found the same violations with some few false positives. The problem that it's still experimental. We can consider using it in the future.

@arkodg can please refer to my questions in the previous comment? Did you manage to get FOSSA api key?

[arkodg]

thanks for digging into this @shahar-h !
+1 on non blocking scans until we fix all

I'm still waiting to hear back from CNCF, will reach out again

[shahar-h]

Thanks, and what about the second point(api token)?

[arkodg]

Thanks, and what about the second point(api token)?

yeah read the context from the distribution PR, CNCF + FOSSA is a +1 with that approach so we can just follow it, also include them in the PR, to make sure we're doing the right thing

[RobertKielty]

@Xunzhuo logged a CNCF Service Desk request.

I invited (most) all of the maintainers to join the CNCF Organizaion on FOSSA.

FOSSA Invites are valid for 48 hours. https://docs.fossa.com/docs/inviting-users

@Xunzhuo please spread the word and ask the invitees to accept their invitations.

I need just one maintainer to accept the invite who can then add repos following these instructions:

https://docs.fossa.com/docs/quick-import

Any issues reach out to me on CNCF Slack or update the Service Request.

[arkodg]

thanks @RobertKielty, I do have access to the API key, will share it with you @shahar-h
From a quick glance, There are ways to integrate into FOSSA

1. run scans on FOSSA on every merge
2. run scans on PRs using our GHA

2 makes sense here so we can proactively catch any violations

[shahar-h]

Regarding osv-scanner option, there are a few gaps:

• There are some missing packages and versions in deps.dev metadata. Opened a few issues.
• We are waiting for helm.sh/helm/v3 v3.15.0 release in order to resolve hashicorp packages violations: use standard errors.Join instead of go-multierrors helm/helm#12818.
• github.com/grafana/tempo which is used in e2e tests declares a disallowed license. We can either replace/remove it or wait for implement filtering by packages through the config google/osv-scanner#944 that will add support for package exclusion.
• implement filtering by packages through the config google/osv-scanner#944 also adds a capability of license overriding which may be useful in case of missing packages/versions in deps.dev or dual licenses.

[arkodg]

thanks for driving this work @shahar-h !

For other following this issue wanted to highlight why Envoy Gateway is trying to adopt osv-scanner over FOSSA

• FOSSA is a SaaS tool that has its own notion of user management, for a open source project, which is a collection of loosely coupled maintainers, managing users in multiple places (apart from GH) adds maintenance burden
• reviewing issues/violations must be done in the FOSSA platform instead of within GH where user roles are already assigned to view the right apps
• the FOSSA token is tied to a email/user, Envoy Gateway does not have any bot emails, and after chatting with @phlax even Envoy Proxy is trying to move away from managing bot emails, this adds more maintenance once that user leaves the project

having said this, if we cannot achieve the goal of license scanning via osv-scanner , we may need to move to FOSSA

[shahar-h]

A more detailed context about osv-scanner gaps:
Current scan results:

• All UNKNOWN license violation are a result of missing package/version in deps.dev service. I opened an issue for each one in deps.dev repo:
  • Missing version for Go package github.com/cncf/xds/go google/deps.dev#83
  • Missing Go package github.com/docker/cli google/deps.dev#84
  • Missing version for Go package github.com/opencontainers/image-spec google/deps.dev#85
  • Support Go standard library package google/deps.dev#86
  • Missing version for Go package github.com/asaskevich/govalidator google/deps.dev#87
    We should be able to manually override the license in these cases once implement filtering by packages through the config google/osv-scanner#944 is merged.
• Regarding CC-BY-SA-4.0 license violation for github.com/docker/go-metrics and github.com/opencontainers/go-digest: both have a dual license: the code is licensed under the Apache 2.0 license and the docs under CC-BY-SA-4.0 license. See:
  https://github.com/docker/go-metrics?tab=readme-ov-file#copyright-and-license
  https://github.com/opencontainers/go-digest?tab=readme-ov-file#copyright-and-license
  osv-scanner doesn't make the difference between license of choice and multiple licenses so it fails for every disallowed license in the list. See explanation here. Anyway we should be able to choose the desired license in these cases once implement filtering by packages through the config google/osv-scanner#944 is merged.
• github.com/hashicorp/errwrap and github.com/hashicorp/go-multierror are licensed under MPL-2.0 license, which is disallowed. Both will be removed once use standard errors.Join instead of go-multierrors helm/helm#12818 is merged and helm 3.15.0 is released. We can temporarily ignore helm package once implement filtering by packages through the config google/osv-scanner#944 is merged.
• github.com/grafana/tempo is licensed under AGPL-3.0 license, which is disallowed, but since it's only used in e2e tests we can safely ignore it once implement filtering by packages through the config google/osv-scanner#944 is merged. We can also consider replacing it with some other package so we don't use it by accident in the future in released code.

[RobertKielty]

@shahar-h I note your work and comments with interest!

I will pass your feedback back to the Project Team in the CNCF.

One way of testing your work with osv-scanner is to add the same project to the team I created on FOSSA and manualy run the scan there to compare the results that osv-scanner produces.

[guydc]

This was discussed in the community meeting. For the time being, we can proceed with:

• Implement an async, non-blocking osv scan workflow action
• Create another issue to track all of the aforementioned limitations and their status. When all issues are resolved, we can turn on enforcement.

[shahar-h]

There is an additional issue: osv license scan can only be run together with vulnerability scan. Since we want to run vulnerability scan recursively(to be aligned with ossf-scorecard) but license scan only on root folder(I guess we don't care about dependencies licenses in tools and site folders) we either need an option to run license scan independently or ask support for a dedicated recursive flag for each scan. See related issue.