kubeflow/model-registry

Introduce dependency license monitoring

tarilabs opened this issue · 4 comments

tarilabs commented

This project onboarded as Apache-2.0, see original thread.

We have received questions about the dependencies' license compatibility, for which we referenced: https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md#approved-licenses-for-allowlist

In this repo, we have:

  • main REST Model Registry server: Go
  • MR Python client: Python
  • UI: React, Node
  • BFF: Go
  • CSI: Go

(we could have more in the future more)

To help with automating on the dependency checks,
👉 we propose to introduce FOSSA scanning in this repo, from the list of tools CNCF can support with: https://contribute.cncf.io/resources/project-services/hosted-tools/#tools

If you are a Kubeflow member reading this issue and you need to be added in the FOSSA tool:

  • general access to CNCF's FOSSA which is a prerequisite is to be requested via CNCF service desk: ask a KFSC representative to manage the service desk request for you/your KF project.
  • then, you can reach out to myself, @rimolive and @terrytangyuan to be added in the existing Fossa team "Kubeflow" in the CNCF's FOSSA, or ask a KFSC representative to manage the service desk request for you/your KF project

Suggested steps for new projects/repos:

  1. ensure the Maintainer is added to the correct Team (in our case, "Kubeflow" Team)
    Screenshot 2024-09-10 at 09 54 36

  2. the Maintainer is to create a "push only" token api key, see example.

  3. the Maintainer should first use the fossa cli with the --team flag for the desired repo, and the appropriate configurations keys from within a .fossa.yml file.
    That would spawn a new Fossa project in the CNCF Org and assign it to the Fossa Team "Kubeflow", at once.

Tip

These newly created Fossa projects would appear within the intended "Kubeflow" Fossa Team, and since we share team admin, should have the appropriate permissions to modify them, such as adding new revision of the project (i.e. new scans)
The issue may arise when a new fossa project is created outside of the team or if an attempt is made to modify an existing project (by adding it to a team, for instance). At this point, we lack CNCF Organizational role sufficient permissions, as in CNCF FOSSA Organization we have only read rights, but write rights only under the given "Kubeflow" FOSSA Team

  • When using the fossa cli, you can specify the name using either the --title flag which in Model Registry we set to the github location (https://github.com/kubeflow/model-registry), or let FOSSA attempt to automatically determine the title from the VCS.
  • To ensure consistency, is best to utilize the --project flag when used from the cli, and project: key when used from the gha. In our case we set it to the github.com/kubeflow/model-registry per fossa conventions.
  • Additional settings to be considered are project.name: key flag within the .fossa.yml file. That should allow it to be uploaded to the same project every time.
    You can also use revision.branch to the same effect if the branch can not be determined automatically.
  1. only after having used the fossa cli, setup the GHA (so it would update a revision to an existing Project already assigned to a Team)

Note

API keys are tied to the Account that created them and inherit their permissions. Should the account permissions change, the token's will as well. This means if the Maintainer from step1 leaves the Fossa team, the remaining Kubeflow project Maintainers will need to go through these steps again to ensure the GHA has the correct push-only token api key, to upload to fossa a new revision.

rareddy commented

apart from the benefits from scanning for the project which I already receive, is there any reason why I should add my name?

tarilabs commented

Follow-ed up with FOSSA helpdesk since I'm not able to add the repo to the Kubeflow team

Screenshot 2024-09-04 at 12 12 01
Screenshot 2024-09-04 at 12 12 42

image

tarilabs commented

this is now working as expected in #324 thanks from the support of David with TKT-11475.

tarilabs commented

In the fossa project CNCF/Kubeflow/Model Registry,
the "github.com/docker/docker" which for us is a transitive dependency appears to be showing multiple licenses, namely Apache-2.0 and GPL-2.0-or-later.

This can be seen by scrolling in the same page to the beginning of
vendor/github.com/spdx/tools-golang/LICENSE.code
to see:

The tools-golang source code is provided and may be used, at your option,
under either:
* Apache License, version 2.0 (Apache-2.0), OR
* GNU General Public License, version 2.0 or later (GPL-2.0-or-later).

This is actually the license for "github.com/spdx/tools-golang", which is vendored by "github.com/docker/docker" (for example, here).

The "github.com/docker/docker" is distributed under Apache-2.0 as can also be seen in this page: https://pkg.go.dev/github.com/docker/docker@v27.2.1+incompatible#:~:text=Sep%206%2C%202024-,License%3A%20Apache%2D2.0,-Details

Currently, FOSSA does not support the automatic creation of dual licenses on the backend.

Without FOSSA Org-wise permission which is our case since we're a subset, the "Kubeflow" FOSSA Team inside CNCF's FOSSA Org, the advised acton is to:

ignoring the issue with a note that the dependency is dual-licensed may be the easiest solution

Recorded as part of TKT-11490.

This appears also to be the case of what other projects under CNCF as done, for example:

Will perform the same for KF Model Registry.

Many thanks to FOSSA support helpdesk and CNCF dev relations for the continued support.