-
Notifications
You must be signed in to change notification settings - Fork 63
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
Comments
/assign @cardil |
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. |
We should keep the checks for forbidden licenses but drop the licenses being published to third_party folder |
We have MPL in some repos - given that the CNCF Allowlist License Policy states
Again - I'm not saying we shouldn't change what we are doing. I'm stating let's separate this from the 'vendorless' work |
Hmm, that is an important detail we missed |
Doesn't that section says that the whole third-party component should be kept in the third-party folder, not just the license? |
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) |
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
|
Moving this issue to knative/hack |
To provide additional context, this was original implemented to meet the second clause of the BSD 2-clause license:
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.) |
I'm going to move my question to a public cncf foundation issue - it probably shouldn't be a service desk issue. |
@dprotaso I've opened the issue you mention: knative/community#1441 |
see discussion here: knative/pkg#2810 (comment)
Caused by #311
The text was updated successfully, but these errors were encountered: