Feature Request: Opt-In Contributor Association and Verified Repository Provenance

[DalL337]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Body

Hello GitHub Team,

I'd like to propose an improvement to how GitHub handles contributor attribution and repository provenance when an existing repository is forked or cloned and republished.

This concerns an issue that other GitHub users have also raised in community discussions: the inability to control whether their GitHub identity is publicly associated with a repository they do not own, maintain, or participate in.

Currently, when a repository is cloned with its Git history intact and published under another account, the original commit authors may automatically appear as contributors to the new repository.

While this behavior is technically consistent with Git's preservation of authorship, it creates an important distinction that GitHub's interface does not adequately address:

Historical authorship is not the same as current participation, affiliation, or endorsement.

This becomes particularly concerning when a derivative repository modifies the original software, changes its distribution methods, or introduces content that the original developer has never reviewed or approved.

I believe GitHub could address this without restricting open-source licensing, interfering with legitimate forks, or modifying Git's existing commit-history model.

Proposed Solution: Opt-In Contributor Association

I propose the following automated workflow.

1. Repository Publication and Detection

When a repository is forked through GitHub or when an independently cloned repository is pushed to GitHub with existing commit history intact, GitHub identifies the original repository through shared commit history.

The association process should occur when the derivative repository is published, not when someone simply clones a repository to their local machine.

2. Verified Provenance Record

GitHub generates a platform-managed provenance record identifying the original repository and its relationship to the newly published repository.

This record should be integrity-protected and maintained by GitHub, rather than stored in a file that the derivative repository owner can modify or delete.

The original repository link remains available as a verified source reference.

3. Notification to the Original Repository Owner

GitHub sends an automated email to the original repository owner or authorized administrator.

The notification explains that a derivative repository has been published and asks:

"Do you wish to have your GitHub identity publicly associated with this repository as an original author?"

The email includes a secure link to an authenticated decision page, along with the publication timestamp and response deadline.

4. Seven-Business-Day Response Window

The original owner has seven business days from the derivative repository's publication event to respond.

The deadline is calculated and enforced by GitHub, with timestamps recorded to the minute using a consistent time standard.

During this period, association remains pending. The original owner's identity is not automatically displayed as an affiliated contributor to the derivative repository.

5. Explicit Approval or Rejection

The original owner has two options:

Yes — Approve Association: GitHub displays a verified attribution identifying the person as an original author of the upstream project, accompanied by a link to the original repository. This attribution should remain distinguishable from active contribution to the derivative.

No — Decline Association: GitHub excludes the original owner's profile from contributor and affiliation displays associated with the derivative repository. The verified link to the original project remains, but no personal participation or endorsement is implied.

Neither decision alters historical commit records, copyright notices, or attribution required by the applicable open-source license.

6. Automatic Expiration

If the original owner does not respond within seven business days, GitHub automatically defaults to No Association.

An unanswered notification should never be interpreted as consent.

GitHub records whether the outcome resulted from an explicit decision or expiration, maintaining an appropriate internal audit trail.

7. Revocation of Previously Approved Association

An original owner who previously approved an association should be permitted to revoke it at any time.

Projects and maintainers change over time. Approval today should not obligate an original author to remain publicly associated with every future direction or distribution decision made by an independent repository owner.

Revocation would update GitHub's public association display without affecting Git history or existing licensing obligations.

Benefits to GitHub and Its Users

This approach would:

Preserve legitimate open-source copying, modification, and redistribution.

Maintain historical authorship and legally required attribution.

Give developers control over how their identities are represented on independently maintained repositories.

Make the distinction between original authorship and active participation more apparent to visitors.

Improve repository provenance and help users identify authoritative upstream sources.

Reduce misleading associations that can create reputational concerns and software-distribution confusion.

Provide a consistent, automated process rather than requiring affected developers to pursue individual support requests.

This would not require GitHub to adjudicate whether a derivative project is legitimate, nor would it give original developers the ability to prohibit redistribution permitted by an open-source license.

It would simply establish that permission to reuse source code and permission to imply personal association are separate matters.

Closing

GitHub already maintains much of the technical information necessary to support this system, including commit identities, repository relationships, and publication events.

I recognize that implementing a reliable provenance and notification system would require engineering work, particularly around identity verification, notification management, and independently published clones. However, I believe the resulting improvement to transparency, developer autonomy, and user trust would justify exploring it.

I would appreciate this proposal being considered by the appropriate product or engineering team, and I welcome feedback on its technical feasibility.

Thank you for your time and consideration.

Best regards,

Dal/Dai

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐