LLM-generated code must not be committed without prior written approval by core

Original Article ↗ Hacker News Discussion ↗

Scope and intent of the NetBSD guideline

  • The rule calls LLM-generated code “presumed tainted” and requires prior written approval from project core, explicitly naming tools like Copilot.
  • Some read it as just short of a total ban; others stress it’s a guideline for good‑faith contributors, not a policeable prohibition.
  • It’s framed by several commenters as primarily about protecting NetBSD from legal trouble, not about denying that AI tools can be useful.

Enforceability and norms

  • Many say it’s essentially unenforceable: short snippets, restyled code, or heavily edited AI output are indistinguishable from hand-written code.
  • Others argue unenforceability isn’t the point; like other project rules (testing, code familiarity), it sets expectations and gives grounds to act if abuse is discovered.
  • Some see it as CYA: if AI‑derived infringing code shows up, NetBSD can show it tried to prevent that.

Licensing and copyright concerns

  • Strong concern that LLMs are trained on GPL and source‑available code, then emit code without preserving licenses or attribution.
  • Risk: GPL or otherwise incompatible code “bleeds” into a BSD‑licensed tree, echoing historic Unix/BSD legal disputes.
  • Proposed mitigations include license‑segregated training (BSD‑only, GPL‑only models), but these don’t exist at comparable quality yet.
  • Debate over whether small snippets are even copyrightable and how this compares to humans reusing patterns from memory.
  • Some distinguish humans (who tend to absorb algorithms) from LLMs (which operate directly on copyrightable text and occasionally regurgitate it verbatim).

Code quality and understanding

  • Critics fear AI encourages “copy without understanding,” making complex, safety‑critical or kernel code more fragile and harder to maintain.
  • Others counter that competent engineers review AI output like any other code; tests and code review remain the key quality gates.
  • Several note that reviewing unfamiliar, nontrivial AI code can be slower than writing it, and tests can’t capture maintainability or design clarity.

Perceived usefulness of AI tools

  • Many describe concrete, positive uses: boilerplate React components, shell/PowerShell scripts, data parsers, small language translations, ESLint rules, and exploratory prototypes.
  • AI is valued for:
    • Reducing “yak shaving” and boilerplate.
    • Acting as an interactive doc/learning aid.
    • Helping in unfamiliar ecosystems or niche one‑off tasks.
  • Others report poor reliability in less common languages or complex domains, requiring heavy rewriting and limiting production use.

Broader attitudes and project context

  • Some fear such policies make NetBSD look out of touch and may harm its relevance; others say caution is warranted given its licensing ethos.
  • Comparison is drawn to past automation (IDEs, static analyzers, autocomplete); supporters see LLMs as another step, critics say they introduce qualitatively new legal and ethical risks.
  • Side discussion notes NetBSD still uses CVS (with plans/interest in Mercurial and a Git mirror), illustrating its conservative tooling culture.