Update Developer Policy for copyright notices #123463
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This updates the developer policy to align with established community norms for copyright notices in source code contributed to LLVM. The updates clearly state that we do not accept code contianing explicit copyright notices in source except where such code is a pre-existing part of an external dependency that is being vendored into LLVM. Explicit copyright notices in source add no value to the project since copyright ownership is well tracked through git. Our policy already requires that contributions made not by the original author have appropriate attribution in git commit messsages or metadata. Further, explicit copyright notices in code can easily get out of date as the code is refactored, updated by additional authors or otherwise changed over time. This leads to misleading out-of-date copyright notices which do more harm than good. This change should be viewed as a clarification and statement of existing established policy, not a change in policy since it represents the way the project has been operating.
lattner
approved these changes
Jan 20, 2025
llvm/docs/DeveloperPolicy.rst
Outdated
| is good for the project, because contributors do not have to fear that their | ||
| code will be used in a way with which they disagree. | ||
|
|
||
| Embedded Copyright Statements |
There was a problem hiding this comment.
I'd suggest expanding this a bit, maybe something like "Embedded Copyright or 'Contributed by' Statements"
|
|
||
| The LLVM project does not accept contributions that include in-source copyright | ||
| notices except where such notices are part of a larger external project being | ||
| added as a vendored dependency. |
There was a problem hiding this comment.
I'd suggest adding a sentence of rationale: "LLVM source code lives for a long time and is edited by many people, the best way to track contributions is through revision control history."
|
Thank you for clarifying and codifying this! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates the developer policy to align with established community norms for copyright notices in source code contributed to LLVM.
The updates clearly state that we do not accept code contianing explicit copyright notices in source except where such code is a pre-existing part of an external dependency that is being vendored into LLVM.
Explicit copyright notices in source add no value to the project since copyright ownership is well tracked through git. Our policy already requires that contributions made not by the original author have appropriate attribution in git commit messsages or metadata.
Further, explicit copyright notices in code can easily get out of date as the code is refactored, updated by additional authors or otherwise changed over time. This leads to misleading out-of-date copyright notices which do more harm than good.
This change should be viewed as a clarification and statement of existing established policy, not a change in policy since it represents the way the project has been operating.