feat: Add license Apache-2.0

[tottoto]

Adds license Apache-2.0 to the crates which contains the resources licensed under the Apache-2.0.

[LucioFranco]

I did some research, since we don't actually include any code that is apache 2.0 but we import it via cargo the separatation is already handled there and we don't need to add additional license text as far as I understand.

[tottoto]

@LucioFranco

It does not contain the source codes itself, but it contains "Object" at generated directories in the following sense:

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

https://www.apache.org/licenses/LICENSE-2.0.html

[nathanielford]

Hey there @tottoto! I'm Nathaniel, a Google software engineer on our gRPC-Rust team. As we transition tonic to the official gRPC-Rust implementation, we are going to be bringing the license into proper compliance.

To that end, we reached out to CNCF legal for some guidance here. Relevant to this PR:

"You can think of the license for the Cargo.toml file as being analogous to the declared license for an overall project. For instance, with Kubernetes, the LICENSE file only includes Apache-2.0 text, even though there are a large number of third party dependencies under other licenses in the vendor/ directory as well as modified third party code in the third_party/ directory. Kubernetes's repositories declare "Apache-2.0" as the project's license, not "Apache-2.0 and MIT and BSD-3-Clause and...[long string of dependency licenses]"

Analogously here, given that tonic is MIT-only, the Cargo.toml files could declare MIT as the license. The licenses of dependencies still need to be complied with, though. So given that there's an Apache-2.0 licensed dependency, the Apache-2.0 license text should also appear somewhere in the repo itself, and the notices for the Apache-2.0 licensed dependencies should make clear that the Apache-2.0 license applies."

So it looks like, in line with your thinking, we need to include the Apache licenses in any crates with Apache licensed code in it, though the crates/projects themselves (i.e. toml files) may only have a single license. That said, we are likely to dual-license multiple crates as we sort out the structure, in particular where they make significant usage of things like the gRPC protos under Apache 2.0.

I want to honor your contribution here - this PR has been open a while. Do you still have interest in getting this modified/submitted? I'm happy to work with you on bringing it in line with our current direction, or if you would rather I can take over the task, close this out and cut a new PR to address this concern. Let me know what you think!

[tottoto]

Thanks for looking into this and for reaching out to CNCF legal. Based on that guidance, if the repository includes the required Apache-2.0 license text and NOTICE information where applicable, I don't have concerns about satisfying the legal obligations.

My remaining concern is how license information is communicated to users. I don't think the Kubernetes analogy is sufficient on its own, because Cargo.toml serves a different role in the Rust ecosystem than a top-level LICENSE file does in a Go repository. The license field is surfaced by crates.io and consumed by tooling, so it is often the primary source of licensing information for a crate.

Because of that, I think discussions around this should take into account not only the legal compliance aspect, but also the Rust-specific distribution model, tooling, and user experience. My proposal was intended both to address the compliance concerns and to make the licensing requirements clearer for crate users.

[nathanielford]

I think we are good merging this with a couple of changes.

• NOTICE and LICENSE-APACHE should be the filenames, leaving off .grpc, .txt and .md. This will be consistent with our other files and ensure tooling doesn't ignore those files, which .grpc in particular will do.
• Make sure that you merge in current changes. Hopefully this won't be too cumbersome. If it is, and beyond your available time to handle, let me know and I can fork the change and do it.

[linux-foundation-easycla]

• ✅ login: nathanielford / name: Nathaniel Ford (d63e75d)
• ❌ - login: @tottoto / name: tottoto. The commit (010805e, 0d8937f, 171049c, 1b89758, 7faa305, 97f5e50, df2573b) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please visit our EasyCLA portal and chat with our support bot.

[nathanielford]

You'll need to accept the CLA agreement, but then this should be good to merge! Thank you!

[nathanielford]

@tottoto Bumping this! Want to get this in so it doesn't get left behind as we work on transition. Thanks again for your help!

[nathanielford]

@tottoto Bump!

[nathanielford]

@tottoto Hey there - do you want me to replicate these changes and submit them, or would you still like to do so? Feel free to reach out if you're having difficulty with the EasyCLA auth.