Debian decides not to decide on AI-generated contributions

Original Article ↗ Hacker News Discussion ↗

Overall reaction to Debian’s “no decision”

  • Many see “not deciding” as reasonable given fast-changing tech and unclear impacts.
  • Others think strong anti-LLM policies are overdue, especially for critical infrastructure like distros, kernels, and compilers.
  • Several argue that focusing on “AI or not” is a distraction; projects should focus on whether contributions are good, safe, and maintainable.

Licensing, copyright, and ethics

  • One camp views LLMs as trained on uncompensated human work, making their outputs ethically tainted and potentially license-violating, especially for GPL/copyleft.
  • Others say all creative work is derivative, IP regimes are already broken, and public‑domain‑like AI output is legally usable once properly reviewed.
  • There is disagreement whether AI-generated code can be copyrighted or licensed; some point to US guidance that pure AI output is not copyrightable, raising complications for FOSS and proprietary projects alike.
  • Some fear future legal or financial obligations to rightsholders whose data trained closed models.

Code quality, review burden, and spam

  • Strong consensus that low-effort AI “slop” is a real problem: large, shallow PRs, hallucinated APIs, and unreadable abstractions.
  • Maintainers report being flooded with low-value PRs, similar to “Hacktoberfest on steroids.”
  • Critics note LLM output often looks superficially good, increasing review cost versus obviously-bad human code.
  • Pro-AI commenters counter that modern models can produce high-quality, often working code when driven by skilled developers, and that bad code predates AI.

Trust, responsibility, and reputation

  • Widely shared view: responsibility sits with the submitter. They must understand, defend, and maintain what they contribute, AI-assisted or not.
  • Several propose stronger reputation/onboarding systems: small patches first, “DKP-like” points, limits for new contributors, or blocking large PRs from unknowns.
  • Some argue “no AI” rules mostly punish honest, high-quality contributors, while bad actors will lie or churn new accounts.

Detection and enforcement

  • Many see labeling or banning AI-generated code as unenforceable without intrusive surveillance or unreliable detectors.
  • Others say rules still matter for intent: violating a “disclose AI use” policy becomes clear bad faith when detectable.

AI as tool vs. replacement; human value

  • One side: AI is just another tool (like autocomplete, linters). What matters is human understanding and intent.
  • Opposing view: viewing AI as a human replacement undermines human dignity and labor value; some tie this to broader capitalist exploitation.
  • Some push back on AI “inevitability” narratives, seeing them as hype to drive adoption and layoffs.

Accessibility and positive use cases

  • Multiple commenters with RSI or disabilities describe LLMs and speech+AI workflows as transformative, restoring or enhancing their ability to code and write.
  • Others accept these as compelling edge cases but maintain that mass low-effort AI use still harms maintainers and code quality.

Process and tooling proposals

  • Ideas include:
    • AI-assisted code review as a first filter, with trust scoring and automatic feedback/triage.
    • Limiting PR size or complexity for new contributors.
    • Requiring discussion/spec design before non-trivial PRs.
    • Explicit policies: contributors must be able to explain changes; “one-strike” ejection for unexplainable slop.
  • Cost and adversarial behavior are noted as major obstacles to AI-based review at scale.