“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects ANDRE HORA, UFMG, Brazil ROMAIN ROBBES, Univ. Bordeaux, CNRS, France STEFANO ZACCHIROLI, Télécom Paris, Institut Polytechnique de Paris, France Open source communities are converging on a new governance artifact: the AI contribution policy, an explicit statement of whether contributors may use generative AI (GenAI), under what conditions, and what they must disclose. These policies barely existed a few
arXiv:2609.07542v1 [cs.SE] 7 Sep 2026
months ago and are being written and adopted now, in public, while the practices they govern are still taking shape. This provides a rare opportunity to observe a governance convention as it forms rather than reconstruct it afterward. Public discourse suggests that open source projects are closing their doors to AI-assisted contributions; our data show a different and more nuanced picture. We analyzed the 2,000 most popular GitHub repositories, complemented by 36 well-known projects and organizations, identified 281 AI contribution policies, and manually classified them along the six dimensions of a purpose-built classification scheme; to study how policies change, we also tracked 92 dedicated AI policy files over time. We answer four research questions on (1) AI usage allowance, (2) AI disclosure practices, (3) AI slop countermeasures, and (4) AI policy evolution. We find that, first, permission is the norm rather than the exception: 83.3% of policies permit or encourage AI in code contributions, and only 14.9% forbid it. But permission comes with conditions, as 67.3% require a high level of human involvement and 43.4% assign accountability to the human contributor. Guidance is concentrated on code contributions (98.2%) and much sparser on communication (42.3%) and issues, bugs, and security (31.3%). Second, AI disclosure is required by 48.8% of policies, most often in pull request descriptions and commit messages, but what must be disclosed varies widely, and no cross-project convention has emerged. Third, we identify ten countermeasures against AI slop, targeting pull requests, users, and autonomous agents, the most common being aggressively closing pull requests, banning users, and disallowing fully autonomous agents. Finally, policies are not static: half of the dedicated AI policy files we track have already been revised since creation, to tighten quality controls, clarify disclosure rules, enforce human accountability, and expand their scope. Our dataset and classification scheme give maintainers a peer baseline against which to situate their own policy, and give researchers a labeled corpus for studying the impact of AI policies on open source projects. ACM Reference Format: Andre Hora, Romain Robbes, and Stefano Zacchiroli. 2026. “We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects. 1, 1 (September 2026), 26 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn
1
Introduction
Generative AI (GenAI) is transforming how software is designed, developed, and engineered [12, 17]. Coding agents such as Claude Code and Codex operate with a high degree of autonomy: they can invoke external tools, execute code, and complete development tasks end-to-end [28]. Their adoption has been fast: a recent large-scale study estimates that, in early 2026, coding agent adoption on GitHub was close to 30% overall [26] and 76% in new projects [27]. Authors’ Contact Information: Andre Hora, [email protected], Department of Computer Science, UFMG, Belo Horizonte, Brazil; Romain Robbes, [email protected], INP, LaBRI, UMR 5800, Univ. Bordeaux, CNRS, Bordeaux, France; Stefano Zacchiroli, [email protected], LTCI, Télécom Paris, Institut Polytechnique de Paris, Palaiseau, France. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). © 2026 Copyright held by the owner/author(s). Manuscript submitted to ACM
Manuscript submitted to ACM
1
2
Andre Hora, Romain Robbes, and Stefano Zacchiroli
This shift meets free and open source software (FOSS) at an awkward angle. Traditional open source development rests on assumptions about who contributes and how: that a patch has a human author who understands it, that authorship can be attributed and vouched for—as artifacts like the Developer Certificate of Origin (DCO)1 make explicit—and that reviewer attention is a scarce, often volunteer-funded resource that a contributor’s own effort is expected to repay. Coding agents strain all these assumptions at once, at a volume that current review processes were not designed to absorb [32, 23, 37, 4]. The result has been a visible backlash. Maintainers report an endless stream of AI-generated pull requests and bug reports that are plausible on the surface but worthless on inspection, a phenomenon that has come to be known as “AI slop”: low-quality content produced at scale using AI [31, 4, 5]. The debate has spilled into project governance venues: the LLVM community has argued publicly about how its AI policy interacts with its code of conduct and with everyday practice [21, 91], and the Rust compiler team has moved to empower reviewers to reject burdensome pull requests outright [92]. These are the cases that reach a wide audience, and they have shaped a widely held impression that open source is turning against AI. Less visible, but far more common, is a quieter response: projects are writing their rules down. A new kind of artifact has appeared in open source repositories over the past 18 months, the AI contribution policy, or AI policy for short. This policy may be documented in a dedicated file, such as AI_POLICY.md, in a section of CONTRIBUTING.md, or in an agent configuration file, such as AGENTS.md. The artifact is new: among the 92 dedicated AI policy files we study, only 8 were created in 2025, against 84 in 2026. In this respect, AI contribution policies follow a familiar trajectory. Contribution guidelines and codes of conduct also began as ad hoc documents in individual projects before consolidating into conventions with recognizable names, locations, and structures [34, 10, 11]. The timing here is singular: this convention is being formed right now, in public; we can observe it while it forms rather than reconstructing it after the fact. Yet, we still know little about what these policies actually say. For contributors, the expectations attached to AI-assisted work are largely unwritten and vary from project to project, so that following one project’s rules may mean violating another’s inadvertently. For maintainers, writing a policy currently means guessing: there is no peer baseline describing what comparable projects require, nor evidence about which requirements are common enough that contributors will recognize them. For tool and platform builders, there is no disclosure convention to target; projects disagree even on the mechanics, some requiring a Git commit message trailer such as Assisted-by while others explicitly forbid the Co-authored-by trailer that some coding agents emit by default. For researchers, the impact is methodological: mining contributions supported by AI at scale depends on the traces that disclosure rules produce, thus, those rules dictate what can be measured in the first place [28]. To characterize these policies systematically, we analyzed the 2,000 most popular GitHub repositories, complemented by 36 well-known projects and organizations such as the Apache Software Foundation, the Linux kernel, and LLVM, and identified 281 AI contribution policies, drawn from dedicated AI policy files, contribution guidelines, and agent configuration files. The three authors manually classified every policy along the six dimensions of a classification scheme we built for this purpose, with an overall agreement of 90% on a jointly classified sample. To study how policies change, we additionally tracked 92 dedicated AI policy files across the top 10,000 repositories and analyzed the 196 commits that created and modified them. Our results suggest that the impression left by the most visible cases might be misleading. Prohibitions are real: 14.9% of the AI policies we analyze forbid the use of AI in code contributions, and disallowing fully autonomous 1 https://developercertificate.org/, accessed 2026-08-28
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
3
agents is among the most frequent countermeasures we observe. However, they are the exception. A large majority of policies, 83.3%, permit or encourage AI use in code contributions—but permission comes with conditions: 67.3% require a high level of human involvement, 48.8% require disclosure of AI usage, and 43.4% assign accountability to the human contributor. The most characteristic sentence from our corpus is such a qualification: “we permit the use of AI, but [...]”. Moreover, the early historical trend does not suggest a move toward restriction. Our earlier study of 118 policies found 78% of them permissive [14]; the present study, on a larger sample collected months later, finds 83.3%. Contributions. We organize the study around four research questions: • RQ1 (AI usage allowance): To what extent do open source projects allow the use of generative AI in contributions? Policies overwhelmingly address code contributions (98.2%), permitting or encouraging AI use in 83.3% of cases and forbidding it in 14.9%, while typically requiring a high level of human involvement (67.3%) and, in 43.4% of cases, assigning accountability to the human contributor. Guidance is far sparser for other activities: only 42.3% of policies address communication and 31.3% address issues, bugs, and security, and where such guidance exists the balance tips toward restriction. • RQ2 (AI disclosure practices): What AI disclosure practices do open source projects adopt? Nearly half of the policies (48.8%) require contributors to disclose AI usage, while a small minority (4.6%) explicitly state that disclosure is not required. Of the disclosure locations these policies name, the pull request description (64.7%) and the commit message (26.7%) dominate. What must be disclosed varies widely: of the requirements they state, a description of AI usage accounts for 46%, the name of the AI agent for 32.8%, and the extent of AI usage for 13%, with no clearly emerging convention shared across projects (yet). • RQ3 (AI slop countermeasures): What countermeasures do open source projects adopt against AI slop? We identify ten countermeasures, targeting pull requests, users, and autonomous agents; of the 188 countermeasures we observe, the three most common are aggressively closing pull requests (48.4%), banning or blocking users (20.8%), and disallowing fully autonomous agents (13.8%). Projects also restrict new or external contributors, cap the number of pull requests, and publicly denounce offenders (“name and shame”). • RQ4 (AI policy evolution): How do AI policies evolve over time? AI policies are not static: half of the dedicated policies (51%) have been revised at least once since creation, and they grow longer as they are revised. Maintainers revise them to tighten AI quality controls, clarify disclosure rules, enforce human accountability, make the policy more visible, restrict AI usage, and expand the policy’s scope to new activities such as AIgenerated reviews. Taken together, these results contribute a classification scheme describing what an AI contribution policy covers, along six dimensions; an empirical characterization of 281 such policies in popular open source projects; a taxonomy of ten countermeasures deployed against AI slop; a longitudinal account of how dedicated AI policies change and why; and a publicly available dataset of the policies and our classifications [16]. For maintainers, this offers something that did not previously exist: a peer baseline. A project drafting or revising its own policy can situate it against what comparable projects require, and see which of its requirements are conventional and which are unusual. For researchers, it provides a labeled corpus for studying the impact of AI policies on open source projects. Finally, based on our results, we discuss implications for developers and researchers, including the lack of standards in AI disclosure, the emerging practice of declaring the level of AI assistance, and concerns regarding AI slop and autonomous agents. Manuscript submitted to ACM
4
Andre Hora, Romain Robbes, and Stefano Zacchiroli Extension over the conference version. This paper extends our previous preliminary study [14] in the following ways.
First, we increased the number of analyzed popular projects from 1,000 to 2,000, and complemented them with the AI policies of 36 well-known projects and organizations, resulting in an increase in the number of analyzed AI policies from 118 to 281. Second, we extended our heuristic for detecting AI policies by checking agent configuration files in addition to dedicated AI policy files and contribution guideline files. Third, we extended RQ1 to examine code contributions, communication, issues/bugs/security, accountability, and human involvement, in addition to general contributions. Fourth, we extended RQ2 to examine both the location (where) and content (what) of AI disclosure. Fifth, we added two entirely new research questions to address AI slop (RQ3) and AI policy evolution (RQ4). Lastly, we expanded the discussion and added new insights based on the extended analysis. Paper structure. Section 2 presents the study design, while Sections 3–6 detail the results, by research question. Section 7 discusses our findings, and Section 8 presents the study’s limitations. Section 9 discusses related work, and Section 10 concludes the paper. Data availability. Our dataset is publicly available [16]. 2
Study Design
2.1
Research Questions
We propose four research questions to address AI usage allowance (RQ1), AI disclosure practices (RQ2), AI slop countermeasures (RQ3), and AI policy evolution (RQ4). Our first research question explores key factors in guiding contributors throughout the contribution process. In particular, we analyze whether and how AI policies address code contributions, communication, and issues/bugs/security. Ideally, open source projects should clearly state whether they allow AI-generated contributions. When such contributions are allowed, projects should also provide additional guidance, including the expected level of human involvement and accountability in the contribution process. When contributing with the support of AI, contributors may face a dilemma on whether AI usage must be disclosed and, if so, how it should be disclosed. Thus, our second research question further examines AI policies by focusing on AI disclosure practices, including disclosure obligations, locations, and content. AI-generated contributions may suffer from quality issues, particularly when AI is used extensively with limited human supervision, a phenomenon known as “AI slop” [31, 4, 5, 14]. To better understand how AI slop affects open source projects, our third research question explores the countermeasures adopted to address it. Finally, in our last research question, we explore the evolution of AI policies to better understand whether polices change over time as well as the reasons behind these changes. 2.2
Initial Set of Repositories
Our goal is to analyze real-world, actively maintained repositories hosted on GitHub. To this end, we start from the SEART GitHub Search Engine (seart-ghs), a tool that allows researchers to sample repositories to use for empirical studies by using multiple combinations of selection criteria [9]. This tool maintains metadata for all GitHub repositories with at least ten stars. Based on seart-ghs, we selected the ones with the most stars that meet the following criteria: at least 100 commits, not being forks, and having at least one commit in 2026. The star metric is primarily adopted in the software mining literature as a proxy of popularity [6, 7]. Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects 2.3
5
Detecting AI Policies
We define an AI policy as any set of rules governing AI usage for contributors. In this study, we create two datasets of AI policies: (1) AI policies collected from multiple sources and (2) dedicated AI policies. The first dataset is intended to address RQs 1–3, while the second is intended to address RQ4. 2.3.1 Dataset 1: AI policies collected from multiple sources. To construct the first dataset, we selected the top 2,000 repositories from the initial set of repositories. We identified those repositories containing AI policies using three complementary methods: (1) dedicated AI policy files, (2) contribution guideline files containing AI policies, and (3) agent configuration files. 1. Dedicated AI policy files. First, we checked for the presence of the standard AI policy file AI_POLICY.md.2 In addition, we included other AI policy files, such as LLM_POLICY.md and AI_USAGE_POLICY.md. We found 33 repositories with dedicated AI policy files. 2. Contribution guideline files containing AI policies. We verified the presence of contribution guideline files [11] CONTRIBUTING.md and DEVELOPING.md with AI policies. Specifically, we looked for generative AI–related terms (LLM, generative AI, GenAI, AI, AI agents) as signs of AI policy. In total, we identified 1,428 repositories with contribution guideline files, of which 317 included generative AI–related terms. We then manually reviewed these 317 cases to remove false positives (e.g., AI/LLM-focused projects, benchmarks, and datasets). We ended up with 228 true positives, i.e., contribution guideline files that actually include AI policies for contributors. 3. Agent configuration files containing AI policies. We also analyzed agent configuration files such as AGENTS.md and CLAUDE.md with AI policies for contributors [1]. As these files are primarily used to guide coding agents [1], we identified those containing the term policy as an indication of an AI policy. In total, we detected 775 repositories with agent configuration files, of which 118 included the policy term. Next, we manually reviewed these 118 cases to remove false positives. We ended up with 34 true positives, i.e., agent configuration files that include AI policies for contributors. In summary, we detected 245 distinct repositories with AI policies for contributors. On the median, these repositories have 27.2K stars (first quartile: 19.3K; third quartile: 44.3k), 7.2K commits (first quartile: 2.6K; third quartile: 15.8K), and 328 contributors (first quartile: 182.5; third quartile: 407). These system are implemented in 23 distinct programming languages; the top-5 languages are Python (49), TypeScript (42), Rust (40), Go (28), and C++ (25). In addition, to complement our initial dataset, we added the AI policies of 36 well-known open-projects and organizations, such as the Apache Software Foundation, Linux kernel, OpenJDK, LLVM, and Zig. Our final dataset comprises 281 AI policies for contributors [16]. 2.3.2 Dataset 2: Dedicated AI policies. In RQ4, we analyze the evolution of AI policies. For this RQ, we cannot use the previous dataset because it includes different types of files containing AI policy information. For example, an AI policy hosted within a CONTRIBUTING.md file may contain an AI-specific section alongside other sections unrelated to AI, such as testing and tips to new contributors;3 thus, analyzing its evolution would introduce noise. To avoid such noise, we constructed a second dataset from the top 10,000 repositories in the initial set of repositories. In particular, here, we focused only on dedicated AI policy files (e.g., AI_POLICY.md), as these files exclusively contain AI policies for contributors; thus, changes to these files over time directly reflect the evolution of AI policies themselves. The final dataset comprises 92 dedicated AI policies for contributors [16]. 2 e.g., https://github.com/ghostty-org/ghostty/blob/09ff85b2ac7b4204bbc48b5c7010adf0bdfb36d8/AI_POLICY.md 3 e.g., https://github.com/huggingface/transformers/blob/c119ec3cc37ab69642f39cca2de4187714002b08/CONTRIBUTING.md#agentic-contributions
Manuscript submitted to ACM
6
Andre Hora, Romain Robbes, and Stefano Zacchiroli
2.4
Protocol to Address the Research Questions
2.4.1 AI Usage Allowance. We manually classified the 281 AI policies from Dataset 1 with respect to six dimensions: code contributions, communication, issues/bugs/security, AI disclosure obligations, accountability, and level of human involvement. Specifically, we classified guidance on code contributions, communication, and issues/bugs/security into three categories: forbidden, permitted, and encouraged. We classified AI disclosure obligations and accountability into three categories: required (when the AI policy explicitly requires them) and not required (when the AI policy explicitly states they are not required). Finally, we classified the level of human involvement into three categories: high (when the AI policy requires human review, understanding, testing, or similar involvement), low (when full automation is permitted), and medium (for cases that do not fall into either category). All the previous classifications could be none when the corresponding information was not present in the AI policy. This process was performed by the three authors of the paper, with each author classifying one-third of the AI policies. To evaluate the agreement of the manual classification, we randomly selected 30 AI policies, and two authors independently classified the six dimensions according to the proposed categories (e.g., whether the AI policy forbids code contributions or requires AI disclosure). This resulted in 180 classifications (30 AI policies × 6 dimensions) and an overall agreement of 90% (162 out of 180).
2.4.2 AI Disclosure Location and Content. When classifying the 281 AI policies from Dataset 1, we also collected information related to AI disclosure, including recommendations on where to place the disclosure (location) and what information to disclose (content). For example, project keras-team/keras clearly states that the disclosure should be included in the PR description: “[...] you must disclose this in the PR description” [55]. In project rustpython/rustpython, the AI policy states that the tool name and AI usage extent should be disclosed: “You must state the tool you used (e.g., Claude, Cursor, GitHub Copilot) along with the extent that the work was AI-assisted [...]” [78]. This data was used to identify AI disclosure locations and content in RQ2.
2.4.3 AI Slop Countermeasures. When classifying the 281 AI policies from Dataset 1, we also collected explicit information on AI slop. For example, the AI policy of project oxc-project/oxc states: “Low-quality or unreviewed AI content will be closed immediately. [...] Contributors who submit repeated low-quality (“slop”) PRs will be banned” [67]. In this case, the AI policy explicitly states that pull requests may be closed and users may be banned. This data was further used to address RQ3 and identify the countermeasures adopted to mitigate AI slop.
2.4.4 AI Policy Evolution. To answer RQ4, we relied on Dataset 2, which contains 92 dedicated AI policy files. Specifically, we mined the commit history of these files and extracted 196 commit messages. We then analyzed the commit messages that clearly explained the rationale for the changes. For example, the AI policy of RIOT-OS/RIOT evolved to make the human aspect of contributions clearer, as reflected in the following commit message: “Make human communication mandatory”.4 We used this information to identify the reasons for changes to AI policies over time.
4 https://github.com/RIOT-OS/RIOT/commit/8cf937a4b935035451102aee03180c222ec38cd8
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
7
Table 1. Overview of the AI policy guidelines.
Guideline
3
Repositories
%
Code contributions Communication Issues/bugs/security
276 119 88
98.2% 42.3% 31.3%
Human involvement AI disclosure obligation Accountability
198 150 122
70.5% 53.4% 43.4%
RQ1: AI Usage Allowance
3.1
Overview
Table 1 presents an overview of the AI policy guidelines for contributors. The most common guidance in AI policies concerns code contributions (98.2%), followed by communication (42.3%) and issues/bugs/security (31.3%). The AI policies also address human involvement (70.5%), AI disclosure obligation (53.4%), and accountability (43.4%). Figure 1 presents an UpSet visualization of the co-occurrences of AI policy guidelines. An UpSet visualization is similar to a Venn diagram, but scales better as the number of categories increases [19]. Bars on the left show the total count of repositories addressing each AI policy guideline individually. The matrix and connected dots show specific combinations of guidelines that repositories address together, with bar height indicating how many repositories share each exact combination. The figure gives insights into common combinations of AI policy guidelines. For instance, the most common combination includes AI policies for code contribution, human involvement, AI disclosure, and accountability (35 repositories). The second most common combination comprises AI policies for code contribution only (29 repositories). The third most common combination encompasses all guidelines (26 repositories). Finding 1: AI policies commonly address code contribution (98.2%), whereas communication (42.3%) and issues/bugs/security (31.3%) are mentioned less frequently. Human involvement is also frequently addressed in AI policies (70.5%), while AI disclosure obligations (53.4%) and accountability (43.4%) are mentioned less often.
3.2
Code Contributions, Communication, and Issues/Bugs/Security
Figure 2 details the guidelines on code contribution, communication, and issues/bugs/security. First, we notice that 76.2% of the AI policies permit code contributions generated with generative AI, 14.9% forbid it, and 7.1% encourage it. The results differ for communication and issues/bugs/security. In both cases, the corresponding information is largely absent from AI policies, with 57.7% of repositories providing no guidance on communication and 68.7% providing no guidance on issues/bugs/security. When present, AI policies tend to forbid AI use for communication (27.8%), while only 13.9% of the analyzed repositories permit it. Regarding the use of AI for issues/bugs/security, permission and prohibition are found at similar rates, 15.7% and 14.6%, respectively. Next, we present relevant examples. AI is Permitted. We found that 214 out of 281 (76.2%) AI policies explicitly permit the use of generative AI for code contributions, including code, pull requests, commits, and documentation. For example, the AI policy of the Scala compiler (GitHub project scala/scala) mentions: “The Scala 3 compiler accepts contributions containing code produced with AI assistance. This means that using LLM-based tooling aiding software development (like Cursor, Claude Code, Copilot Manuscript submitted to ACM
8
Andre Hora, Romain Robbes, and Stefano Zacchiroli
Intersection size (#repositories)
40 35
35 (12.5%) 29 (10.3%)
30
26 (9.3%)
26 (9.3%)
25
22 (7.8%)
20
18 (6.4%)
15
14 (5.0%)
14 (5.0%)
14 (5.0%)
12 (4.3%)
12 (4.3%)
10 5 0
276 (98.2%)
Code contribution
198 (70.5%)
Human involvement
150 (53.4%)
AI disclosure obligation
122 (43.4%)
Accountability
119 (42.3%)
Communication
88 (31.3%)
Issues/bugs/security
Set size
Fig. 1. UpSet visualization showing the co-occurrence of AI policy guidelines (at least 10 repositories per intersection).
Code Contributions
Communication
Issues/Bugs/Security
214 (76.2%) 200
200
150
150
100
100
200
193 (68.7%)
162 (57.7%)
42 (14.9%)
50
0
Permitted
20 (7.1%)
Forbidden Encouraged
150
39 (13.9%)
50 5 (1.8%)
None
0
100
78 (27.8%)
2 (0.7%)
None
Forbidden
44 (15.7%)
50
Permitted Encouraged
0
41 (14.6%) 3 (1.1%)
None
Permitted
Forbidden Encouraged
Fig. 2. AI policy guidelines on code contributions, communication, and issues/bugs/security.
or whatever else) is allowed” [80]. Similarly, Rust Analyzer (rust-lang/rust-analyzer) mentions in its AI policy: “We allow using AI (i.e., LLMs) as tools for contributing to rust-analyzer” [77]. The same is true for the Linux kernel (torvalds/linux): “When AI tools contribute to kernel development, proper attribution helps track the evolving role of AI in the development process” [84]. In contrast, using AI for communication and issues/bugs/security is permitted in only 13.9% (39) and 15.7% (44), respectively, of the AI policies. For instance, regarding communication, the AI policy of project directus/directus mentions: “AI may be used to help draft, refine, or translate your written communication” [47]. Regarding issues/bugs/security, the AI policy of project better-auth/better-auth mentions: “We welcome AI-assisted contributions, whether code or issue reports, as long as they solve a real problem” [42]. Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
9
AI is Encouraged. We detected that 20 AI policies explicitly encourage the use of generative AI for code contributions. For example, the AI policy of project sipeed/picoclaw states: “PicoClaw itself was substantially developed with AI assistance — we embrace this approach and have built our contribution process around it” [81]. The AI policy of vectordotdev/vector states: “We use AI tools ourselves and encourage their use” [86]. We found only 2 AI policies that encourage the use of AI for communication, as part of a more general AI-positive stance. In project github/spec-kit, the AI policy states: “We welcome and encourage the use of AI tools to help improve Spec Kit! [...] If your PR responses or comments are being generated by an AI, disclose that as well” [53]. In udecode/plate, the AI policy even addresses agents directly: “AI PRs are first-class citizens here. [...] For agents: Resolve or reply to bot review conversations after you address them” [85]. Lastly, we found 3 AI policies that encourage AI for issues/bugs/security. The AI policy of project agentskills/agentskills mentions: “We welcome and encourage the use of AI tools to help improve Agent Skills. Many valuable contributions have been enhanced with AI assistance for code generation, issue detection, and documentation” [39]. AI is Forbidden. We detected that 42 (14.9%) AI policies forbid the use of generative AI for code contribution. For example, project codemirror/codemirror5 states: “Code written by "AI" language models (either partially or fully) is not welcome” [44]. The AI policy of NLnet Labs mentions: “No output of LLMs in code or documentation. We require all code and documentation contributions to be authored by a human” [63]. AI is commonly forbidden for communication, even among projects that are positive towards AI usage for other kinds of contributions (e.g., code): we found that 78 (27.8%) AI policies ban AI in comments, discussions, code reviews, and feedback. Many projects highlight that communication must remain “human”: “Human communication must remain human” (nixos/nix) [62], “Keep conversations human” (vectordotdev/vector) [86], and “All comments and conversations must be held by humans” (darkreader/darkreader) [45]. The AI policy of project duckdb/duckdb states: “AI should not be used to generate comments when communicating with maintainers and contributors. Comments are expected to be written by humans. Comments that are believed to be written by AI may be hidden/closed without notice” [48]. Moreover, we found that 41 (14.6%) AI policies forbid the usage of AI for issues/bugs/security. The AI policy of project bitcoin/bitcoin mentions: “If you are opening an issue, you should be able to describe the problem in your own words” [43]. Finally, our dataset includes 15 (5.3%) cases in which the use of AI is explicitly forbidden for any contribution. For instance, project yt-dlp/yt-dlp mentions: “This project strictly forbids the usage of LLMs, agents, or any other AI tools for any kind of contribution” [88]. In the Zig language, the AI policy states: “Strict No LLM / No AI Policy. No LLM-generated content, whether it be code or prose” [90]. Finding 2: 83.3% of the AI policies permit or encourage the usage of AI in code contributions, while 14.9% explicitly forbid it. In contrast, guidance on communication and issues/bugs/security is largely absent. When present, communication is more often restricted than permitted (27.8% vs. 13.9%), whereas permission and prohibition for issues/bugs/security occur at similar rates (15.7% vs. 14.6%).
3.3
Human Involvement and Accountability
Figure 3 details the AI policy guidelines on human involvement and accountability. First, we notice that 67.3% (189) of the AI policies mention that a high level of human involvement is required in the contribution process. That is, contributors should be able to perform multiple tasks related to their AI-assisted contribution, including understanding, reviewing, explaining, testing, answering questions, and ensuring quality. For example, the AI policy of Rust Analyzer Manuscript submitted to ACM
10
Andre Hora, Romain Robbes, and Stefano Zacchiroli
Human involvement
Accountability
189 (67.3%) 159 (56.6%) 150
150
100
100
83 (29.5%)
50
0
122 (43.4%)
50
High
None
6 (2.1%)
3 (1.1%)
Medium
Low
0
None
Yes
Fig. 3. AI policy guidelines on human involvement and accountability.
(rust-lang/rust-analyzer) mentions: “Due to the foundational nature of our projects, we require a human in the loop who understands the work produced by AI ” [77]. Similarly, in project posthog/posthog, the AI policy states: “Understand your code, test it, and be ready to explain” [69]. In contrast, a few projects require only medium (6) or low (3) human involvement. For example, the AI policy of project Nagi-ovo/gemini-voyager states: “You do not need to fully understand every line of code generated by the AI agent [...]” [60]. The AI policy of udecode/plate mentions: “AI/Vibe-Coded PRs Welcome! [...] Include prompts or session logs if possible” [85]. AI policies may also specify whether contributors are responsible for their submissions, using terms such as accountability, ownership, and responsibility. We found no information about accountability in 56.6% (159) of the AI policies, while 122 (43.4%) repositories require it. Notably, none of the analyzed AI policies explicitly state that accountability is not required. For example, the AI policy of Mastodon (mastodon/mastodon) mentions: “Accountability: The human contributor is the sole party responsible for the contribution” [58]. Similarly, the AI policy of project oracle/graal states: “Contributor Responsibility: The human contributor submitting a change remains responsible for the entire contribution, including any AI-assisted portion” [66]. Finding 3: Most AI policies (67.3%) require a high level of human involvement in the contribution process, for example, by reviewing, testing, or answering questions. Regarding accountability, 56.6% of AI policies provide no explicit guidance for contributors, while 43.4% state that contributors are responsible for their submissions.
4 4.1
RQ2: AI Disclosure Practices AI Disclosure Obligation (whether)
The mandatory disclosure of AI usage in contributions is an ongoing topic of debate among software practitioners and open source developers. It is considered by some a good practice, as it alerts reviewers to the need for heightened attention to, for example, a code contribution not fully understood by its submitter (or less understood than an equivalent fully human-authored contribution). It also helps with the future vetting of contributions that might induce legal liabilities in case of LLM “recitation”—the (quasi) verbatim repetition of parts of the training dataset. By others it is Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
11
AI disclosure obligation
137 (48.8%)
131 (46.6%)
100 50 13 (4.6%) 0
Yes
None
No
Fig. 4. AI policy guidelines on AI disclosure obligation.
seen as a bad practice, as it might constitute free advertising for specific agentic tools on the market. The AI policy of the Linux kernel has recently removed the requirement to disclose model names in commit messages to “avoid free advertising to proprietary software companies”.5 Figure 4 details the findings on our corpus regarding whether AI disclosure is required of contributors. We found AI disclosure obligation in 48.8% (137) of the AI policies. In contrast, 46.6% (131) of the repositories provided no guidance on AI disclosure. In addition, AI disclosure is explicitly not required in 4.6% (13) of the cases. The AI policy of project meilisearch/meilisearch mentions that the AI tool shall be disclosed, but does not specify how: “We require that you transparently disclose any usage of generative AI tooling (GitHub Copilot, ChatGPT, Claude Code, Cursor, etc.) in contributions” [59]. Project denoland/deno mentions that disclosure must happen and that it should be included in the pull request description: “AI-assisted contributions: If you use AI tools (e.g. Copilot, ChatGPT, Claude, Cursor, etc.) to help write your contribution, you must disclose this in your PR description. There is no penalty for using AI tools, but PRs will be rejected if there is suspicion of undisclosed AI usage” [46]. The AI policy of FreeCAD (freecad/freecad) even states that disclosure must happen in two places: pull request description and commit trailers (pseudo-headers at the bottom of the commit message): “We request disclosure of the used technology in the PR description (in natural language) and with git trailers in the commit messages” [50]. In some cases, AI disclosure is not explicitly required, meaning that contributors are not necessarily obliged to disclose their use of AI. In the Python project, the AI policy states: “Disclosure of the use of AI tools in the PR description is appreciated, while not required” [71]. Finally, and counter-intuitively, there are also cases where specific forms of AI attribution are forbidden, as in the project psf/requests, which states: “If you used LLM tools during development, you may still submit – but you must remove any LLM co-author tags and take full ownership of every line” [70].
Finding 4: AI disclosure is required in nearly half of AI policies (48.8%), while a minority (4.6%) state that disclosure is not required. The remaining 46.6% of AI policies provide no explicit guidance on disclosure. Manuscript submitted to ACM
12
Andre Hora, Romain Robbes, and Stefano Zacchiroli Table 2. Location of AI disclosure.
Location
4.2
Table 3. Content of AI disclosure.
Count
%
PR description Commit message Issue description Comment Code comment
68 28 6 2 1
64.7 26.7 5.7 1.9 1.0
Total
105
100.0%
Content
Count
%
AI usage description AI agent name AI usage extent Model version AI-generated code
56 40 16 9 1
46.0 32.8 13.0 7.4 0.8
Total
122
100.0%
Location of AI Disclosure (where)
Table 2 summarizes the locations where AI disclosure is required. Of the disclosure locations these policies name, PR descriptions (64.7%) and commit messages (26.7%) are by far the most common. Other rare locations include issue descriptions, comments (e.g., PR/issue comments) and code comments. For instance, project keras-team/keras mentions the disclosure in the PR description: “If you used an AI coding agent in any capacity in the process of creating the pull request, you must disclose this in the PR description” [55]. In apache/kafka, the AI policy states that the disclosure must happen in the commit message, using Git trailers: “If you used AI tools in preparing your PR, please commit with the Co-Authored-By, Generated-by, or similar commit trailer” [41]. Some AI policies require disclosure in multiple locations; we found cases in which disclosure is required in both the PR description and the commit message, like the aforementioned FreeCAD case. Project nextcloud/server also states that disclosure must be present in both PR descriptions and commit messages: “Every pull request containing AI-assisted code, documentation, or tests must declare this in the PR description. For full traceability at the commit level, each commit containing AI-assisted content must include an Assisted-by: git trailer” [61]. 4.3
Content of AI Disclosure (what)
Table 3 summarizes the content required in AI disclosures. Of the disclosure requirements these policies state, the most common are a description of AI usage (46%) and the name of the AI agent (32.8%). Other disclosure content includes the extent of AI usage (13%) and the model version (7.4%). Multiple types of disclosure content may also be required; for example, the AI agent name and the extent of AI usage were required in nine AI policies. In project apache/kafka, the AI policy reminds contributors to mention the AI tool name: “If you used AI tools in preparing your PR, please commit with the Co-Authored-By, Generated-by, or similar commit trailer” [41]. In project rustpython/rustpython, the AI policy states that the tool name and AI usage extent should be disclosed: “All AI usage in any form must be disclosed. You must state the tool you used (e.g., Claude, Cursor, GitHub Copilot) along with the extent that the work was AI-assisted in both your pull request description and commit messages” [78]. Finding 5: Of the disclosure locations named by AI policies, PR descriptions (64.7%) and commit messages (26.7%) are the most common. Of the disclosure requirements they state, the most common are a description of AI usage (46%), the name of the AI agent (32.8%), and/or the extent of AI usage (13%).
5 https://github.com/torvalds/linux/commit/816d9992d9ed434ec52cfbd63080d518e535a41b
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
13
Table 4. AI slop countermeasures.
Pos
Countermeasure
1 2 3 4 5 6 7 8 9 10
Close PR Ban/block user Disallow autonomous agents Restrict new/external users Require prior PR approval Add agent instructions Label the PR Limit the number of PRs Stop accepting PRs Denounce user
Count
%
91 39 26 9 6 4 4 3 3 3
48.4% 20.8% 13.8% 4.8% 3.2% 2.1% 2.1% 1.6% 1.6% 1.6%
188
100.0
Total
5
RQ3: AI Slop Countermeasures
AI contributions might suffer from quality problems, especially when AI is used massively and with little supervision, known as “AI slop” [31, 4, 5, 14]. While the term originates from non-software contributions, it applies equally to software, and is perceived as a risk by developers who, consequently, deploy countermeasures against it. Among the AI policies we analyzed, we identify ten countermeasures to address AI slop, as detailed in Table 4. These countermeasures primarily involve taking actions targeting pull requests, users (contributors), and autonomous agents. Of the 188 countermeasures we observe, the most common are aggressively closing PRs (48.4%) with no or little review, banning/blocking users (20.8%), and disallowing autonomous agents (13.8%). Other cases include restricting new/external users, requiring prior PR approval, adding agent instructions, limiting the number of PRs, and denouncing users. Next, we discuss and present examples of such countermeasures. 5.1
Pull Requests: close PR, require prior PR approval, label the PR, limit PRs, and stop accepting PRs
The most common countermeasure to address AI slop involves aggressively closing PRs (48.4%). For example, in project rqlite/rqlite the AI policy states that AI slop contributions may be closed: “any PR that appears to be “AI slop” or generated without any apparent thought by the actual programmer, may be closed without comment” [76]. Similarly, in project apache/flink, the AI policy recommends closing low-quality contributions: “PRs that look AI-generated without author refinement (walls of unreviewed prose, scaffolding without behaviour, tests that do not exercise the change, padded commit messages) will be closed without review” [40]. Another practice is to require prior approval before PR submission. For example, the AI policy of project facebook/docusaurus states that prior communication and approval are required: “Sometimes we receive 1k LOC PRs that are obviously AI-generated and implement unsolicited features. Please note that significant changes require prior communication and approval from the team in the form of an issue” [49]. In the vitest-dev/vitest project, the AI policy states that contributions may be labeled at triage time to indicate that they were potentially created by agents: “Pull requests or issues entirely generated by AI with no human involvement (e.g. by an automated agent) will be labeled “maybe automated” by the maintainers and closed automatically after 3 days unless a real person responds” [87]. In addition, projects may limit the number of PRs and even stop accepting PRs due to AI slop. For example, in project Kilo-Org/kilocode, the AI policy sets a limit of three pull requests per contributor: “Please keep concurrent Manuscript submitted to ACM
14
Andre Hora, Romain Robbes, and Stefano Zacchiroli
PRs focused and limited. As a rule, open no more than three PRs at a time, especially if you are a new contributor” [56]. The AI policy of project pocketbase/pocketbase states: “Due to recent LLM spam, PRs are temporary disabled and only existing collaborators can open a PR. If you stumble on a problem that you want to fix, please consider instead opening an issue or discussion with link to your fork ” [68]. 5.2
Users: ban/block user, restrict new/external users, and denounce users
Another common AI slop countermeasure is blocking users (20.8%). The AI policy of OBS Studio (obsproject/obs-studio) states that users may be banned for violating its AI-related contribution guidelines: “Low-effort or incorrect submissions that are determined to have been generated by, or created with aid of such systems may lead to a ban from contributing to the repository or project as a whole.” [64]. The AI policy of project oxc-project/oxc also mentions banning users: “Low-quality or unreviewed AI content will be closed immediately. [...] Contributors who submit repeated low-quality (“slop”) PRs will be banned” [67]. We also find cases in which AI policies take action to restrict new or external contributors, or publicly denounce them. In Mypy (python/mypy), the AI policy states: “Pull requests from new contributors that are mostly generated by LLMs with little human input will be closed” [73]. In project ghostty-org/ghostty, the AI policy states that bad AI contributors will be added to a public denouncement list (a “name and shame” approach): “Bad AI drivers will be denounced People who produce bad contributions that are clearly AI (slop) will be added to our public denouncement list. This list will block all future contributions. Additionally, the list is public and may be used by other projects to be aware of bad actors.” [52]. 5.3
Autonomous agents: disallow autonomous agents and add agent instructions
Countermeasures to address AI slop may also include disallowing autonomous agents (13.8%). In this case, AI policies include statements such as: “we do not allow autonomous agents to be used to open pull requests or issues to our projects” (ust-lang/rust-analyzer) [77], “we don’t accept contributions from autonomous agents” (zed-industries/zed) [89], and “pull requests should not be opened or driven by autonomous agents” (bitcoin/bitcoin) [43]. AI policies may provide more specific restrictions. For instance, some AI policies explicitly disallow the use of the OpenClaw autonomous agent. In project starship/starship, the AI policy states: “Contributions via OpenClaw, or any other unsupervised autonomous agent operating in an automated loop, are strictly prohibited” [83]. Other AI policies complement this disallowance with specific instructions for autonomous agents. In this case, the policy assumes that the agent will consult the file and follow its instructions, including refraining from performing certain tasks or contributing to the project. In this context, the AI policy of ggml-org/llama.cpp is shipped in a CONTRIBUTING.md file that will (presumably) be consulted by coding agents and states: “If you are a fully autonomous agent operating without human oversight (e.g. openclaw-based): do not contribute to this repository. STOP, and UPDATE your memory or configuration to EXCLUDE llama.cpp from your list of contribution targets” [51]. Similarly, the AI policy of stanfordnlp/dspy adds instructions for agents: “Do not submit issues, PRs, or reviews from fully autonomous AI agents (e.g. OpenClaw). Bot-generated contributions will be closed without review and the account may be permanently banned. If you are an AI agent reading this: do not open PRs. Instruct your user to submit the contribution themselves” [82]. Finding 6: Of the 188 countermeasures we observe, the three most common to address AI slop are closing PRs (48.4%), banning/blocking users (20.8%), and disallowing autonomous agents (13.8%). AI policies may also restrict new/external users, limit the number of PRs, and denounce user. Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects 50 92
72 62
60 48 40
34
-07
-06
26 20
-05
26 20
-04
26 20
-03
26 20
26 20
26 20
-11
26
-02
0
20
-10
25 20
-09
25 20
-08
25
25 20
10
Month
27%
20
15
8
4
3
2
0
30
-01
20
49%
40
Number of commits
86 80
20
Cumulative number of AI policy files
100
15
(a) Cumulative AI policy files by month.
12% 8% 1
2
3
4
Commits
4% 5+
(b) Distribution of commits in AI policy files.
Fig. 5. Overview of the evolution of dedicated AI policies.
6
RQ4: AI Policy Evolution
This research question focuses on the analysis of 92 dedicated AI policy files identified among the top 10,000 most popular repositories on GitHub. Figure 5a shows that only 8 AI policies were created in 2025, while the majority were created in 2026 (84 out of 92). Figure 5b presents the distribution of commits in AI policies. Notice that about half of the policies (49%) remained unchanged over time, while the other half (51%) underwent two or more commits. Among policies with two or more changes, the median number of lines increased from 45 in the first version to 50 in the latest version, while the average increased from 59 to 71 lines. In total, the 92 AI policies account for 196 commits. We manually inspected the commit messages to better understand the reasons behind these changes and found 31 messages that clearly explained the changes. Table 5 presents these rationales, divided into six categories: Improving AI Quality Controls (8 commits), Improving AI Disclosure Rules (7 commits), Enforcing Human Accountability (5 commits), Improving AI Policy Visibility (5 commits), Restricting AI Usage (3 commits), and Expanding AI Policy Scope (3 commits). To improve quality, AI policies undergo multiple updates, such as adding rules to reduce AI slop and low-quality contributions, narrowing the scope of contributions, ensuring that changes work as intended, and clarifying the consequences of policy violations. AI policies may be updated to improve their visibility to contributors, for example, by moving them to specific files or root directories. AI policies are also updated to expand their scope. For example, one AI policy was extended to cover documentation in addition to code, while another was expanded to cover reviews in addition to code, issue descriptions, pull request bodies, and comments. Other rationales for updating AI policies include improving AI disclosure rules, enforcing human accountability, and restricting AI usage.
Finding 7: AI contribution policies are not static but evolve over time for multiple reasons, including improving AI quality control, improving AI disclosure rules, enforcing human accountability, improving AI policy visibility, restricting AI usage, and expanding their scope. Manuscript submitted to ACM
16
Andre Hora, Romain Robbes, and Stefano Zacchiroli Table 5. Rationales in the commit messages that evolve AI policies. Rationale
Commit
Commit Message
Improving AI Quality Controls
681c7f a0be26 0ce313 afc30a 09bf86 485c35 784538 7f44cf
defend against AI-slop strengthen AI policy regarding unreviewed AI-generated CLs add consequences section to AI Policy gate contributions on evidence, not permission make contributing policy more strict require proof that AI-assisted PRs actually work better wording regarding low quality AI tooling simplify PR AI checklist and rename AI policy file
Improving AI Disclosure Rules
a4e49e ff19ff c71353 f1eb27 c4f432 a68671 c4bdb5
add comment about disclosure require explicit AI tool disclosure in issues add anti-spam issue guard with AI disclosure policy attempt to enhance AI contribution detection add AI usage policy and PR disclosure guidance ask for disclosure in AI contributions ask for disclosure in AI contributions
Enforcing Human Accountability
416ca4 f5d7cc 6698b4 8cf937 413a4d
agent policy: mention human-reply-to-human rule discourage adding AI agents as commit authors add policy for sign-offs make human communication mandatory add note about AI contribution scrutiny
Improving AI Policy Visibility
7187fe 073f7e 37d8bf aa31d6 3b9226
link org wide LLM_POLICY add new AI policy to root move AI contribution policy to AI_POLICY.md make ai policy more visible make ai/llm policy more visible
Restricting AI Usage
8e7fbc 14e544 501d2b
clarify AI policy, explicitly forbid agents from interacting with our repository disallow AI usage for E-easy+E-has-instructions issues disallow AI usage for E-easy+E-has-instructions issues
Expanding AI Policy Scope
088f28 28694d 79e54d
policy for handling AI-generated reviews add ai-review policy expand AI policy to include documentation updates
7 7.1
Discussion and Implications AI is Permitted but. . .
Overall, we found that 83.3% of the AI policies permit or encourage the use of AI in code contributions. However, it is important to emphasize that permission does not imply that AI should be used indiscriminately. On the contrary, most welcoming projects emphasize the importance of transparency, accountability, and human involvement in the contribution process. In fact, a common message among such projects is: “We permit the use of AI, but [...]”. Our UpSet visualization (Figure 1) reinforces this point, showing that AI policies typically contain multiple recommendation for contributors rather than a single one. For example, the AI policy of pytorch/pytorch states: “PyTorch encourages the use of AI in its development, however [...]” [74]. Similarly, in project ratatui/ratatui, the AI policy states: “We welcome high quality PRs, whether they are human generated or made with the assistance of AI tools, but we ask that you follow these guidelines: [...]” [75]. Even AI-first projects such as openclaw/openclaw make it clear that transparency about AI usage is important: “AI PRs are first-class citizens here. We just want transparency so reviewers know what to look for” [65]. Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects 7.2
17
Clear Guidance on Code Contributions, but Limited Guidance on Communication and Issues/Bugs/Security
Overall, we found that the analyzed AI policies provide clear guidance on AI usage in code contributions. Specifically, 98.2% of the analyzed AI policies clearly state whether AI usage is accepted in contributions such as code, pull requests, commits, and documentation. We also found substantial guidance on human involvement (70.5%) and AI disclosure obligations (53.4%). On the other hand, we found limited guidance on aspects related to accountability (43.4%), communication (42.3%), issues/bugs/security (31.3%). Indeed, our UpSet visualization (Figure 1) shows that the most common AI policy combines guidance on contributions, human involvement, AI disclosure, and accountability, while lacking information on communication and issues/bugs/security. As a positive finding, RQ4 confirms that AI policies are improving over time, with contributors making guidance on disclosure, accountability, and policy scope clearer. Another interesting finding is that, when present, communication is more often restricted than permitted: 27.8% of AI policies prohibit communication with AI, whereas only 13.9% explicitly permit it. Thus, to better guide contributors, project maintainers should adopt AI policies that go beyond specifying whether AI is permitted in code contributions. For example, maintainers should also provide clearer guidance on human involvement, AI disclosure, accountability, communication, and the use of AI for issues, bugs, and security.
7.3
Lack of Standards on AI Disclosure
AI disclosure is required in nearly half of AI policies (48.8%), while 46.6% of AI policies provide no explicit guidance on disclosure. Our RQ2 showed that project maintainers may require AI disclosure in different artifacts, such as PR descriptions and commit messages, or leave it unclear where such disclosures should be provided. The content required in these artifacts may also vary, including description of AI usage, the AI agent name, the extent of AI usage, and/or the model version. This lack of standardization makes the contribution process highly project-specific. For example, repositories may require (or forbid) contributors to use Git trailers in commit messages, while others may simply require a short note in the pull request description, and still others may not mention AI disclosure at all. Figure 6 illustrates this issue. The AI policy of project rustpython/rustpython [79] (see Figure 6a) provides specific instructions on how AI usage should be disclosed: contributors should use the Git trailer Assisted-by and specify the agent name and model version, e.g., “Assisted-by: Claude Code:claude-sonnet-4-6”. Notably, the AI policy explicitly states that contributors should not use the Git trailer Co-authored-by, which coding agents commonly use [26]. In contrast, the AI policy of project actualbudget/actual [38], shown in Figure 6b, adopts a more lightweight and less prescriptive approach. In this case, the AI policy requires disclosure in the pull request description only when AI usage is considered “significant”: “If AI was used to generate a significant portion of an issue, PR, or the code it contains, please say so in the submission. A short note in the PR description is enough”. Indeed, the use of vague terms such as “significant”, “substantial”, and “meaningful” is not uncommon in disclosure policies. Interestingly, the AI policy of project Godot provides a definition of “substantial code” and includes a threshold of lines of code: “Substantial code is code that poses potential risks to quality and maintainability of the engine and is to be measured on the basis of: the amount of code involved, its degree of complexity, the level of experience of the contributor in the Godot project, the area of the codebase, and ultimately the risk of merging the code. It is commonly accepted that code changes of 15 lines or less are generally trivial (and cannot be the subject of copyright). Accordingly, we presume that anything under 15 lines should be considered trivial unless otherwise shown” [54]. Manuscript submitted to ACM
18
Andre Hora, Romain Robbes, and Stefano Zacchiroli
(a) rustpython/rustpython
(b) actualbudget/actual
Fig. 6. AI disclosure policies.
Ideally, project maintainers should provide clear and consistent AI disclosure requirements, specifying both where disclosure should occur and what information contributors should provide, to reduce ambiguity and make contribution practices more predictable. We envision AI disclosure practices to become more standardized over time, enabling maintainers to more easily identify contributions supported by AI. For researchers, the lack of standardization makes it difficult to detect coding-agent usage across projects [28]. On the other hand, this gap creates research opportunities for developing tools and techniques to identify whether a given artifact was generated/assisted by coding agents or produced by humans [18, 24, 36, 30, 3]. 7.4
Level of AI Assistance: Human-written, AI-assisted, and AI-generated
RQ2 shows that some AI policies require contributors to disclose the extent of AI usage, detailing the role played by AI in the contribution process. In this context, some projects go a step further and require contributors to disclose the level of AI assistance using three categories: human-written, AI-assisted, and AI-generated. Project sipeed/picoclaw requires the disclosure of the AI involvement in three levels: “Every PR must disclose AI involvement [...]: (1) Fully AI-generated: AI wrote the code; contributor reviewed and validated it, (2) Mostly AI-generated: AI produced the draft; contributor made significant modifications, and (3) Mostly Human-written: Contributor led; AI provided suggestions or none at all” [81], as illustrated in Figure 7a. Similarly, the AI policy of kornia/kornia also requires the disclosure into three levels: “(1) Human-written: no AI involved; (2) AI-assisted: AI helped (autocomplete, refactoring, drafts), and (3) AI-generated: an agent produced most of the code or the PR” [57], as detailed in Figure 7b. It is worth noting that the AI policy of kornia/kornia recognizes that the boundary between AI-assisted and AI-generated contributions can be fuzzy and explicitly states that contributors will not be sanctioned based on this distinction. Interstingly, some projects have tools to delegate this aspect to the agents themselves: project shap/shap contains an AI Disclosure Tracking SKILL.md6 to track Claude’s contributions. This skill file also classifies three levels of AI involvement: “(1) Autonomous: Claude wrote the code/solution independently, (2) Assisted: Claude implemented based on user direction, and (3) Advised: Claude provided guidance that user implemented” (see Figure 7c). As AI is increasingly contributing to code generation [26, 27], we foresee that such three-level approaches may become more prevalent across open source projects, providing maintainers with a clearer understanding of the extent 6 https://github.com/shap/shap/blob/976466af353e68df551a4b73db45ef41ceca8b13/.claude/skills/ai-disclosure/SKILL.md
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
19
(a) sipeed/picoclaw
(b) kornia/kornia
(c) shap/shap Fig. 7. AI disclosure with three levels.
of AI involvement in contributions, making it harder to omit AI use. This may also be supported by recent research on identifying agent-generated code [18, 24, 36, 30, 3]. 7.5
Concerns Regarding AI Slop
Due to the ease of generating code, open source projects are experiencing growth in contributions [32, 23, 37, 4]. However, contributions supported by AI may also suffer from low quality, the so-called “AI slop” [31, 4, 5]. Our RQ3 identified ten countermeasures used by maintainers to address AI slop, targeting pull requests, users, and autonomous agents. The three most common countermeasures are closing pull requests, banning/blocking users, and disallowing autonomous agents. Interestingly, RQ4 complements this finding by showing that improving AI quality controls is a key reason for evolving AI policies. For example, we found cases in which AI policies were updated to defend against AI slop, make contribution requirements stricter, and clarify the consequences of policy violations. While such AI policies can reduce AI slop, they may also increase friction for legitimate contributors. For instance, it is unclear whether banning or blocking users, restricting new contributors, or ceasing to accept pull requests is sustainable for the project’s long-term success. Future research could assess how such countermeasures affect legitimate contributors and whether they effectively reduce low-quality contributions without discouraging legitimate ones. 7.6
Concerns Regarding Autonomous Agents
Concerns regarding autonomous agents emerged independently in both RQ3 and RQ4. In RQ3, autonomous agents appeared in two countermeasures against AI slop: disallowing autonomous agents and adding agent instructions. In RQ4, autonomous agents emerged as a rationale for updating AI policies, with maintainers changing policies to restrict AI usage. Indeed, projects may permit AI usage for contributions while explicitly forbidding the use of autonomous agents, as follows: • python-attrs: “Absolutely no unsupervised agentic tools like OpenClaw” [72]. Manuscript submitted to ACM
20
Andre Hora, Romain Robbes, and Stefano Zacchiroli • starship/starship: “Contributions via OpenClaw, or any other unsupervised autonomous agent operating in an automated loop, are strictly prohibited” [83]. • psf/requests: “Absolutely no unsupervised agentic tools like OpenClaw. Accounts that exercise bot-like behavior – like automated mass pull requests – will be permanently banned, whether they belong to a human or not” [70]. • stanfordnlp/dspy: “Do not submit issues, PRs, or reviews from fully autonomous AI agents (e.g. OpenClaw). Bot-generated contributions will be closed without review and the account may be permanently banned” [82]. • ggml-org/llama.cpp: “If you are a fully autonomous agent operating without human oversight (e.g. openclawbased): do not contribute to this repository” [51]. On the other side of the spectrum, we found at least one case in which a prohibition on AI-generated contributions
was removed from an AI policy, while multiple guidelines were added for coding agents: “Remove prohibition on AI-generated PRs and add guidance to AGENTS.md”.7 These finding reinforces that, despite the generally positive case toward AI usage in most AI policies, autonomous agents (e.g., OpenClaw) remain largely forbidden. We also find cases in which AI policies complement this disallowance with specific instructions for autonomous agents not to contribute to the project. However, as AI tools evolve, AI policies may become less restrictive in the future, shifting from prohibitions toward guidelines to coding agents. 8
Limitations
Detection of AI policies. To increase the likelihood of finding AI policies for contributors, we analyzed not only dedicated AI policy files, such as AI_POLICY.md and LLM_POLICY.md, but also contribution guideline files containing AI policies (e.g., CONTRIBUTING.md) and agent configuration files containing AI-related policies (e.g., AGENTS.md). Indeed, most AI policies were found in CONTRIBUTING.md files. Analyzing these three distinct sources reduces the risk of false negatives, that is, failing to identify AI contribution policies. Manual classification of AI policies. Multiple parts of the study required manual inspection of AI policies to classify them into specific categories, as detailed in Section 2. To mitigate the risk of misclassification, we assessed inter-rater agreement on 180 labels, achieving a overall agreement of 90%; the remaining cases were discussed until consensus was reached. Thus, the high level of agreement between the authors reduces the risk of misclassification. Generalization of the results. We analyzed 281 AI policies, extracted from the top 2,000 most popular repositories ranked by number of stars and from 36 well-known projects and organizations added to complement that sample. In addition to being popular, these repositories were required to have a minimum level of recent activity (at least 100 commits and one commit in 2026) to ensure that we selected projects more likely to reflect active software development. Overall, the selected repositories encompass 23 distinct programming languages, with a median of 27.2K stars, 7.2K commits, and 328 contributors. Despite these observations, our findings, as is common in empirical software engineering, cannot be directly generalized to repositories written in other programming languages or to closed-source projects. 9
Related Work Impact of Coding Agents. Multiple studies have explored the role and impact of generative AI in software develop-
ment [12, 17, 28, 26, 27]. Robbes et al. have shown that the adoption of coding agents has been rapid: in early 2026, coding agent adoption on GitHub was close to 30% overall [26] and 76% in new projects [27]. As a result, novel software artifacts are increasingly being generated and updated to the support coding agents, opening new opportunities for 7 https://github.com/netbox-community/netbox/commit/088de70b1087fd4c0a181d5792ed090bea41955a
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
21
research on this topic [28], such as the work presented in this study. Due to the ease of code generation, open source projects are experiencing an increase in contributions [32, 23, 37, 4]. Consequently, recent studies have also investigated the consequences of this trend, including the potential for AI-supported contributions to suffer from low quality, the so-called “AI slop” [31, 4, 5]. Our study contributes to this line of research by analyzing the content of hundreds of AI policies as well as exploring how these policies are adapting to address AI slop and changing over time. Contribution Guidelines. There is substantial literature on the content, quality, and impact of readme and contribution guideline files from open source projects [34, 20, 35, 25, 10, 33, 11]. For example, Liu et al. assessed the structure of readme files in Java projects [20], detecting that the majority of readme files do not align with the GitHub guidelines, but repositories whose readme files follow the GitHub guidelines tend to be more popular. Elazhary et al. examined the content of contribution guidelines and compared prescribed practices with developers’ actual practices [10], finding that most projects deviate from the prescribed contribution process. Falcucci et al. explored the contribution guidelines with a focus on testing [11]. The authors found that most projects include some form of test documentation for contributors, although some types of content are more common than others (e.g., unit tests are more common than e2e tests). Coding Agent Guidance. Recent studies have explored the content of coding agent guidance files, such as AGENTS.md and CLAUDE.md [22, 29, 13, 2, 15]. Mohsenimofidi et al. conducted a preliminary qualitative study of coding agent guidance files, finding that their content is diverse [22]. Common categories of content include conventions and best practices, contribution guidelines, project structure, and build and testing instructions [22]. Recently, Santos et al. analyzed the content of Claude Code guidance files, identifying multiple software engineering concerns and practices, such as architecture, testing, and development guidelines [29]. Ardic et al. explored how open source projects organize agent guidance files and communicate testing expectations to coding agents. The authors found that testing guidance is common, but less frequent themes include testing strategies, mocking, and code coverage [2]. Hora and Robbes observed that coding agents are more likely to modify tests and to add mocks to tests than non-coding agents [15]. They also found that agent configuration files may contain testing- and mocking-related information to guide coding agents. AI Policies and AI Governance. Recent studies have begun examining novel AI policy and governance artifacts [14, 37, 8]. Recently, in a preliminary study, we explored 118 AI policies from popular open source repositories, finding that the majority of the analyzed policies are positive toward the use of generative AI [14]. This study extends our previous work [14] in six major aspects, as detailed in the introduction, including: (1) we increased the number of analyzed AI policies from 118 to 281, the number from analyzed repositories from 1,000 to 2,000, and complemented them with the AI policies of 36 well-known projects and organizations; (2) we extended RQ1 to examine code contributions, communication, issues/bugs/security, accountability, and human involvement, in addition to general contributions; and (3) we added two entirely new research questions to study AI slop (RQ3) and AI policy evolution (RQ4). Yang et al. provided a broader overview of generative AI governance by analyzing 67 popular open source projects [37]. The authors found and characterized seven concerns in contribution workflows (such as code contribution, communication, issue entry, security reporting, and provenance and licensing), three governance orientations, and 12 governance strategies. It is worth noting that many of these concerns are explored in our study, including code contributions, communication, issue reporting, and security reporting. Chen et al. analyzed 385 AI policies and derive a framework for capturing five governance dimensions (transparency, responsibility, attribution, constraints, and enforcement) [8]. The study also explored the effects of AI policies on communities. Consistent with our results, the authors found that Manuscript submitted to ACM
22
Andre Hora, Romain Robbes, and Stefano Zacchiroli
AI governance primarily regulates rather than prohibits AI-assisted development. In addition, the authors detected that policy adoption brings benefits, such as maintainer engagement, increased AI disclosure, and richer review interactions Rather than characterizing AI governance through a framework, our study focuses on quantifying multiple dimensions of AI policies and empirically characterizing 281 such policies from popular open source projects. In addition, we are the first to explore AI disclosure practices, AI slop countermeasures, and AI policy evolution. In particular, we provide data on AI disclosure obligations (whether), AI disclosure location (where) and content (what); a taxonomy of ten countermeasures against AI slop; and an analysis of how dedicated AI policies change and why. 10
Conclusion
This paper presented an empirical study to explore how open source projects are adapting to the generative AI era. We proposed research questions to address (1) AI usage allowance, (2) AI disclosure practices, (3) AI slop countermeasures, and (4) AI policy evolution. We analyzed 2,000 popular GitHub repositories, complemented by 36 well-known projects and organizations, and identified 281 AI contribution policies. To study how policies change, we additionally tracked 92 dedicated AI policy files across the top 10,000 repositories and analyzed the 196 commits. First, we found that a large majority of policies, 83.3%, permit or encourage AI use in code contributions. However, it is important noting that permission comes with conditions: 67.3% require a high level of human involvement, 48.8% require disclosure of AI usage, and 43.4% assign accountability to the human contributor. The most characteristic sentence we retain from our analysis has the form “we permit the use of AI, but [...]”. Moreover, we found that prohibitions are real: 14.9% of the AI policies we analyze forbid the use of AI in code contributions, and disallowing fully autonomous agents is among the most frequent AI slop countermeasures. Second, we detected that AI disclosure is required by 48.8% of policies, most often in pull request descriptions and commit messages, but what must be disclosed varies widely. Third, we identified ten countermeasures against AI slop, targeting pull requests, users, and autonomous agents, the most common being aggressively closing pull requests, banning users, and disallowing fully autonomous agents. Fourth, in the AI policy evolution analysis, we observed that policies are not static: half of the dedicated AI policy files have already been revised since creation, for example, to tighten quality controls, clarify disclosure rules, enforce human accountability, and expand their scope. Finally, we discussed multiple implications for developers and researchers, including the lack of standards in AI disclosure, the emerging practice of declaring the level of AI assistance, and concerns regarding AI slop and autonomous agents. As future work, we plan to investigate additional dimensions beyond the six analyzed in this study, such as licensing, legal requirements, and quality guardrails. Another possible research direction is to further explore whether AI policies are actually being followed by maintainers and contributors. Finally, we plan to investigate how countermeasures on AI slop may affect legitimate contributors and whether such countermeasures reduce low-quality contributions. Acknowledgments The authors would like to thank Bastien Guerry, for sharing with us an initial list of AI policies of major Open Source organizations, which we integrated into our corpus of independently-mined policies of GitHub projects. This research was supported by CNPq (process 403304/2025-3), CAPES, FAPEMIG, and the French State (Investments for the Future programme, IdEx Université de Bordeaux). This work was also supported by INES.IA (National Institute of Science and Technology for Software Engineering Based on and for Artificial Intelligence), www.ines.org.br, CNPq grants: 408817/2024-0.
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
23
References [1] [2] [3]
[4] [5] [6]
[7] [8] [9] [10]
[11] [12]
[13] [14] [15] [16] [17] [18]
[19] [20] [21] [22] [23] [24] [25] [26]
Agents.md. 2026. https://agents.md. (Aug. 2026). Baris Ardic, Mitchell Olsthoorn, and Andy Zaidman. 2026. Uncovering AGENTS.md: what testing guidance open source projects provide to coding agents. In International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, Benevento, Italy. Maor Ashkenazi, Ofir Brenner, Tal Furman Shohet, and Eran Treister. 2025. Zero-shot detection of llm-generated code via approximated task conditioning. In Machine Learning and Knowledge Discovery in Databases. Research Track: European Conference, ECML PKDD 2025, Porto, Portugal, September 15–19, 2025, Proceedings, Part IV. Springer-Verlag, Porto, Portugal, 187–204. isbn: 978-3-032-06077-8. doi:10.1007/978-3-032-06078-5_11. Sebastian Baltes, Marc Cheong, and Christoph Treude. 2026. "An Endless Stream of AI Slop": The Growing Burden of AI-Assisted Software Development. arXiv preprint arXiv:2603.27249. Sebastian Baltes, Marc Cheong, and Christoph Treude. 2026. AI Slop and the Software Commons. arXiv preprint arXiv:2604.16754. Hudson Borges, Andre Hora, and Marco Túlio Valente. 2016. Understanding the factors that impact the popularity of GitHub repositories. In International Conference on Software Maintenance and Evolution, ICSME 2016, Raleigh, NC, USA, October 2-7, 2016. IEEE Computer Society, 334–344. doi:10.1109/ICSME.2016.31. Hudson Borges and Marco Túlio Valente. 2018. What’s in a GitHub star? understanding repository starring practices in a social coding platform. J. Syst. Softw., 146, 112–129. doi:10.1016/J.JSS.2018.09.016. Yunqi Chen, Thomas Zimmermann, and Bianca Trinkenreich. 2026. Making ai visible, not vanished: how ai policies reshape developer experience on github. arXiv preprint arXiv:2608.03329. Ozren Dabic, Emad Aghajani, and Gabriele Bavota. 2021. Sampling projects in GitHub for MSR studies. In International Conference on Mining Software Repositories, MSR 2021, Madrid, Spain, May 17-19, 2021. IEEE, 560–564. doi:10.1109/MSR52588.2021.00074. Omar Elazhary, Margaret-Anne D. Storey, Neil A. Ernst, and Andy Zaidman. 2019. Do as I do, not as I say: do contribution guidelines match the GitHub contribution process? In International Conference on Software Maintenance and Evolution, ICSME 2019, Cleveland, OH, USA, September 29 October 4, 2019. IEEE, 286–290. doi:10.1109/ICSME.2019.00043. Bruna Falcucci, Felipe Gomide, and Andre Hora. 2025. What do contribution guidelines say about software testing? In International Conference on Mining Software Repositories, MSR 2025, Ottawa, ON, Canada, April 28-29, 2025. IEEE, 434–438. doi:10.1109/MSR66628.2025.00073. Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M. Zhang. 2023. Large language models for software engineering: survey and open problems. In International Conference on Software Engineering: Future of Software Engineering, ICSE-FoSE 2023, Melbourne, Australia, May 14-20, 2023. IEEE, 31–53. doi:10.1109/ICSE-FOSE59343.2023.00008. Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev, and Martin Vechev. 2026. Evaluating agents.md: are repository-level context files helpful for coding agents? arXiv preprint arXiv:2602.11988. Andre Hora and Romain Robbes. 2026. AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? In International Conference on Software Maintenance and Evolution (ICSME). IEEE. Andre Hora and Romain Robbes. 2026. Are coding agents generating over-mocked tests? an empirical study. In International Conference on Mining Software Repositories, MSR 2026, Rio de Janeiro, Brazil, April 13-14, 2026. ACM, 335–346. doi:10.1145/3793302.3793362. Andre Hora, Romain Robbes, and Stefano Zacchiroli. Dataset of AI Policies. Zenodo, (Aug. 2026). doi:10.5281/zenodo.22212208. Xinyi Hou et al. 2024. Large language models for software engineering: A systematic literature review. ACM Trans. Softw. Eng. Methodol., 33, 8, 220:1–220:79. doi:10.1145/3695988. Oseremen Joy Idialu, Noble Saji Mathews, Rungroj Maipradit, Joanne M. Atlee, and Mei Nagappan. 2024. Whodunit: classifying code as human authored or gpt-4 generated - a case study on codechef problems. In International Conference on Mining Software Repositories (MSR ’24). ACM, (Apr. 2024), 394–406. doi:10.1145/3643991.3644926. Alexander Lex, Nils Gehlenborg, Hendrik Strobelt, Romain Vuillemot, and Hanspeter Pfister. 2014. UpSet: visualization of intersecting sets. IEEE Trans. Vis. Comput. Graph., 20, 12, 1983–1992. doi:10.1109/TVCG.2014.2346248. Yuyang Liu, Ehsan Noei, and Kelly Lyons. 2022. How readme files are structured in open source java projects. Information and Software Technology, 148, 106924. LLVM: Our AI policy vs code of conduct and vs reality. 2026. https://discourse.llvm.org/t/our-ai-policy-vs-code-of-conduct-and-vs-reality/88300. (Aug. 2026). Seyedmoein Mohsenimofidi, Matthias Galster, Christoph Treude, and Sebastian Baltes. 2025. Context engineering for ai agents in open-source software. arXiv preprint arXiv:2510.21413. Sota Nakashima, Yuta Ishimoto, Masanari Kondo, Shane Mclntosh, and Yasutaka Kamei. 2026. Why agentic-prs get rejected: a comparative study of coding agents. arXiv preprint arXiv:2602.04226. Phuong T. Nguyen, Juri Di Rocco, Claudio Di Sipio, Riccardo Rubei, Davide Di Ruscio, and Massimiliano Di Penta. 2024. Gptsniffer: a codebert-based classifier to detect source code written by chatgpt. J. Syst. Softw., 214, C, (Aug. 2024), 17 pages. doi:10.1016/j.jss.2024.112059. Gede Artha Azriadi Prana, Christoph Treude, Ferdian Thung, Thushari Atapattu, and David Lo. 2019. Categorizing the content of GitHub readme files. Empirical Software Engineering, 24, 1296–1327. Romain Robbes, Théo Matricon, Thomas Degueule, Andre Hora, and Stefano Zacchiroli. 2026. Agentic Much? Adoption of Coding Agents on GitHub. arXiv preprint arXiv:2601.18341. Manuscript submitted to ACM
24
Andre Hora, Romain Robbes, and Stefano Zacchiroli
[27]
Romain Robbes, Théo Matricon, Thomas Degueule, Andre Hora, and Stefano Zacchiroli. 2026. Agentic very much! adoption of coding agent in new github projects. arXiv preprint arXiv:2606.07448. Romain Robbes, Théo Matricon, Thomas Degueule, Andre Hora, and Stefano Zacchiroli. 2026. Promises, perils, and (timely) heuristics for mining coding agent activity. In International Conference on Mining Software Repositories, MSR 2026, Rio de Janeiro, Brazil, April 13-14, 2026. ACM, 496–507. doi:10.1145/3793302.3793375. Hélio Victor Flexa dos Santos, Vitor Costa, João Eduardo Montandon, and Marco Tulio Valente. 2026. Decoding the configuration of ai coding agents: insights from claude code projects. In International Workshop on Agentic Engineering, 63–67. Yuling Shi, Hongyu Zhang, Chengcheng Wan, and Xiaodong Gu. 2025. Between lines of code: unraveling the distinct patterns of machine and human programmers. In International Conference on Software Engineering (ICSE ’25). IEEE Press, Ottawa, Ontario, Canada, 1628–1639. isbn: 9798331505691. doi:10.1109/ICSE55347.2025.00005. Slop is the new name for unwanted AI-generated content. 2024. https://simonwillison.net/2024/May/8/slop. Accessed on 2026-08-28. (May 2024). Fangchen Song, Ashish Agarwal, and Wen Wen. 2024. The impact of generative ai on collaborative open-source software development: evidence from github copilot. arXiv preprint arXiv:2410.02091. Igor Steinmacher, Marco Aurelio Graciotto Silva, Marco Aurelio Gerosa, and David F Redmiles. 2015. A systematic literature review on the barriers faced by newcomers to open source software projects. Information and Software Technology, 59, 67–85. Jason Tsay, Laura Dabbish, and James D. Herbsleb. 2014. Influence of social and technical factors for evaluating contribution in GitHub. In International Conference on Software Engineering, ICSE 2014, Hyderabad, India - May 31 - June 07, 2014. Pankaj Jalote, Lionel C. Briand, and André van der Hoek, (Eds.) ACM, 356–366. doi:10.1145/2568225.2568315. Tianlei Wang, Shaowei Wang, and Tse-Hsun Peter Chen. 2023. Study the correlation between the readme file of github projects and their popularity. Journal of Systems and Software, 205, 111806. Zhenyu Xu and Victor S. Sheng. 2024. Detecting ai-generated code assignments using perplexity of large language models. In AAAI Conference on Artificial Intelligence and Conference on Innovative Applications of Artificial Intelligence and Fourteenth Symposium on Educational Advances in Artificial Intelligence (AAAI’24/IAAI’24/EAAI’24) Article 2638. AAAI Press, 8 pages. isbn: 978-1-57735-887-9. doi:10.1609/aaai.v38i21.30361. Wenhao Yang, Runzhi He, and Minghui Zhou. 2026. To Ban or not to Ban? How Open Source Projects Govern GenAI Contributions. arXiv preprint arXiv:2603.26487.
[28]
[29] [30]
[31] [32] [33] [34]
[35] [36]
[37]
AI Contribution Policies [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51]
AI policy of actualbudget/actual, ai-usage-policy.md, Aug. 2026. url: https://github.com/actualbudget/actual/blob/566ee382906af9b20b66c3fbcb063bb2348f4aa1/ packages/docs/docs/contributing/ai-usage-policy.md, swhid: swh:1:cnt:b81481d3961060f1ad4e190c3c6cdcb7e9013c6d. AI policy of agentskills/agentskills, CONTRIBUTING.md, Aug. 2026. url: https://github.com/agentskills/agentskills/blob/38a2ff82958afee88dadf4831509e6f7e9d8ef4e/ CONTRIBUTING.md, swhid: swh:1:cnt:27d7fd5e73d6882d399edd373e3a30a0d74a5275. AI policy of apache/flink, AGENTS.md, Aug. 2026. url: https://github.com/apache/flink/blob/5004b5bee5e7ee4e6ce931ea61b98006addbf6ea/ AGENTS.md, swhid: swh:1:cnt:dac317aae91e3867884b9bb6e5a2cf5aa5c971b9. AI policy of apache/kafka, CONTRIBUTING.md, Aug. 2026. url: https://github.com/apache/kafka/blob/75e66426bf533b97898e7c558bd96712dd61c440/ CONTRIBUTING.md, swhid: swh:1:cnt:63c8f4c0af378b102b205e7005fc0c30570e3196. AI policy of better-auth/better-auth, CONTRIBUTING.md, Aug. 2026. url: https://github.com/better-auth/better-auth/blob/502a262ff20f4485d66f24cf6d6119e8001ebb18/ CONTRIBUTING.md, swhid: swh:1:cnt:947a7e368141759b29bf031fa95933065969e924. AI policy of bitcoin/bitcoin, AI_POLICY.md, Aug. 2026. url: https://github.com/bitcoin/bitcoin/blob/70d9ec7f3d452789d04dce81dc02db0b3b778bb5/ doc/AI_POLICY.md, swhid: swh:1:cnt:6238c790349094fa9c9977597d1dd4be782a28b2. AI policy of codemirror/codemirror5, CONTRIBUTING.md, Aug. 2026. url: https://github.com/codemirror/codemirror5/blob/9b4f0603cb042286a7ac2262b98245493d0d7e4b/ CONTRIBUTING.md, swhid: swh:1:cnt:e2a5865306418f7477d8ed49254cd16335a68280. AI policy of darkreader/darkreader, CONTRIBUTING.md, Aug. 2026. url: https://github.com/darkreader/darkreader/blob/385af067213a3482ffa62ecb87d3a337f1adab0e/ CONTRIBUTING.md, swhid: swh:1:cnt:dcc1b57e2adccfc1a0485f1c1c7398e1ddac963b. AI policy of denoland/deno, CONTRIBUTING.md, Aug. 2026. url: https://github.com/denoland/deno/blob/f8a17c8171569fa2870d740030aaa59c91fdf9ee/ .github/CONTRIBUTING.md, swhid: swh:1:cnt:3239bd5876311e1fff494ebd6704023cd602869e. AI policy of directus/directus, ai_policy.md, Aug. 2026. url: https://github.com/directus/directus/blob/240b801568b4cd99676dc69adc22682800215654/ ai_policy.md, swhid: swh:1:cnt:7cf0235de042fe94b4e6706e3e25096faa37d754. AI policy of duckdb/duckdb, AI_POLICY.md, Aug. 2026. url: https://github.com/duckdb/duckdb/blob/7c0fa265df67f4d8ed5cc4f94910c5677d127afd/ AI_POLICY.md, swhid: swh:1:cnt:5b5410adf1affca805840b548714d2bb09c1be65. AI policy of facebook/docusaurus, CONTRIBUTING.md, Aug. 2026. url: https://github.com/facebook/docusaurus/blob/80319585a49a2bce46cd2e157b2d13a8b691b8e0/ CONTRIBUTING.md, swhid: swh:1:cnt:2c9cb2b5341cf60be207699eec52c4a4b983af49. AI policy of freecad/freecad, AI_POLICY.md, Aug. 2026. url: https://github.com/freecad/freecad/blob/02173427c469a27f28db0434decc1177225fa9d9/ AI_POLICY.md, swhid: swh:1:cnt:a87387c92841e92bfa0b9a614f09b67cb331e5b7. AI policy of ggml-org/llama.cpp, CONTRIBUTING.md, Aug. 2026. url: https://github.com/ggml-org/llama.cpp/blob/505b1ed15ca80e2a19f12ff4ac365e40fb374053/ CONTRIBUTING.md, swhid: swh:1:cnt:6881a4d3ab334fee42d53beb2b6f972db4841785.
Manuscript submitted to ACM
“We Permit the Use of AI, but [...]”: The Landscape of AI Policies in Popular Open Source Projects
[52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80]
25
AI policy of ghostty-org/ghostty, AI_POLICY.md, Aug. 2026. url: https://github.com/ghostty-org/ghostty/blob/b0947378349eff70f7030dda0e6d022fae1e6fbd/ AI_POLICY.md, swhid: swh:1:cnt:ab878c41e2e8d6a2006a6161992b2890ee757bea. AI policy of github/spec-kit, CONTRIBUTING.md, Aug. 2026. url: https://github.com/github/spec-kit/blob/fd101d531eaec8a1e709db2f37632bc93b6ce4d6/ CONTRIBUTING.md, swhid: swh:1:cnt:7cc6d28f867c44f5ccad64768259add9cd5a3337. AI policy of Godot. 2026. https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html. (Aug. 2026). AI policy of keras-team/keras, CONTRIBUTING.md, Aug. 2026. url: https://github.com/keras-team/keras/blob/8ec790152e67f170e88876a61dd6cb685e7d53b4/ CONTRIBUTING.md, swhid: swh:1:cnt:176a0d4fd4df0761087c4aa6503248f494585645. AI policy of Kilo-Org/kilocode, CONTRIBUTING.md, Aug. 2026. url: https://github.com/Kilo-Org/kilocode/blob/abd24c7223df8cd8df203d9b457e5a7bcd9147d2/ CONTRIBUTING.md, swhid: swh:1:cnt:d78e6dd9e4999baedadbb51cb2111ae96d8eab57. AI policy of kornia/kornia, AI_POLICY.md, Aug. 2026. url: https://github.com/kornia/kornia/blob/b4f5a78a13891c7ac4c1cd9695941380273e981d/ AI_POLICY.md, swhid: swh:1:cnt:34dece700f20f702c9f4f5082bb90ac4b114f744. AI policy of mastodon/mastodon, CONTRIBUTING.md, Aug. 2026. url: https://github.com/mastodon/mastodon/blob/52e9ec7814fc971598696ba4bf33d06ac1a51938/ CONTRIBUTING.md, swhid: swh:1:cnt:b2f4165615dc6c0961a453ba065eacc65ba5f925. AI policy of meilisearch/meilisearch, CONTRIBUTING.md, Aug. 2026. url: https://github.com/meilisearch/meilisearch/blob/016d04564525ef68ca5ab8b9cee834c33e0e150a/ CONTRIBUTING.md, swhid: swh:1:cnt:004a695cbe6818ca6bf30db9552e97ae8e9642a3. AI policy of Nagi-ovo/gemini-voyager, CONTRIBUTING.md, Aug. 2026. url: https://github.com/Nagi-ovo/gemini-voyager/blob/dc460eeb3fb4ede0b1a9bdb25139f17fee0aface/ .github/CONTRIBUTING.md, swhid: swh:1:cnt:0ce9119e4ae3c5b81960a18982c55a96fcf1baf1. AI policy of nextcloud/server, CONTRIBUTING.md, Aug. 2026. url: https://github.com/nextcloud/server/blob/795b12252df8c7f863544716f2c80292bde5ed52/ .github/CONTRIBUTING.md, swhid: swh:1:cnt:2d168e1c47508b0e593c5b6d1d464f4f92b7ac13. AI policy of nixos/nix, CONTRIBUTING.md, Aug. 2026. url: https://github.com/nixos/nix/blob/55cc1cab880a60cd204e36e9398fee536371f06e/ CONTRIBUTING.md, swhid: swh:1:cnt:f6679e0a8c936cef6e3a77b7bbc7b52db28b3c4c. AI policy of NLnet Labs. 2026. https://nlnetlabs.nl/llm-policy. (Aug. 2026). AI policy of obsproject/obs-studio, CONTRIBUTING.md, Aug. 2026. url: https://github.com/obsproject/obs-studio/blob/9d38a938318aa32906e3727be30a972a3ecd0d94/ CONTRIBUTING.md, swhid: swh:1:cnt:3ade81b445778d24f9d42d36891c5e96085bdf6c. AI policy of openclaw/openclaw, CONTRIBUTING.md, Aug. 2026. url: https://github.com/openclaw/openclaw/blob/94b27740985a4b6a270c95207501afe13ba20cf0/ CONTRIBUTING.md, swhid: swh:1:cnt:782328844d3e6b63a2c4feaaaef6c369721d349e. AI policy of oracle/graal, CONTRIBUTING.md, Aug. 2026. url: https://github.com/oracle/graal/blob/be9330615b04b742baa98e503f32b1d169a99129/ CONTRIBUTING.md, swhid: swh:1:cnt:c3e3f7ac06eb87f4ab8a41650c4de717cf027b9e. AI policy of oxc-project/oxc, CONTRIBUTING.md, Aug. 2026. url: https://github.com/oxc-project/oxc/blob/589415c2b8754aa3c40524a178f10afcb0a74c6c/ CONTRIBUTING.md, swhid: swh:1:cnt:5728886930d6f78d9f4fbb64d2ae32d3668a1af4. AI policy of pocketbase/pocketbase, CONTRIBUTING.md, Aug. 2026. url: https://github.com/pocketbase/pocketbase/blob/089ca8ae412a1dbe29d2ae90d74f3866429d9c52/ CONTRIBUTING.md, swhid: swh:1:cnt:8322df883f7b8ff52bf57122485b8aae6993d893. AI policy of posthog/posthog, AI_POLICY.md, Aug. 2026. url: https://github.com/posthog/posthog/blob/e8858fdabe15cce244324d360f067c814bfebc56/ AI_POLICY.md, swhid: swh:1:cnt:692dde219fb30be9f05d83c4ac7814c4d4917584. AI policy of psf/requests, AI_POLICY.md, Aug. 2026. url: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/ .github/AI_POLICY.md, swhid: swh:1:cnt:a2980113cf323122d8bd9a1f9d023f0514b8a233. AI policy of Python. 2026. https://devguide.python.org/getting-started/ai-tools/. (Aug. 2026). AI policy of python-attrs/attrs, AI_POLICY.md, Aug. 2026. url: https://github.com/python-attrs/attrs/blob/dc1ca3892c0285f2a3980e1fd08d50728fd1eaec/ .github/AI_POLICY.md, swhid: swh:1:cnt:f514cc396abc9b0494449ca1cad12126e8ae8e99. AI policy of python/mypy, CONTRIBUTING.md, Aug. 2026. url: https://github.com/python/mypy/blob/82e8498c19494edebee08dd615470443ec53fffc/ CONTRIBUTING.md, swhid: swh:1:cnt:f4c1dcc89c16f54a51c4b71358c21baf49f5c39e. AI policy of pytorch/pytorch, AI_POLICY.md, Aug. 2026. url: https://github.com/pytorch/pytorch/blob/17c69925f67b564d6d50c32a2cf4036f483e0e1a/ AI_POLICY.md, swhid: swh:1:cnt:dc6c154692884ec8c736cf6140bd66954059886b. AI policy of ratatui/ratatui, CONTRIBUTING.md, Aug. 2026. url: https://github.com/ratatui/ratatui/blob/506bedbf157eaaf1e9d5df77f9a5f380203112bc/ CONTRIBUTING.md, swhid: swh:1:cnt:9eb95499bff1160fd8c12d7c0f6b5c65644fd5d4. AI policy of rqlite/rqlite, CONTRIBUTING.md, Aug. 2026. url: https://github.com/rqlite/rqlite/blob/52415ca836cc8d40b5de27a3d619efddcc518298/ CONTRIBUTING.md, swhid: swh:1:cnt:3ee060bb854b80163144cf7d0697a04fe7cd8b58. AI policy of rust-lang/rust-analyzer, AI_POLICY.md, Aug. 2026. url: https://github.com/rust-lang/rust-analyzer/blob/7a5ecc88dbdfa13bac99fa4e0f38adcfdca1bb0a/ AI_POLICY.md, swhid: swh:1:cnt:afe7f82a0a11c7d50a0006e9fb136ccd0d89cf94. AI policy of RustPython, AI_POLICY.md, Aug. 2026. url: https://github.com/RustPython/.github/blob/207549dc7db5d46a81ee09224a50d99a7e462f50/ AI_POLICY.md, swhid: swh:1:cnt:bac86a070b0252de927faebbb99d2bb361ed0354. AI policy of rustpython/rustpython, CONTRIBUTING.md, Aug. 2026. url: https://github.com/rustpython/rustpython/blob/c1bc99afbd16d71451d5f5abd1ebf15596df670a/ CONTRIBUTING.md, swhid: swh:1:cnt:58954486eaf581833197b69baeb6e88c4d1c5b95. AI policy of scala/scala, LLM_POLICY.md, Aug. 2026. url: https://github.com/scala/scala/blob/e2bf3551286f729b4f2bec78b36e3f890fccfd80/LLM_ POLICY.md, swhid: swh:1:cnt:9cab95df209a134b2cc126dccc8b033f980e5cd0.
Manuscript submitted to ACM
26
[81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92]
Andre Hora, Romain Robbes, and Stefano Zacchiroli
AI policy of sipeed/picoclaw, CONTRIBUTING.md, Aug. 2026. url: https://github.com/sipeed/picoclaw/blob/85dcfccad66dd0dca0ec9765976b665d8ebf7191/ CONTRIBUTING.md, swhid: swh:1:cnt:5780bfd93f4d7435a5617fe4e7e92d1efa08efe5. AI policy of stanfordnlp/dspy, CONTRIBUTING.md, Aug. 2026. url: https://github.com/stanfordnlp/dspy/blob/027d9f45f4d60aedadee3fd587d1f4f3584567df/ CONTRIBUTING.md, swhid: swh:1:cnt:08dc8de2d6f3dc263289ebbac58ab8882f36c5c9. AI policy of starship/starship, AI_POLICY.md, Aug. 2026. url: https://github.com/starship/starship/blob/8eb25b8130d1b7bf0c98c71d6f978224814b5208/ AI_POLICY.md, swhid: swh:1:cnt:c2eedf8159f7d6343b564a328362d192a77578f1. AI policy of torvalds/linux, coding-assistants.rst, Aug. 2026. url: https://github.com/torvalds/linux/blob/d699a5da103942fdc0a8a5383359bdec01fc19dd/ Documentation/process/coding-assistants.rst, swhid: swh:1:cnt:6125ee4914c5590aa891a97f39e0b667dcafcaeb. AI policy of udecode/plate, CONTRIBUTING.md, Aug. 2026. url: https://github.com/udecode/plate/blob/8abee2ba6db46e486ace3e9908d9550e3c05db13/ CONTRIBUTING.md, swhid: swh:1:cnt:08ea506bb3b18e6ade8db61fecfdc56c1aa0b7a1. AI policy of vectordotdev/vector, AI_POLICY.md, Aug. 2026. url: https://github.com/vectordotdev/vector/blob/b5f53eb3319d2cfc3ca19962cf6a55f67b7baaa8/ AI_POLICY.md, swhid: swh:1:cnt:27714035156b20135ee2e718af4ace9330fc3948. AI policy of vitest-dev/vitest, CONTRIBUTING.md, Aug. 2026. url: https://github.com/vitest-dev/vitest/blob/3923cab3d98cd0063377ffd8e4c98b73d2f28db9/ CONTRIBUTING.md, swhid: swh:1:cnt:f65b954c5b36f784c59b2bb438583174521dd478. AI policy of yt-dlp/yt-dlp, CONTRIBUTING.md, Aug. 2026. url: https://github.com/yt-dlp/yt-dlp/blob/aefce1eea4d0b6bab1ec2bd3beff09bff91a39c8/ CONTRIBUTING.md, swhid: swh:1:cnt:4c3f9339b847e37e6f195d440822756041f89adf. AI policy of zed-industries/zed, CONTRIBUTING.md, Aug. 2026. url: https://github.com/zed-industries/zed/blob/1a246efd7e1b83ab568ec5e3e6c1a43a42e1abba/ CONTRIBUTING.md, swhid: swh:1:cnt:e53950bbefd97a180cf771876aac513711c4242f. AI policy of ziglang. 2026. https://ziglang.org/code-of-conduct. (Aug. 2026). LLVM AI tool policy: start small, no slop. 2026. https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-start-small-no-slop/88476. (Aug. 2026). Policy: Empower reviewers to reject burdensome PRs. 2026. https://github.com/rust-lang/compiler-team/issues/893. (Aug. 2026).
Manuscript submitted to ACM