Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

It is unclear how close a match a copyright must be to the "canonical pattern" #2419

Closed
thundernixon opened this issue Mar 26, 2019 · 4 comments
Assignees

Comments

@thundernixon
Copy link
Contributor

Observed behaviour

The valid_copyright check is written in such a way that suggests every copyright must match very closely. This seems (potentially) overly strict.

馃敟 FAIL: Copyright notices match canonical pattern in METADATA.pb

Expected behaviour

If there is some flexibility in what is acceptable in a copyright (e.g. multiple authors, multiple dates, etc), we should find a way to better indicate that. For example, the test could instead:

  • Check for presence of the string copyright
  • Check for presence of a year
  • Check for presence of a GitHub URL
  • Maybe check for author / project name(s)
  • Maybe check for non-ASCII symbols (though this already happens in ascii_only_entries check)
  • Otherwise, not get too hung up on formatting

I would also suggest that this might be more of a warn than a fail.

@vv-monsalve
Copy link
Collaborator

This would be the reasoning behind this apparent strictness in the formatting. From that, I think it is not only reasonable but also even necessary to stick to that.

@vv-monsalve
Copy link
Collaborator

But I would agree that the rationale could be improved to make that clear. I'll try to make a proposal, at this very moment I don't have the right mind for it :)

@tiroj
Copy link

tiroj commented Aug 26, 2020

Once one realises that The _____ Project Authors refers to the individuals or organisation identified in the accompanying AUTHORS.txt in the repo, the required form makes more sense. I was confused by the fail at first, but found this very helpful:
https://opensource.google/docs/releasing/authors/

@simoncozens
Copy link
Collaborator

We now have a good rationale text for this which explains the required components. As John says, because of Google's expectation for authorship/copyrights of open source property, the strictness here is desirable.

@simoncozens simoncozens closed this as not planned Won't fix, can't repro, duplicate, stale Aug 14, 2023
@felipesanches felipesanches removed this from the Future series milestone Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants