You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: add attribution & prior art policy to catch uncredited derivatives early
- CONTRIBUTING.md: new 'Attribution & Prior Art' section with clear rules
and examples of what requires attribution and how to do it
- PR template: add mandatory 'Attribution & Prior Art' checklist with
prior-art disclosure field
- copilot-instructions.md: add attribution checks to External Contribution
Quality Gate and PR Review mandatory checklist
Motivated by microsoft#748 — prevents uncredited derivatives of community work
from being merged without proper attribution.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,8 @@ Do NOT auto-merge large feature PRs without maintainer review.
16
16
17
17
When external contributors open issues or PRs proposing integration with their own project/tool/library, apply these quality checks before investing review time:
18
18
19
+
-**Attribution & prior art check**: If the PR implements functionality similar to an existing open-source project, verify it credits that project explicitly. Check the "Prior art" section in the PR template. If the PR mirrors patterns from a known project (architecture, CLI conventions, config schema, API design) without attribution, **request changes immediately** and do not merge until attribution is added. Uncredited derivatives of community work will be closed.
20
+
-**Timeline verification**: For PRs that arrive shortly after a community member proposes similar functionality in an issue, verify the PR author isn't racing to submit an uncredited copy of the proposed approach. Check issue discussion history for prior art.
19
21
-**Minimum credibility threshold**: The referenced project should have meaningful community adoption (e.g., 50+ GitHub stars, multiple contributors, evidence of production usage). One-person repos with <10 stars and no community traction do not warrant integration effort.
20
22
-**Self-promotion filter**: Issues or PRs that primarily serve to promote the contributor's own low-profile project — rather than adding genuine value to AGT — should be deprioritized. Politely acknowledge but do not fast-track.
21
23
-**Verify claims**: If the PR cites benchmarks, adoption numbers, or production deployments, spot-check them. Unverifiable claims are a red flag.
@@ -42,7 +44,8 @@ NEVER merge a PR without thorough code review. CI passing is NOT sufficient.
42
44
Before approving or merging ANY PR, verify ALL of the following:
43
45
44
46
1.**Read the actual diff** — don't rely on PR description alone
45
-
2.**Dependency confusion scan** — check every `pip install`, `npm install`, `cargo add` command in docs/code for unregistered package names. The registered names are:
47
+
2.**Attribution & prior art** — check if the PR implements patterns similar to known open-source projects. If it does, verify proper attribution exists in the PR description and code. Check whether the PR arrived shortly after a community member proposed similar work in an issue — if so, verify the contributor isn't submitting an uncredited derivative. **PRs without proper attribution will not be merged.**
48
+
3.**Dependency confusion scan** — check every `pip install`, `npm install`, `cargo add` command in docs/code for unregistered package names. The registered names are:
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+19Lines changed: 19 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,25 @@ contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additio
29
29
5. Update documentation if your change affects public APIs
30
30
6. Submit a pull request with a clear description of the changes
31
31
32
+
### Attribution & Prior Art
33
+
34
+
**All contributions must properly attribute prior work.** This is a hard requirement, not a suggestion.
35
+
36
+
- If your contribution implements functionality similar to an existing open-source project, you **must** credit that project in your PR description and in code comments or documentation where the pattern is used.
37
+
- Copying or closely adapting architecture, API design, CLI conventions, or documentation from another project without attribution is not acceptable, even if the code is rewritten.
38
+
- When in doubt, cite the prior art. Over-attribution is always better than under-attribution.
39
+
- PRs found to contain uncredited derivatives of other open-source work will be closed.
40
+
41
+
**Examples of what requires attribution:**
42
+
- Adapting a sandboxing approach from another security tool
43
+
- Using an algorithm or protocol design described in another project's docs
44
+
- Mirroring CLI flags, config schema, or architectural patterns from a known project
45
+
46
+
**How to attribute:**
47
+
- In your PR description: list related projects under "Prior art / related projects"
48
+
- In code: add a comment like `# Approach adapted from <project> (<license>)`
49
+
- In documentation: include a "Prior art" or "Acknowledgments" section
0 commit comments