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

x/pkgsite: license not recognized for apache beam #46291

Open
miracvbasaran opened this issue May 20, 2021 · 5 comments
Open

x/pkgsite: license not recognized for apache beam #46291

miracvbasaran opened this issue May 20, 2021 · 5 comments

Comments

@miracvbasaran
Copy link

@miracvbasaran miracvbasaran commented May 20, 2021

What is the URL of the page with the issue?

https://pkg.go.dev/github.com/apache/beam/sdks/go/pkg/beam

What is your user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

Screenshot

image

What did you do?

I am trying to read the godoc for package beam but the recent additions to the license file in the project makes godoc unable to recognize the license for the package. The license for the package (and the repository) is actually Apache 2.0.

What did you expect to see?

Documentation.

What did you see instead?

"Documentation not displayed due to license restrictions."

@gopherbot gopherbot added this to the Unreleased milestone May 20, 2021
@seankhliao seankhliao changed the title x/pkgsite:beam godoc license is not recognized x/pkgsite:license not recognized for apache beam May 20, 2021
@seankhliao seankhliao changed the title x/pkgsite:license not recognized for apache beam x/pkgsite: license not recognized for apache beam May 20, 2021
@jba jba self-assigned this May 20, 2021
@jba jba removed this from the Unreleased milestone May 20, 2021
@jba jba added this to the pkgsite/unplanned milestone May 20, 2021
@jba
Copy link
Contributor

@jba jba commented May 22, 2021

@lostluck, I read the email thread on this. We can't accept the Python license, because then any Go project could have only that license, which would be odd and probably not kosher. For example, the CNRI section's grant is to "use Python 1.6.1", which would not cover a pure Go module.

Can you put the Python license into a separate file that is not on our list?

@lostluck
Copy link

@lostluck lostluck commented May 22, 2021

That's very fair, thank you. I'll look into file separating it. That should be ok, of there's a way to do it not against policy. Maybe we can put it into a LICENSE.python file and the policy folks on the apache side would be ok with it.

Another thought occured to me. Does the doc generation look at non-Root level files? And if so, does it terminate it's search when it finds a License file nearer to the doc code in question? If it doesn't glob global the license files from high level directories, we might be able to separate out a file for just the go code.

All those licenses largely apply to other vendored code, but not the go code itself. Would putting a more concise license file in beam/sdks/go work?

@jba
Copy link
Contributor

@jba jba commented May 22, 2021

I think LICENSE.python is a great idea.

We AND all the licenses we detect from the package directory to the module root. That is, if package M/P has a LICENSE file at M (the module root) and at M/P, we assume both apply. We need to be conservative in our interpretation, since it's not vetted by a human. So the answer is no, you can't place a license in the go subdirectory that will override your root LICENSE.

@lostluck
Copy link

@lostluck lostluck commented May 25, 2021

If it's all licenses from the package directory to the Module Root, then would moving the Python license up towards/closer to the python code and out of the path to the root work instead? Just hedging in case the LICENSE.python proposal isn't acceptable.

@jba
Copy link
Contributor

@jba jba commented May 25, 2021

Yes, that will work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants