-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
go.dev: display of licenses for included packages #36953
Comments
According to our legal advisors, we're doing it right: the nested package is made available under the terms of both the module license and its own license. Having said that, I'm afraid there's nothing more we can say. This is fundamentally a legal question. |
There are two issues here:
AFAICS you are describing 1. I differ in opinion in this. But further it does not address 2; if the vendored code is being made available as part of the module, and the terms of the license include the requirement for inclusion of the license (as BSD licenses do), then the license should refer to the entirety of the module. |
@jba, forgive me if I've misunderstood, but a module author has no right to publish another author's work under an alternative license (unless that is explicitly permitted by the work's original license). Nor do module authors intend to claim such a right. If your legal advisors don't agree, and you cannot seek a second opinion, the only recourse is to omit from pkg.go.dev any module which contains packages published under any license other than that applied to the module. |
To be clear, I gather from the context at the original comment that this issue is about the fact that two licenses are shown here: This is a report about the package imported as k8s.io/kubernetes/third_party/forked/gonum/graph. The second license is not necessarily irrelevant. What if the "forked" copy has modifications made by the Kubernetes project? The modifications may well be covered by the overall Kubernetes Apache license. Showing both is almost certainly the right answer, and certainly preferable to guessing to show only one. There are modifications in this case (import paths if nothing else). By just about any definition, these are the relevant LICENSE files. It is up to users to decide what to do about them.
It is certainly permissible for an author to incorporate BSD-licensed software into an Apache-licensed overall whole, as happened here. There may well be Apache-licensed modifications made to the original BSD-licensed software. Showing both relevant LICENSEs is the right thing to do. Give users clear information and let them investigate further. |
@rsc, I gathered from the following statements that only one license (from the "host") will be evident for the entire module. You reply that "showing both relevant LICENSEs is the right thing." Could you clarify?
Given that the vendored license wasn't evident, I interpreted "both" to mean "either". |
OK, but the host should show both as well, perhaps reading "portions licensed under [list]" |
@rsc I am OK with this in the context of 1. (though for vendored code it may not be true that there have been alterations, however where the license allows overarching relicensing while retaining the original license - as the BSD license do - it fine to do that). However, point 2. is missed. The host module contains |
We do not distribute code. We display README files and documentation. These are arguably derivative works, so we do not display a module-level README if the module licenses don't permit it, and we don't display documentation of a package if its licenses don't permit it. However, if the module's license allows redistribution, we can show its README, regardless of how the module's packages are licensed. You might be confusing pkg.go.dev with the module proxy. That does distribute code, and is subject to different rules. |
The sophistry here is getting tiresome, but if we need to do this, here we go. Navigate to https://pkg.go.dev/k8s.io/kubernetes/ in the "Subdirectories" tab and view the license, you will see only "Apache-2.0". Find in the page, "third_party/forked/gonum/graph/simple", you will see "Package simple provides a suite of simple graph implementations satisfying the gonum/graph interfaces." This is text derived from this code. I don't honestly understand the level of push back here. |
@jba, how are these not no-brainer feature requests?
My assumption is that the point of displaying licenses isn't simply to comply with them in order to render package docs, but to let users browsing modules immediately see the license type(s). |
There are two separate issues here, a substantive one—are we observing the licenses—and a user-interface one—should we show package licenses on the module page. When Dan wrote "the host module contains code that is not Apache licensed, and is being distributed," he was saying we violated the first, and in my sophistry-free answer I explained why that wasn't true. The UI question is a reasonable one, which we'll take as a feature request. I'm sorry if we gave the impression that we were ignoring it, but in our minds it's a cosmetic feature and not a substantive legal issue. |
You have again ignored the second issue as detailed in this comment. |
I'm not sure what issue you're referring to. Aside from complaints, that comment offers two facts:
I agree that both are true, but you present no argument linking them to anything, so I don't know how to interpret them. Both seem to show our site functioning correctly. The first shows, before the list of subdirectories, a header that we show for every module page, in part listing the licenses that apply to the module. The second illustrates that when all the licenses that apply to a package allow redistribution, we display documentation for the package. If you feel we are violating the terms of a license, can you state plainly what exactly we're doing wrong, and provide a link to an example? If you are asking us to display (rather than merely honor) certain licenses, then as I just wrote, that's a reasonable feature request that we'll take under discussion. If you still think I'm ignoring something, can you say plainly what that thing is? |
I think I see a point of confusion. When you wrote
you were trying to argue that we do distribute code, despite my claim that we didn't. Well, again, I'm not a lawyer, so maybe what we do by displaying documentation is legally distributing code, or maybe it isn't. But the relevant points are that we display a package's documentation if and only if all licenses that apply to it permit us to do so, and we display a module's README if and only if all the licenses that apply to it permit us to do so. |
I think I have made this as clear as I can. |
@kortschak and @networkimprov, your tone is uncalled for ("The sophistry here is getting tiresome", "how are these not no-brainer feature requests"). Please remember that we are all working toward the same goal of making this site work well. If we can't communicate constructively, we can't communicate. |
@kortschak, I've reread this thread twice now and I am not sure I understand
In the concrete case of the Kubernetes module that has a forked* copy of gonum, It sounds like you think we should also show the gonum license. It also sounds like you think we are legally required to show the gonum license * Note that "vendored" is not accurate or relevant, since modules do not have vendored code in them at all. The only time this kind of nesting is going to come up is in forked copies, imported under different module paths from the original. |
No, 1. is the set of license required for displaying the gonum fork (see note below), and 2. is the set of licenses that is required to display the module's documentation as a whole.
I am satisfied with this given the changes that exist in the k8s fork.
This is where I have an issue.
I don't agree that the level of import reach is relevant. Trepidatiously reaching into a hypothetical, if the forked (I was using vendored obviously more loosely than you take it) code were GPL, then it would be required. I also don't agree that it would be very noisy if done carefully.
The issue that I have here is that there are apparently two bars that are being measure against. This may be purely due to implementation details and so maybe I should give this the benefit of the doubt, but I will note that previously I was told that go.dev was doing the right thing by allowing the unclassified licenses to be trumped by a host license, rather than not displaying the package at all. This is now fixed for the package that's being discussed here, but only by virtue of having the license recognition fixed for Gonum. I agree that in a sane world a quotation would be fair use (and that this is correct). However, go.dev does no work to do similar presentation for packages that do not have acceptable licenses (In those cases show quotes of the signature could be rendered) suggesting that fair use quoting is not a reason here. A social issue is how people understand the intent of presenting licenses on the page. I believe fairly strongly that users will take them as notes for advice (notwithstanding the note that it is not). The absence of a note on the module means that people may be misinformed. At this point, I don't think the discussion is moving forward though, so I'm giving up. Maybe this should just be relegated to feature request. |
I'm sorry we weren't able to reach agreement about how the site should behave when reporting the overall Kubernetes license. It sounds like we can close this issue. |
On behalf of @kortschak, from #36758 (comment):
The text was updated successfully, but these errors were encountered: