Revisit the need to bundle the LICENSE files in third_party folder

[cardil]

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:

• https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy
• https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md

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.

• https://github.com/etcd-io/etcd
• https://github.com/istio/istio
• https://github.com/coredns/coredns
• https://github.com/envoyproxy/envoy (has the third-party folder to hold some Android C header files)
• https://github.com/argoproj/argo-cd
• https://github.com/kedacore/keda
• https://github.com/fluent/fluentd
• https://github.com/prometheus/prometheus

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 knative/hack#315
Related to cncf/foundation#642

[evankanderson]

/project Steering Committee Backlog

[knative-prow]

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

In response to this:

/project Steering Committee Backlog

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[evankanderson]

See discussion in cncf/foundation#642

[dprotaso]

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]

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 google/go-licenses#244 . And there are tons of other peculiarities which took ages to analyze. Please drop the license check.

[dprotaso]

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

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

[rhuss]

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]

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 knative/client-pkg#166

[dprotaso]

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]

This PR does that knative/hack#376

[dprotaso]

Serving PRs are out that drop the vendored files