[License Exception Request] gRPC-Rust [Apache 2.0 + MIT dual-license]

[dfawley]

For which CNCF project are you requesting exceptions?

gRPC

Are you an official maintainer of this project?

Yes

List of components requiring an exception

Component	Upstream URL	License(s)	Purpose
tonic	https://github.com/hyperium/tonic	MIT	tonic pre-exists as a gRPC implementation, and is licensed under MIT-only. The gRPC project will take ownership of this repo & project, and the existing license cannot be changed. We will continue development on it, fixing bugs, adding features, changing APIs, and improving performance.
gRPC-Rust	https://github.com/grpc/grpc-rust (proposed)	Apache 2.0 + MIT	gRPC will build on top of tonic to provide full gRPC functionality. To maintain comatibility with tonic and match the Rust community's practices, we would like to dual-license.

Are all of the components mandatory dependencies for the project to function as intended?

Yes

If no, please explain

No response

How will the components be included in or with the project's code and distributions?

• Incorporated code
• Vendored component
• Build-time dependency
• Build and test tooling
• Install-time dependency
• Required upstream dependencies
• Other (please describe below)

If any of the above selections don't apply to all of the components listed in the table above, please explain

We do intend to maintain separation between the pre-existing tonic code (plus modifications) and the new gRPC code. The new gRPC library will build on top of the tonic library. However, tonic will not be vendored from its original location; gRPC will take full ownership of the repo.

Which of the following best describes how the components interact with the project's own code?

• Static linking: e.g., compiled together with project code into a single binary
• Dynamic linking: e.g., compiled into a separate binary, running together with project code in a single address space at run-time
• Separate process: e.g., separate executable running in a different process space, interacting with project code only via mechanisms such as pipes, sockets, etc.
• Network interaction only: e.g., logically separated over a network and communicating only via mechanisms such as network API call, exchanging JSON data, etc.
• Other (please describe below)

If any of the above selections don't apply to all of the components listed in the table above, please explain

No response

Will any of the components be modified?

Yes

If yes, please specify which components will be modified, and briefly describe the purpose and nature of the modifications.

As described above, we will maintain tonic as part of our regular day-to-day operations.

Will the project be seeking to contribute the modifications back to the upstream project?

None

[swinslow]

Hi, thanks for submitting this request. We'll discuss it with the CNCF Legal Committee in preparation for taking it to the CNCF Governing Board for their review.

Just to confirm, this is our understanding of your plans here -- can you please let us know if this is correct, or if anything is off?

For tonic:

• the existing tonic repo would be transferred as-is into the gRPC GitHub org
• the gRPC community would retain the "tonic" name and continue developing it as its own repo going forward
• it would continue to retain the MIT license, and new contributions would similarly come in and be licensed out under MIT

For gRPC-Rust:

• this would be a new repo, separate from tonic
• it would use tonic as a dependency
• all contributions to gRPC-Rust would be dual-licensed, under each user's choice of either MIT or Apache-2.0

Does that all match your plans? Thanks!

[dfawley]

@swinslow,

Thank you for your reply. One clarification/correction on two points:

• the gRPC community would retain the "tonic" name and continue developing it as its own repo going forward
  ..
• this would be a new repo, separate from tonic

Yes, the gRPC project would retain the "tonic" name, crates and repo. However, our current thinking is that we will:

1. Transfer and rename the https://github.com/hyperium/tonic repo to https://github.com/grpc/grpc-rust
2. Create a branch in that repo that will be used for long-term support of the existing tonic crates (limited to CVEs & bug fixes).
3. Remove the tonic code from the primary development branch.
4. Copy needed tonic code into the new "grpc" crate and maintain it in place (including features, refactoring, performance improvements, etc).

The goal with this approach is to preserve the repo history of tonic and avoid creating a repo in the grpc organization that will immediately be in a LTS/retirement state.

For licensing, our preferences (in order) would be:

1. Use MIT-only licensing. Tonic is already MIT-only, so this would be compatible and easy for us to administer.
2. Dual-license MIT+Apache. IIUC we cannot re-license tonic as Apache, so we must maintain MIT licensing for that purpose. Also, this is the preference of the Rust community.
3. Apache-only license for new code, but maintain a copyright notice from Tonic, noting that it is MIT licensed.

Please let us know what our options are, and if there are other considerations we may have missed.