-
Notifications
You must be signed in to change notification settings - Fork 98
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
Comments
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. |
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 :) |
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: |
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. |
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
But instead we have got: 'Copyright 2012-2015 The Mozilla Foundation, Telefonica S.A., and Nikita Prokopov (https://github.com/tonsky/FiraCode)'
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:
copyright
ascii_only_entries
check)I would also suggest that this might be more of a
warn
than a fail.The text was updated successfully, but these errors were encountered: