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

Do not copy source code for Reciprocal licenses #28

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

chizhg
Copy link
Member

@chizhg chizhg commented Jun 5, 2020

According to the description:

// Reciprocal licenses allow usage of software made available under such
// licenses freely in *unmodified* form. If the third-party source code is
// modified in any way these modifications to the original third-party
// source code must be made available.

For software that uses Reciprocal licenses, we don't need to copy the source directory as long as the code is unmodified. As normally users use third-party tools to vendor the dependencies, it seems to be overly cautious to always copy source code for Reciprocal licenses.

@googlebot googlebot added the cla: yes Contributor license agreement signed (https://cla.developers.google.com) label Jun 5, 2020
@chizhg chizhg changed the title Do not copy code for Reciprocal licenses Do not copy source code for Reciprocal licenses Jun 5, 2020
@albertomilan
Copy link

While I agree with that, how are we enforcing the copy of the licensed code if there's any change in it?

@dprotaso
Copy link
Contributor

dprotaso commented Jun 8, 2020

how are we enforcing the copy of the licensed code if there's any change in it?

can't we use the go.sum file to ensure there aren't any local changes in the vendor folder?

@albertomilan
Copy link

how are we enforcing the copy of the licensed code if there's any change in it?

can't we use the go.sum file to ensure there aren't any local changes in the vendor folder?

We could follow that approach, but we should also confirm the dependencies that have changed and only copy the code for those ones which have a reciprocal license. That's the optimal behavior, so I'm wondering what's the middle point we might be agreeing here.

@dprotaso
Copy link
Contributor

We could follow that approach, but we should also confirm the dependencies that have changed and only copy the code for those ones which have a reciprocal license. That's the optimal behavior, so I'm wondering what's the middle point we might be agreeing here.

what you mentioned (in bold) makes sense to me and is a good middle ground

@rhuss
Copy link

rhuss commented Jul 8, 2020

Is there any change in the vendor/ code anyway? If so, how it is guaranteed that it not gets lost when doing an update? For such a case one would need to record the change somewhere else anyway and in this case, one could also add the source code the third_party directory, too.

If this is not a good default, maybe it would make sense to at least make it configurable with a dedicated command-line option (like the confidence_threshold) as each project knows best whether it ever has modified a vendor dependency.

@dprotaso
Copy link
Contributor

dprotaso commented Jan 7, 2021

It looks like long term we'll be able to ensure the vendor directory is not modified

golang/go#27348

@dprotaso
Copy link
Contributor

You can probably quickly hash the modules in the vendor folder and compare them with hash in go.sum no?

@dprotaso
Copy link
Contributor

@wlynch do you have thoughts on this PR?

@wlynch
Copy link
Contributor

wlynch commented Jun 11, 2021

Did some research today - this would need more work.

We can't guarantee that all users are vendoring their dependencies. If for whatever reason the upstream source is unavailable, deleted, or modified, you could get into a state where the source used in a binary would no longer be available and would not meet license obligations (for licenses like MPL 2.0 the obligation is on the binary distributor).

We would need to keep this behavior for non-vendored dependencies.
For vendored dependencies, relying on vendor/ + verification seems reasonable.

@dprotaso
Copy link
Contributor

@chizhg @wlynch maybe then this feature goes behind a flag?

ie. if we are already vendoring the code via go mod vendor we can pass a flag to go-licenses to opt-out copying the code when saving

@wlynch
Copy link
Contributor

wlynch commented Jun 18, 2021

An opt-out flag SGTM, so long as we include a warning about the consequences of doing so.

I haven't poked around the x/mod code recently, but I'm curious if we can easily detect if the module has been vendored at all (even if we can't verify the go.sum easily yet). 🤔

@dprotaso
Copy link
Contributor

@Bobgy any change you could include this in your v2 work?

@OMG54545
Copy link

OMG54545 commented Nov 9, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Contributor license agreement signed (https://cla.developers.google.com)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants