License field change and future plans: grpc

[Benjamin Beasley]

I took over maintainership of the grpc package after it was orphaned for one month, and I
just built the first package in the process of rehabilitating it. A careful audit of the
sources required a License field change for the main package from “ASL 2.0” to “ASL 2.0
and BSD”. This does not reflect an upstream change.

Upstream does also provides certain source files under other licenses (ISC, MIT, MPLv2.0),
but at this point these are all removed in %prep. Previous versions of the package
*should* have been “ASL 2.0 and BSD and MPLv2.0”, but I have replaced the MPLv2.0-licensed
certificate bundle with a symbolic link to the system shared certificates.

There are a number of subpackages, some pre-existing, and some new. Many (grpc-cpp,
grpc-plugins, grpc-cli, grpc-devel, python3-grpcio, python3-grpcio-tools) now have the
same “ASL 2.0 and BSD” license as the base package, while others (grpc-data, grpc-doc,
python3-grpcio-channelz, python3-grpcio-health-checking, python3-grpcio-reflection,
python3-grpcio-status, python3-grpcio-testing, python-grpcio-doc) are still just “ASL
2.0”. This generally falls along arch/noarch lines.

I already fixed quite a few defects in the package, and added several Python packages that
were not being built. As I keep working on this package, I plan to:
  - Switch from building with make to building with CMake, which is better-supported
upstream.
  - Try to build and run the test suite.
  - Update to the latest version; at this point, I will build into a side tag, coordinate
with dependent packages, and issue a call for testing on this list. This package is a
Byzantine warren of code, and I am not even a user of it—just someone with a lot of
experience digging through Byzantine warrens of code—so there are a lot of things that
could go wrong, or could have already gone wrong undetected a long time ago! I’d like to
get to this point for Fedora 34.
  - Try to build for EPEL8.
  - Start trying to build the bindings for languages other than C, C++, and Python.

We’ll see how it goes!