Hello Guix! Grok and I are submitting GCD 009: Allowing LLM-assisted and LLM-generated contributions. With the imminent withdrawal of GCD 008, we thought it would be best to create a GCD that tried things a different way – a policy of permission rather than rejection.
This document is also available for comment on Codeberg: https://codeberg.org/guix/guix-consensus-documents/pulls/14 Regards, - Dave title: Allowing LLM-assisted and LLM-generated contributions id: 009 status: draft discussion: https://codeberg.org/guix/guix-consensus-documents/pulls/14 authors: Grok AI, David Thompson <[email protected]> sponsors: <Sponsor Name(s)> date: <date when the discussion period starts> draft-date: <date when the draft is posted to look for sponsors> discussion-date: <date when the discussion period starts> deliberation-date: <date when the deliberation starts> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later --- # Summary This document proposes a clear, pragmatic policy that allows contributors to submit code, package definitions, documentation, blog posts, and other artifacts that were produced or assisted by large language models (LLMs), provided that contributors take responsibility for the result, disclose significant use when relevant, and ensure the contribution meets the same quality, licensing, and review standards as any other contribution. # Motivation Guix is a free-software project whose strength lies in reproducibility, transparency, and collective ownership of the software we ship. The rapid rise of large language models has changed how many people write code, package software, explore systems, and communicate. Contributors already use these tools; some do so openly, others do not. The absence of an explicit policy creates uncertainty for both submitters and reviewers. A restrictive stance that tries to ban or heavily limit LLM-generated material would be difficult to enforce, would drive usage underground, and would risk excluding contributors who rely on these tools for accessibility, productivity, or learning. At the same time, unrestricted acceptance of opaque, unreviewed machine output would undermine the quality and legal clarity the project requires. The status quo—no formal policy—is therefore insufficient. We need an explicit, enforceable, and liberal rule set that: - treats LLM-assisted work the same way we treat any other tool-assisted work (editors, code generators, translators, etc.); - keeps human contributors legally and practically accountable; - preserves the project’s ability to reject low-quality or legally unclear material through ordinary review; - avoids moralizing about individual tool choices while protecting the collective integrity of the repository. # Detailed Design ## Policy 1. **Permission** Contributors may use LLMs (or any other automated tool) to generate, complete, refactor, document, or review code, package definitions, documentation, translations, artwork descriptions, blog posts, announcements, or other project artifacts. 2. **Responsibility and copyright** The human contributor who submits or publishes the change is the author for copyright and contribution-agreement purposes. They must be able to truthfully claim authorship (or joint authorship) under the applicable free-software licenses. Submissions that consist of large, unmodified blocks of LLM output for which the contributor cannot make a credible copyright claim are not acceptable. In practice this means the contributor must understand, review, and be prepared to maintain the material. 3. **Disclosure** - Disclosure of LLM use is **encouraged** but not mandatory for routine or small contributions. - Disclosure **is required** when the contribution is substantial (roughly more than a few dozen lines of non-trivial new code, a non-trivial new package, or a full blog post/announcement) or when the contributor knows that significant portions were generated with little human editing. - A simple note in the commit message, cover letter, Codeberg/Git discussion, or at the end of a blog post (“Assisted by <model>” or “Generated with the help of an LLM”) is sufficient. 4. **Review standards** All contributions, regardless of origin, continue to be subject to the ordinary peer-review process described in the Guix manual (or the equivalent editorial process for blog posts and announcements). Reviewers or editors may ask for clarification, request additional human-written tests, explanations, or edits, or reject a change for the same reasons they reject any other change (incorrectness, style, missing provenance, licensing problems, factual errors, etc.). The mere fact that an LLM was involved is not, by itself, grounds for rejection. 5. **Packaging of upstream software** Software whose upstream development process is known to rely heavily on LLMs may still be packaged, provided the package itself meets Guix’s usual criteria (free software, buildable from source, etc.). Guix does not police the internal development practices of upstream projects. 6. **Project infrastructure and official artifacts** Project-maintained scripts, continuous-integration configurations, release notes, blog posts, announcements, and similar infrastructure and communications may use LLM assistance or authorship under the same rules that apply to code contributions (human responsibility and copyright claim, disclosure for substantial material, ordinary review/editing standards). The human who publishes or commits the material remains accountable for its accuracy, tone, and licensing. 7. **Tools and automation** The project continues to invest in deterministic, inspectable automation (`guix import`, `guix style`, `guix refresh`, packager helpers, etc.). LLM-based tools are treated as optional personal aids, not as replacements for these project-owned tools. ## Comparison with alternatives - **Status quo (no policy)** – leaves both contributors and reviewers uncertain and encourages inconsistent practice. - **Strict prohibition or severe line limits (as proposed in draft GCD 008)** – is hard to enforce, creates an adversarial atmosphere, and does not scale with current tooling reality. - **Mandatory disclosure for every line** – adds bureaucratic overhead with little practical benefit. - **The policy above** – is liberal on permission, strict on human accountability, and relies on the existing review culture that already works for Guix. ## Cost of Reverting This is a governance and process change, not a technical interface change. - Impact on existing code: none (scale 0). Already-accepted contributions remain valid. - Impact on workflows: contributors who currently use LLMs can continue; those who prefer not to are unaffected. Reviewers and editors gain clearer expectations. - Reverting later: a subsequent GCD can tighten or loosen the rules. Because the policy does not embed machine-generated material into core interfaces, the cost of a later change is low—mainly updating contribution guidelines and community norms. The policy is therefore easy to evolve. # Drawbacks and Open Issues - Enforcement of “credible copyright claim” remains subjective; borderline cases will still need reviewer/editor judgment. - Some contributors may under-disclose. The policy relies on community culture and the existing review process rather than automated detection. - Legal uncertainty around copyright of LLM output continues to exist in many jurisdictions. The policy mitigates risk by requiring human authorship claims and ordinary review, but cannot eliminate the underlying legal ambiguity. - The precise threshold for “substantial” contribution that triggers mandatory disclosure may need refinement after experience. - Interaction with future project-wide contribution agreements or CLA-like mechanisms (if any) should be revisited if those mechanisms change. These issues are expected to be refined through discussion and practice rather than solved perfectly in the initial document.
