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

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?

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.

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.

Yes, that will work.

Assuming no news is good news.