search

knative / community

Knative governance and community material.
https://knative.dev/community
Other
247 stars 233 forks source link

Revisit the need to bundle the LICENSE files in `third_party` folder #1441

Closed cardil closed 5 months ago

cardil commented 11 months ago

Background

We run google/go-licenses tool's save command in every repo. It bundles the LICENSE files of the dependencies, or their code, depends on the license itself. This has been the practice of the project since Knative inception. The requirements were coming from Google's OSPO office.

The CNCF has those 2 pages on the licenses:

Despite that, the CNCF Allowlist License Policy mentions that non-apache deps should be held in a designated third-party folder, such practice is very uncommon among the CNCF projects.

I did find only the https://github.com/kubernetes/kubernetes actually holds some third-party components in a designated folder (not only the LICENSE files)

Question

Is the current practice really required by CNCF? Maybe we can drop it like most projects do?

Links

This follows up the discussion in https://github.com/knative/hack/issues/315 Related to https://github.com/cncf/foundation/issues/642

evankanderson commented 10 months ago

/project Steering Committee Backlog

knative-prow[bot] commented 10 months ago

@evankanderson: You must be a member of the knative/community github team to set the project and column.

In response to [this](https://github.com/knative/community/issues/1441#issuecomment-1821356136): >/project Steering Committee Backlog Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
evankanderson commented 10 months ago

See discussion in https://github.com/cncf/foundation/issues/642

dprotaso commented 8 months ago

Following up here - I'm inclined to drop this practice given we've gotten no guidance from CNCF. Clearly it's not an issue for them if we don't do this.

rhuss commented 8 months ago

I would drop our license handling, too. The sooner, the better. After the upgrade to go 1.21 that introduced "toolchain", the license checker is broken for any toolchain not bundled with the installed go installation. See https://github.com/google/go-licenses/issues/244 . And there are tons of other peculiarities which took ages to analyze. Please drop the license check.

dprotaso commented 8 months ago

After the upgrade to go 1.21 that introduced "toolchain",

Is there a reason to specify the toolchain directive over go directive?

rhuss commented 8 months ago

Is there a reason to specify the toolchain directive over go directive?

I don't think so. We haven't added toolchain manually to go.mod, but it was introduced by ./hack/update-deps.sh for some reason. We don't actively use toolchain (and nailing everything down to the patch-level is also something we should not do via this mechanism)

cardil commented 5 months ago

Okay. Can we agree that we could at least remove the need to bundle all those LICENSE files?

Personally, I would keep the check as it, from time to time, actually finds some invalid libs, like https://github.com/knative/client-pkg/issues/166

dprotaso commented 5 months ago

Okay. Can we agree that we could at least remove the need to bundle all those LICENSE files?

Yeah let's update hack to stop saving the licenses - then each repo can delete them

cardil commented 5 months ago

This PR does that knative/hack#376

dprotaso commented 5 months ago

Serving PRs are out that drop the vendored files