Skip to content

LICENSE and check for grpc-rust.#2748

Open
nathanielford wants to merge 9 commits into
grpc:masterfrom
nathanielford:implement/license-check
Open

LICENSE and check for grpc-rust.#2748
nathanielford wants to merge 9 commits into
grpc:masterfrom
nathanielford:implement/license-check

Conversation

@nathanielford

Copy link
Copy Markdown
Contributor

Motivation

Ensure that licenses are being added and not improperly modified to all code files, in compliance with CNCF requirements.

Solution

This is a python script that runs in the CI and can be configured to run in a pre-commit. It also adds a LICENSE file to the grpc directory to conform with the MIT license being used throughout that part of the code-base. This script only checks the grpc directory at this time.

@nathanielford
nathanielford requested a review from dfawley July 22, 2026 22:23
@nathanielford
nathanielford marked this pull request as ready for review July 22, 2026 22:23

@dfawley dfawley left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could simplify this with a few minor changes.

  • We don't need to worry about files with apache licenses at all. We should just be enforcing that our source files have the MIT license. The Apache licensed code that is grpc-authored is all the protos that we just make copies of here.

  • The ALLOWED_AUTHORS thing can be removed and we can assert that the copyright directly states "gRPC authors".

  • I don't think we need a separate LICENSE in the grpc directory. We should update the LICENSE in the root, and also have @LucioFranco update all the copyright notices to have the same author ("gRPC authors") - or send him a PR that does this for him to approve. [EDIT: by "all" I mean the ones that are currently "(c) Lucio Franco"]

  • The .pre-commit-config.yaml and surrounding tooling feels like overkill to me at this point.

@LucioFranco

Copy link
Copy Markdown
Member

If someone can send me a PR that would be best otherwise i think what @dfawley said makes sense.

@nathanielford

Copy link
Copy Markdown
Contributor Author

I'll send you a PR @LucioFranco - I didn't want to overstep, but if you're good switching the licenses at this juncture I'll go ahead and do that for the entire repo. I won't merge this PR until that one is in.

Should I move the tools/ directory then to the top level and have this check the entire repo for the MIT/gRPC authors license or leave it across the grpc/ directory only? Also note this doesn't cover protos really, but should be adaptable to do so if we need it.

@dfawley

dfawley commented Jul 23, 2026

Copy link
Copy Markdown
Member

Should I move the tools/ directory then to the top level

SGTM.

and have this check the entire repo for the MIT/gRPC authors license or leave it across the grpc/ directory only?

If it's not too painful, that would be great. If there are a ton of problems then we can expand the scope over time.

@nathanielford

Copy link
Copy Markdown
Contributor Author

It's probably easy enough to put this across the entire repo. I was being conservative in scope just because I didn't want to overstep.

One last question: should I also try and cover proto files? These are largely under Apache licenses in the larger repo. Ignoring third_party and special cases (rls) is easy, but I'm not wholly sure what to do with the protos, some of which date back to 2015 or so and are licensed to Google LLC. For instance: examples/proto/googleapis/google/api/http.proto

@dfawley

dfawley commented Jul 23, 2026

Copy link
Copy Markdown
Member

We don't need an automated checker for those. However we want to ignore them should be fine. The main thing we need the checker for is to ensure that new files get the proper license clause in them. AFAIK we don't intend to author new proto files in this repo so if you were wanting to exclude anything ending in .proto, that should be fine.

@nathanielford

Copy link
Copy Markdown
Contributor Author

Ok, I think this is ready to go.

@dfawley dfawley left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for jumping on this! Just a couple more minor nits.

Comment thread tools/check_license.py
Comment on lines +3 to +4
Checks source files (*.rs, *.proto) for exact match against MIT or Apache 2.0 license boilerplate.
Performs piecewise validation and unified diffing against expected boilerplate templates.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: still mentions apache

Comment thread tools/check_license.py

MIN_YEAR = 2025

# Regex to capture: (prefix) Copyright [(c)] (year_spec)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there an optional (c)? Are we inconsistent?

Comment thread tools/check_license.py
Comment on lines +71 to +77
elif first_line.startswith("//"):
for line in lines:
if line.strip().startswith("//"):
header.append(line.rstrip())
else:
break
return header, None

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this bit be removed now? Or do we support //? Also: related things mentioning // above/below.

Comment thread tools/check_license.py

def validate_copyright_years(year_spec: str) -> tuple[bool, str | None]:
current_year = datetime.date.today().year
years = [int(y) for y in re.findall(r"\b\d{4}\b", year_spec)]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is more complex than it needs to be since we removed the range support?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants