-
Notifications
You must be signed in to change notification settings - Fork 553
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
add job to check oss licenses #2259
Conversation
Signed-off-by: cpanato <[email protected]>
Signed-off-by: cpanato <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #2259 +/- ##
=======================================
Coverage 28.56% 28.56%
=======================================
Files 131 131
Lines 7855 7855
=======================================
Hits 2244 2244
Misses 5305 5305
Partials 306 306 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
I don't have any context, but can I ask a high level question - What is the purpose of copying in licenses into the repo? Is this a common practice in OSS? I would have assumed that if you're trying to verify if you can use a repo due to licenses, you'd want to go to the source of truth (each dependency repo) for the licenses, rather than trust this repo to provide them (since we could modify the licenses) |
Great question! From the projects that I've worked on (and it's not authoritative by any means, just my experience), it used to be that all the code would be vendored in, but since things changed along the way with go mods, etc. We started to vendor only in the LICENSE as well as check them to ensure that we're not using code that has licenses that are not compatible with our license. I think as far as going to source, we do grab the LICENSE at the version it's imported, so if we did modify, one could see the change, but I think it's more just for tooling purposes. Not sure this helps :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this change, but since this also is sort of a policy decision, I'd like members of the TSC to weigh in on this matter.
@mattmoor who probably remembers more details about licenses than I have already forgotten. |
I don't really see any need to check in the licenses. Can we verify they meet our policies without doing that? |
The main purpose of this is to enable including the directory generated by IANAL, but this is my understanding of why Knative/Tekton did this. |
If we care about the licenses and use libraries/code that have Licenses, I think we should track that. If we don't want to track or care about this now, we can close this PR |
to get back to this, we don't want to do the license check and then this job will be not needed, correct? |
closing this for now, if we decide to have this or similar job I can make that happen |
Summary
Fixes: #2258
we need to check what to do with some libraries that does not have licenses
those dependencies were introduced in #2008