Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update_licenses should still run when repos don't have vendor folder #315

Closed
Tracked by #134
dprotaso opened this issue Sep 18, 2023 · 16 comments · Fixed by #316
Closed
Tracked by #134

update_licenses should still run when repos don't have vendor folder #315

dprotaso opened this issue Sep 18, 2023 · 16 comments · Fixed by #316
Assignees

Comments

@dprotaso
Copy link
Member

dprotaso commented Sep 18, 2023

see discussion here: knative/pkg#2810 (comment)

Caused by #311

@dprotaso
Copy link
Member Author

/assign @cardil

@cardil
Copy link
Contributor

cardil commented Sep 19, 2023

I don't agree this is required. There is no such requirement anywhere in CNCF docs.

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

Both docs focus on license use and checking. None of them refers to a need to embedding the deps license in a specific folder, nor in a container.

@dprotaso
Copy link
Member Author

dprotaso commented Sep 19, 2023

This has been the practice of the project since it's inception. The requirements were coming from Google's OSPO office. I opened a CNCF request months back to see if we should continue it.

Also the update_licenses checks also ensures we don't pull in GPL code etc.

Whether we change this practice should be a separate discussion from vendoring dependencies.

Screenshot 2023-09-19 at 8 18 24 AM

@cardil
Copy link
Contributor

cardil commented Sep 19, 2023

@dprotaso: Also the update_licenses checks also ensures we don't pull in GPL code etc.

We still run that check, within the presubmit build test:

report_build_test Check_Licenses check_licenses || failed=3

@upodroid
Copy link
Member

We should keep the checks for forbidden licenses but drop the licenses being published to third_party folder

@cardil
Copy link
Contributor

cardil commented Sep 19, 2023

@upodroid We should keep the checks for forbidden licenses but drop the licenses being published to third_party folder

Exaclly what #311 did.

@dprotaso
Copy link
Member Author

There is no such requirement anywhere in CNCF docs.

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

We have MPL in some repos - given that the CNCF Allowlist License Policy states

It is stored unmodified in a designated third-party folder; AND

Again - I'm not saying we shouldn't change what we are doing. I'm stating let's separate this from the 'vendorless' work

@upodroid
Copy link
Member

Hmm, that is an important detail we missed

@cardil
Copy link
Contributor

cardil commented Sep 20, 2023

@dprotaso We have MPL in some repos - given that the CNCF Allowlist License Policy states

It is stored unmodified in a designated third-party folder; AND

Doesn't that section says that the whole third-party component should be kept in the third-party folder, not just the license?

@cardil
Copy link
Contributor

cardil commented Sep 20, 2023

However, looking at some of the graduated CNCF projects, it's hard to find the third-party folder like ours (from https://landscape.cncf.io/card-mode):

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)

@dprotaso
Copy link
Member Author

We keep going back and forth. My point here is let's not deviate from what we are currently doing without a discussion at the TOC level - since this impacts all subgroups. This is a separate discussion from vendorless work

So let's continue our license disclosure practice until we have consensus at that level.

Thus let's

  1. Fix the hack script to continue to call update_licenses (this issue)
  2. Create a new community issue regarding the license disclosure practice
  3. Bring it up with the TOC

@cardil
Copy link
Contributor

cardil commented Sep 21, 2023

Moving this issue to knative/hack

@evankanderson
Copy link
Member

evankanderson commented Sep 21, 2023

To provide additional context, this was original implemented to meet the second clause of the BSD 2-clause license:

  1. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

By embedding the license in the container image, people who received the OCI image (for example, by pulling from a repo which the image had been cloned to) would also receive a copy of the license, which would trivially satisfy "reproduce the above copyright notice". Since I'm not a lawyer, I'm not going to venture whether this was an overly-restrictive reading of this clause. (This also similarly trivially satisfies the MIT requirement of including a liability disclaimer notice.)

@dprotaso
Copy link
Member Author

I'm going to move my question to a public cncf foundation issue - it probably shouldn't be a service desk issue.

@dprotaso
Copy link
Member Author

cncf/foundation#642

@cardil
Copy link
Contributor

cardil commented Sep 27, 2023

@dprotaso I've opened the issue you mention: knative/community#1441

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants