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:

1. the license under which the vendored code is being made available.
2. the license under which the module is being made available.

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.

the nested package is made available under the terms of both the module license and its own license

@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:
https://pkg.go.dev/k8s.io/kubernetes/third_party/forked/gonum/graph?tab=licenses

This is a report about the package imported as k8s.io/kubernetes/third_party/forked/gonum/graph.
The site finds two relevant copyright notices.
First, k8s.io/kubernetes@v1.17.2/third_party/forked/gonum/graph/LICENSE
is reported as a BSD license.
Second, k8s.io/kubernetes@v1.17.2/LICENSE is reported as an Apache license.

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.

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

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?

You are displaying host license on the vendored code package, ... and not displaying vendored code licenses on the host module.

[That's fine, because] the nested package is made available under the terms of both the module license and its own license.

Given that the vendored license wasn't evident, I interpreted "both" to mean "either".

I believe your confusion is my fault: I neglected to mention that pkg.go.dev's behavior changed since Dan made his original comment. We now show both licenses on the vendored package:

.

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 code text that is not Apache licensed, and is being distributed. Any licenses that are detected in the module should also be noted on the module's license list. And any unacceptable licenses should make the entire module unacceptable (hence prior to Gonum's license being special-cased, k8s should not have had its information displayed). This is the problem that go.dev faces with attempting to do lawyering a machinā.

The host module contains code that is not Apache licensed, and is being distributed.

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?

Any licenses that are detected in the module should also be noted on the module's license list.

the host [module] should show both [host & vendored licenses] as well, perhaps reading "portions licensed under [list]"

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:

1. Navigate to https://pkg.go.dev/k8s.io/kubernetes/ in the "Subdirectories" tab and view the license, you will see only "Apache-2.0".

2. 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 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

This is text derived from this code

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
what you are asking us to change at this point, but I will try to reply.
You refer to "1" and "2", which I think means your text from 4 days ago:

1. the license under which the vendored code is being made available.
2. the license under which the module is being made available.

In the concrete case of the Kubernetes module that has a forked* copy of gonum,
(1) is the gonum BSD license, and (2) is the Kubernetes Apache license.
For the forked gonum, we now show both licenses.
For the overall Kubernetes module, we show only the Apache license.

It sounds like you think we should also show the gonum license.
We disagree about whether that's useful in general.
It might be nice to be complete, but it would also be very noisy:
most imports of Kubernetes don't reach gonum, so that license is not relevant.

It also sounds like you think we are legally required to show the gonum license
when displaying the overall Kubernetes module information.
That's definitely not true: the overall Kubernetes page is not reproducing
any significant part of gonum. The single sentence on the subdirectory list
is a simple, short quotation no different than snippets on a web search result page.
Its use does not introduce a license notice requirement.

* 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.

In the concrete case of the Kubernetes module that has a forked* copy of gonum,
(1) is the gonum BSD license, and (2) is the Kubernetes Apache license.

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.

For the forked gonum, we now show both licenses.

I am satisfied with this given the changes that exist in the k8s fork.

For the overall Kubernetes module, we show only the Apache license.

This is where I have an issue.

It sounds like you think we should also show the gonum license.
We disagree about whether that's useful in general.
It might be nice to be complete, but it would also be very noisy:
most imports of Kubernetes don't reach gonum, so that license is not relevant.

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.

It also sounds like you think we are legally required to show the gonum license
when displaying the overall Kubernetes module information.
That's definitely not true: the overall Kubernetes page is not reproducing
any significant part of gonum. The single sentence on the subdirectory list
is a simple, short quotation no different than snippets on a web search result page.
Its use does not introduce a license notice requirement.

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.