Open Source Splits on AI Contributions: OpenJDK, GCC and COSMIC Restrict Them, Debian Allows Them, and the Linux Kernel Moves to Drop Its Tag

Background

Over the past several months, open-source projects that accept outside contributions have had to decide what to do about code written with large language models. The decisions have not converged. This analysis compares the rules several prominent projects have put in writing and the survey data that has appeared alongside them. Reported facts are set out first; the final section describes what the sources suggest the differences mean for developers.

The Machine Herald has covered several of these decisions individually, including Codeberg’s member vote on vibe-coded projects, Debian’s competing proposals, Oracle’s OpenJDK policy and systemd’s AGENTS.md canary. This piece sets the latest developments side by side.

Current situation

Projects that restrict AI-generated contributions

OpenJDK’s “Interim Policy on Generative AI,” dated 9 April 2026, states: “Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems,” according to OpenJDK. The policy lets contributors use such tools “privately” to help comprehend, debug and review code, so long as they do not contribute content generated by them. Its FAQ gives three reasons: reviewer burden, safety and security, and intellectual property. On intellectual property, the FAQ says the Oracle Contributor Agreement requires a contributor to own the rights in each contribution, and that most generative AI tools “are trained on copyrighted and licensed content, and their output can include content that infringes those copyrights and licenses.” The FAQ also answers a hybrid case directly: a contributor who generates 100 lines with a tool and edits ten of them may not contribute the result, because it “would still include, in part, AI-generated code.”

The GCC Steering Committee took a different legal route. According to Phoronix, the committee announced on 29 July 2026 that it had accepted the recommended policy of the GCC AI Policy Working Group, so that no “legally significant” code contributions made through AI or LLM tools will be accepted. Phoronix quotes the policy as saying that “the GCC maintainers are free to accept legally insignificant contributions generated by an LLM as long as they meet the usual prerequisites for any contribution and the contribution is clearly marked,” and as making an exception for “legally significant contributions to test cases, generated in whole or in part by an LLM.” Phoronix also reports that the GCC stakeholders plan to revisit the policy in early 2027.

In October, System76’s COSMIC desktop added a similar rule. According to The Register, contributors must declare: “I have not included any LLM (also known as AI) generated content in this PR, including code, comments, and descriptions.” The Register reports that the GNOME Calendar contributing guide says the project “does not allow contributions generated by large languages [sic] models (LLMs) and chatbots,” and that GNOME Extensions states that extensions “must not be AI-generated” while permitting AI learning aids and code completion.

Projects that permit it with conditions

Debian went the other way. The Debian vote page lists eight proposals on its ballot and names Option 5, “Responsible Use of Generative AI,” as the winner. The text of that option says Debian “neither endorses nor prohibits the use of generative AI tools,” and that “The use of a generative AI tool does not diminish the contributor’s responsibility for the work they submit.” It states that “Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian’s established development practices,” and that Debian encourages disclosure of AI assistance “but do not require them to do so.” The same option asks contributors planning broad actions such as mass bug filing to seek prior discussion and consensus, with a human overseeing any automated process. The ballot also contained Option 1, a proposal to forbid direct contributions written with LLM assistance through a Social Contract change.

The Register’s COSMIC report adds a one-line summary of the wider picture: “Debian decided to allow it, and of course, the kernel itself does too.”

The kernel and the attribution question

The Linux kernel currently asks that patches where AI tools contributed carry an “Assisted-by:” tag, according to Phoronix. Phoronix reported on 13 October 2026 that kernel developers are now looking at dropping that requirement “amid the rampant use of AI/LLMs,” that a patch removing the documentation was posted to the kernel mailing list, and that at the Linux Maintainers Summit in Prague there was reportedly consensus on deprecating it. The same report says views on the mailing list are mixed: some want the tag removed, while others “would like the clarity” of knowing whether AI helped with a patch.

This sits alongside GCC’s policy, under which the limited LLM contributions it accepts must be clearly marked, and Debian’s, which encourages but does not require disclosure.

What the survey data says

A Linux Foundation Research study published on 20 October 2026 provides figures on the volume problem these policies address. According to the Linux Foundation, 59% of maintainers report growing contribution volume since the rise of generative AI, rising to 69% among large projects, and 25% of incoming pull requests are estimated to be low-quality “AI slop,” a share that rises to 31% among large projects. The same release says only 35% of projects have a formal policy permitting generative AI use, while 32% have no policy and no plans for one. It also reports that 71% of maintainers agree generative AI reduces barriers to entry, that 53% disagree that it has improved community trust, and that disclosure of AI assistance “remains inconsistent.” The release names Red Hat as the study’s sponsor.

Implications

The following points are analysis drawn from the sources above, not reported facts.

Rules depend on the project, not on the tool. The same AI-assisted patch would be barred at OpenJDK, barred at GCC if legally significant, barred at COSMIC, and permitted at Debian, with the kernel described by The Register as allowing it too. A developer contributing to several projects with one agent-driven workflow therefore faces different obligations in each, including a pull-request declaration in COSMIC and clear marking of any accepted LLM contribution in GCC.

The stated justifications differ. OpenJDK’s FAQ names reviewer burden, security and intellectual property together; the GCC policy as reported by Phoronix turns on whether a contribution is legally significant; Debian’s winning text declines to resolve the legal questions and places responsibility on the contributor. The Linux Foundation data bears most directly on the reviewer-burden argument, since it measures the share of low-quality pull requests rather than legal risk.

Private use is carved out in the stricter projects. OpenJDK allows private use for comprehension, debugging and review, and COSMIC, as The Register describes it, still lets contributors learn from AI and find bugs with it. For developers, the practical boundary in these projects is therefore the submission, not the use of an assistant on one’s own machine.

Attribution is the least settled element. The kernel’s reported move away from the “Assisted-by:” tag, GCC’s marking requirement and Debian’s optional disclosure are three positions on one question. The Linux Foundation release lists standardized attribution practices among its recommendations, which the projects compared here have not yet adopted in a common form.

Detection is acknowledged to be hard. OpenJDK’s FAQ says that “reliably distinguishing human-generated content from AI-generated content is impossible” in general and asks reviewers to act on evidence they see. Declaration mechanisms such as COSMIC’s checkbox, and the Skara checkbox OpenJDK says it will add to pull requests, rely on contributors’ own statements.

What remains unclear

The sources do not say whether the kernel’s tag removal has been merged, only that consensus was reported at the Maintainers Summit. The GCC policy applies, in its own words as quoted by Phoronix, “For the time being,” with a review planned for early 2027, and Debian’s text says its position “may evolve as time passes.” The Linux Foundation figures are survey estimates, not measured counts of pull requests.