Pop!_OS moved from disclosure to prohibition.
On September 30, the Pop!_OS contributor guide added a short rule. Content generated by an LLM may not be contributed to Pop!_OS issues or pull requests. The rule names code, comments, and descriptions.[1]
The previous COSMIC pull request template asked contributors to disclose generated code. It warned that generated changes could be complex, lack project context, and take longer to review. The new template replaces that disclosure route with an attestation that the pull request contains no LLM-generated content.[2]
The policy changed because the maintainers changed what they will accept, not because software learned to prove authorship.
The checkbox checks a statement, not the source.
The COSMIC template now asks for one completed checkbox after five contributor statements. Those statements cover generated content, understanding, commit description, testing, and the Developer Certificate of Origin. A GitHub Action runs when a pull request opens, changes, or receives new commits. Its job is to require a completed checklist.[2]
That mechanism is useful and limited. It can block an incomplete pull request form. It cannot inspect how every line was produced, distinguish completion from generation, or decide whether a contributor told the truth. Review and project judgment still carry the policy.
The rollout is code too.
COSMIC's policy update script copies the pull request template and checklist workflow into each submodule listed by the cosmic-epoch repository. It creates a policy-only branch and requests engineering and quality-assurance review.[3]
That is a better maintenance move than pasting policy by hand. We checked twelve COSMIC repositories and found the same template blob in each. The script still has a boundary. It follows the submodule list, so a repository outside that list needs its own update path.
Write for the disputed edge.
The Hacker News thread immediately reached the hard questions. Commenters asked about dependencies that may contain generated code, contributors who use a model while still understanding a patch, review burden, and whether a ban can survive better models.[4] Those comments show where readers expect ambiguity. They do not establish how Pop!_OS will rule on every case.
The contributor guide is strict and short. A follow-up commit removed examples of allowed research or testing because the maintainer did not want examples read as permission.[1] That choice makes the prohibition clear. It also puts more weight on maintainers to answer edge cases consistently.
Build the intake rule before the argument arrives.
- Choose the posture. Ban generated content, require disclosure, or admit it with named evidence.
- Name the routes. State whether the rule covers code, tests, comments, documentation, issue reports, and pull request descriptions.
- Name the gate. Use a contributor attestation, required review, labels, or another mechanism that contributors can see before submission.
- State what automation proves. A checklist proves form completion. It does not prove origin or understanding.
- Publish the dispute route. Say who decides close calls and whether contributors may revise and resubmit.
- Keep copies synchronized. Put the source policy in one maintained location and automate repository updates.
A policy can protect maintainer time without pretending provenance is easy to detect. The contract should say what enters the queue, what stops at the gate, and who owns the close call.