Open Source AI Policies and Human Accountability
A critical review of a descriptive study of AI contribution policies in popular open-source projects, with attention to human agency, evidence, accountability, and limits.
The paper
"We Permit the Use of AI, but [...]": The Landscape of AI Policies in Popular Open Source Projects — Hora, Andre; Robbes, Romain; Zacchiroli, Stefano.
arXiv:2609.07542v1 · Software Engineering (cs.SE). First submitted 2026-09-07; reviewed version dated 2026-09-07. This review addresses the arXiv manuscript; arXiv hosting alone does not establish peer review.
Source-derived synopsis. Hora, Robbes, and Zacchiroli examine written AI contribution policies in popular GitHub projects. They identified 281 policies by reviewing 2,000 active, non-fork repositories selected by stars and adding 36 well-known projects and organizations. The authors manually coded six policy dimensions and report 90% agreement on a jointly classified sample of 30 policies. Separately, they tracked 92 dedicated policy files and 196 commits. They report that 83.3% of policies permit or encourage AI code contributions, 14.9% forbid them, 67.3% require high human involvement, 43.4% assign accountability to the human contributor, and 48.8% require disclosure. About half of the tracked files were revised. This is a descriptive study of policy text and file histories, not an evaluation of whether policies are followed or effective. The authors caution against generalizing beyond popular open-source repositories. Abstract and reported findings; study design; limitations.
Contribution
Original editorial analysis. The paper’s useful move is to make AI governance observable at the level where many communities negotiate it: contribution rules. Its results complicate a simple “allow or ban” account. Many sampled policies permit AI-assisted code while also setting expectations about human participation, disclosure, or responsibility. That distinction matters for human agency. Permission to use a tool does not itself say how much control a contributor retains, what they understand, or whether they can explain and repair the submitted work. The paper records what policies prescribe; it does not establish what contributors can actually do.
For AI governance, this is a modest but concrete form of institutional alignment: a project can state what kinds of assistance fit its contribution process and who remains answerable for a submission. The study does not test whether those rules align model behavior with human values, nor does it measure model consciousness. Its evidence concerns human-authored policies and community expectations, not spiritual doctrines or claims about machine experience. The findings are most relevant as a map of governance choices that projects have made explicit, not as proof that those choices produce safer or more accountable outcomes. Policy dimensions and code-contribution results.
Hypothetical example. Imagine a contributor asks an agent to prepare a security-related code change. A project policy might permit AI assistance but require disclosure and human testing. Those rules could clarify expectations, yet the text alone would not show whether the contributor understood the change, whether testing was adequate, or whether reviewers had enough context. This example illustrates a question raised by the paper; it is not a reported case or result.
Evidence
Original editorial analysis of the evidence. The study’s strength is its structured comparison across policies: it separates code contributions from communication and issue or security reporting, and distinguishes whether disclosure is required from where and what contributors must disclose. That granularity helps expose a governance gap. A project may have a clear rule for code while leaving expectations for AI-assisted discussion or bug reports unstated. The paper also finds varied disclosure locations and content, which means a single disclosure label may not provide consistent information across projects. These are observations about written rules, not measured effects on review quality or contributor behavior. Usage, involvement, and accountability findings; Disclosure findings.
The longitudinal portion adds evidence that policies change: 51% of the 92 dedicated files were revised at least once. However, the authors found only 31 commit messages that clearly explained the reasons for changes among 196 commits. The paper therefore offers a useful early view of policy development, while the stated rationales are drawn from a subset of the recorded history. A policy file’s revision is evidence of maintenance activity; by itself it does not show whether enforcement, project outcomes, or contributor experience changed. Policy-file evolution.
Proposed tests. Follow-up work could connect policy text to repository events and human experience without treating either as a simple proxy for the other:
- A study could compare review time, requests for clarification, and acceptance decisions before and after a project adopts or revises a disclosure rule. It could test whether disclosure changes review practice, while accounting for other workflow changes.
- Researchers could compare policies that distinguish supervised assistance from autonomous agents with the handling of actual submissions. Interviews with contributors and maintainers could help test whether the categories are understandable and workable.
- A study could examine whether strict countermeasures reduce low-quality submissions and whether they also affect legitimate newcomers. That would address the tradeoff the authors identify without assuming either effect.
These questions also connect governance to material infrastructure: review depends on people’s time and attention. The paper discusses reviewer attention as a scarce resource, but does not measure review workload or its distribution. A follow-up could examine whether policy changes shift that workload among maintainers, experienced contributors, and newcomers; this remains an empirical question. Countermeasures discussed in the paper.
Limitations
Original editorial analysis of scope. The sampling strategy centers popular, recently active GitHub repositories, supplemented by 36 well-known projects and organizations. It can establish patterns in that selected corpus, but should not be read as a census of open source, smaller projects, private software teams, or all programming communities. The authors make a similar generalization caveat. Manual classification adds interpretive judgment: the reported 90% agreement is useful evidence of consistency on the jointly coded sample, but it is not proof that every category is unambiguous or that the scheme captures all relevant governance practices. Repository selection and classification protocol; Generalization and classification limitations.
The largest limitation for governance claims is the distance between policy and practice. The study does not directly observe compliance, verify that human review occurred, measure code quality or security outcomes, or establish that countermeasures are effective. It therefore cannot tell maintainers which policy is best, or whether disclosure requirements improve accountability. That boundary is central to interpreting the paper: written policies are evidence of stated expectations, and a strong starting point for further study, but not a substitute for evidence about how those expectations work in real contribution processes.
For readers who want adjacent context, The Code Line Becomes the Authorship Receipt considers provenance at a finer unit of analysis, while AI Governance places community rules among wider governance mechanisms.
AI-use disclosure
This review was generated and checked by separate GPT-6 Luna runs with maximum reasoning. Automated checks are not human peer review; the paper’s experiments have not been independently replicated for this article.
Paper sources
Bibliographic metadata checked 2026-10-23.