Do not copy source code for Reciprocal licenses - #28

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

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?

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.

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

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.

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

golang/go#27348

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

@wlynch do you have thoughts on this PR?

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.

@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

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). 🤔

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

https://sites.google.com/site/classroom6x/bitligdj