Debian Won't Ban AI Code, Gentoo and NetBSD Already Did — The Open Source World Is Split on AI Contributions

[cto_michelle]

The open source community is experiencing one of its most significant philosophical schisms in recent memory, and it’s not about licensing models or governance structures — it’s about whether AI-generated code has any place in open source projects at all. The fault lines are deepening, and major projects are landing on opposite sides.

Gentoo and NetBSD: The Hard Line

Gentoo Linux drew the first major line in the sand by banning all AI tools from contributions. The reasoning is threefold: copyright uncertainty surrounding AI-generated output, quality concerns about code that hasn’t been deeply understood by a human contributor, and ethical objections to training data that may have been scraped from copyleft-licensed repositories without consent. The policy is unambiguous — contributors are prohibited from using AI code generators for any contribution to the project, and violations result in contribution rejection.

NetBSD went even further with a specifically legal framing. Their policy presumes all AI-generated code is “tainted” — legally uncertain for inclusion in a BSD-licensed project. Contributors must obtain prior written approval before submitting any AI-assisted contribution, and the burden of proof falls on the contributor to demonstrate the code is legally clean. This is an unusually aggressive stance for a project that historically favored permissive approaches.

LLVM and the Middle Path

The LLVM project chose a more pragmatic route: AI tool usage must be disclosed, but isn’t banned outright. Contributors using AI tools must take full responsibility for the output and verify it meets project coding standards, passes tests, and doesn’t introduce security vulnerabilities. It’s essentially a “use at your own risk with full transparency” approach, which acknowledges the reality that AI tools are already deeply embedded in many developers’ workflows.

Debian: Still Deciding

And then there’s Debian — one of the largest and most influential Linux distributions, the upstream source for Ubuntu and dozens of derivatives. Debian is still actively debating its AI contribution policy, and the internal discussion reflects the broader community split. Pragmatists argue that AI is just another productivity tool, no different in principle from autocomplete or code generation templates. Purists counter that AI code threatens the legal and philosophical foundations that make open source possible.

The Copyright Question at the Heart of Everything

Open source licenses — GPL, BSD, Apache, MIT — all operate on a fundamental assumption: human authorship with clear copyright ownership. A human writes code, holds copyright, and voluntarily licenses it under open source terms. The entire legal framework depends on this chain.

AI-generated code breaks that chain. The US Copyright Office has ruled that purely AI-generated works are not copyrightable. However, AI-assisted works — where a human makes substantial creative decisions using AI as a tool — may qualify for copyright protection. The boundary between “AI-generated” and “AI-assisted” is fuzzy at best.

This creates a cascade of unanswered legal questions. If AI-generated code isn’t copyrightable, can it carry a GPL license? If it can’t carry a license, can it legally be included in a licensed project? Does including unlicensed code in a GPL project “contaminate” the project’s licensing? Nobody has definitive answers, and the legal precedent is years away from being established. Conservative projects are banning AI code entirely because the downside risk of getting the legal question wrong is existential.

The Quality and Review Burden Problem

Beyond legality, the CNCF Security Slam 2026 opened specifically to address security concerns in open source projects, with the OpenSSF publishing best practices for handling AI-generated contributions. The concern isn’t just about whether AI code works — it’s about the review burden it creates. AI can generate large volumes of plausible-looking code that compiles, passes basic tests, and looks reasonable on first read. But verifying that code for subtle bugs, security vulnerabilities, and architectural fit requires significant human effort.

Projects with limited maintainer bandwidth — which is most open source projects — simply can’t afford the review cost of evaluating high-volume AI-generated contributions. The fear is that AI lowers the barrier to submitting code so dramatically that maintainers get buried under an avalanche of “good enough” contributions that each require deep review.

Our Company’s Approach

At my company, we allow AI-assisted development internally but require full human review before anything ships. For open source contributions, we follow each project’s stated policy — no exceptions. It’s the only responsible approach when the legal landscape is this uncertain.

What concerns me most is the emerging two-tier ecosystem. Projects that accept AI contributions will move faster and ship more features, but they’ll accumulate quality debt and legal risk. Projects that ban AI will maintain higher quality and legal clarity, but they’ll evolve more slowly and potentially lose contributors who’ve integrated AI deeply into their workflows.

The question for the community: should open source projects ban AI-generated contributions? And more fundamentally — is the copyright question even solvable within our current legal frameworks, or do we need new legislation specifically addressing AI-generated code in open source contexts?

[alex_dev]

I contribute to several open source projects and the inconsistency is already causing friction. I used Copilot while working on a bug fix for a Gentoo package and honestly couldn’t tell which lines were “mine” and which were AI-suggested — the autocomplete is so integrated into my workflow that the boundary is blurry. I ended up rewriting the entire fix from scratch to be safe. This is the practical problem with AI bans: they’re nearly impossible to enforce because AI assistance exists on a spectrum from “AI wrote the whole function” to “AI completed the variable name.”

Are we going to ban autocomplete? Where’s the line? IDE autocomplete has been suggesting code completions for decades — the difference with AI-powered completion is degree, not kind. When my IDE suggests closing a bracket, that’s fine. When it suggests a whole line based on context, that’s fine. When it suggests a whole function based on context… suddenly it’s banned? The boundary is arbitrary and unenforceable.

The LLVM disclosure approach is the most pragmatic, but it relies entirely on honest self-reporting, which is fundamentally unverifiable. There’s no tool that can reliably detect whether code was AI-generated or human-written. You can run stylometric analysis, but a competent developer who reviews and modifies AI output will produce code indistinguishable from hand-written code. So the enforcement mechanism is essentially the honor system.

I think the community needs to accept that AI tools are going to be part of most developers’ workflows whether we like it or not, and focus on what we can actually enforce: code quality standards, test coverage requirements, and thorough review processes. Judge the code, not how it was produced.

[priya_security]

The legal uncertainty creates a real supply chain risk for companies consuming open source, and I don’t think most engineering teams appreciate how serious this is.

Consider the scenario: a widely-used open source library includes AI-generated code in a release. That code, under current US Copyright Office guidance, may not be copyrightable. If it’s not copyrightable, the open source license attached to it may not be legally enforceable for those specific portions. Could a company then fork the AI-generated portions without complying with the original license terms? Could a competitor extract AI-generated functions from a GPL project and use them in proprietary software, arguing that unlicensed code can’t impose license obligations?

These aren’t hypothetical concerns — legal teams at enterprise companies are starting to audit their open source dependencies for AI provenance. The problem is that this is essentially impossible at scale. Most projects don’t track which contributions involved AI assistance, and even those with disclosure policies only capture contributions made after the policy was adopted. The retroactive risk is enormous.

From an enterprise security perspective, this is analogous to the Log4j situation but for legal risk instead of technical risk. A deeply embedded dependency with uncertain legal status could force costly relicensing or rewriting efforts.

We need a legal resolution — either a definitive court ruling or legislation — that clarifies the copyright status of AI-assisted code. The current ambiguity is untenable for enterprise open source consumption. Until we get that clarity, the conservative approach — treating all AI-generated code as legally uncertain — is the only responsible enterprise strategy, even if it slows down development.

[eng_director_luis]

The two-tier ecosystem concern Michelle raised is already emerging, and the dynamics are playing out exactly as I’d expect from studying technology adoption patterns.

I’ve been tracking a handful of comparable open source projects — pairs where one accepts AI contributions and one doesn’t. The pattern is consistent: the AI-accepting projects are shipping more features, closing more issues, and attracting more contributors. But their issue trackers also show more reports of regressions, subtle bugs that slip through review, and “drive-by” contributions where someone submits AI-generated code and disappears before the maintainers can ask follow-up questions.

The AI-banning projects are more stable, have fewer regressions, and their contribution quality is higher on average. But they’re evolving slower, their contributor counts are flat or declining, and they’re losing mindshare to faster-moving alternatives.

For enterprise adoption decisions, stability matters more than velocity — I’d rather depend on a slowly-evolving library that works reliably than a fast-moving one that introduces breaking changes. But market dynamics might not support this preference indefinitely. If the AI-accepting projects capture more users and more contributors, they accumulate more ecosystem gravity — more tutorials, more Stack Overflow answers, more integration support. The AI-banning projects might become niche regardless of their superior quality.

It’s the classic “worse is better” dynamic that has played out repeatedly in technology history, and it rarely favors the “better” side. VHS beat Betamax. JavaScript beat better-designed languages. The question is whether the open source community can find a middle path that captures AI’s productivity benefits without compromising the legal and quality foundations that make open source trustworthy. I’m not optimistic, but I’d love to be proven wrong.