Do not copy source code for Reciprocal licenses

[chizhg]

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.

[albertomilan]

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

[dprotaso]

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]

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]

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]

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]

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

golang/go#27348

[dprotaso]

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

[dprotaso]

@wlynch do you have thoughts on this PR?

[wlynch]

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]

@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]

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]

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

[OMG54545]

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