GCC, Conservancy and Rust AI documents (was Re: [PATCH v2] docs/devel: relax policy on AI-generated contributions)

[Paolo Bonzini <pbonzini@redhat.com>]

On 8/7/26 16:41, Daniel P. Berrangé wrote:
> None the less that is an interesting benchmark.
> 
> A key challenge we've always had in these discussions is how
> to draw a line on what "legally signicant" means in practice.
> 
> The fact that the GNU project has used the "15 lines" rule
> for copyright assignment is quite a useful benchmark to take
> in to account precisely because they've used that for years
> (presumably decades?).

True, but it's only superficially the same that they've used.  The GNU 
"15 lines rule", as defined at 
https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html, is 
that "what counts is the total contribution of the person; it is 
irrelevant which parts of it were contributed when"; whereas the GCC AI 
policy treats each contribution from LLMs as independent.

Presumably this is because they consider the likelihood of copyright 
infringement to be independent across LLM outputs, but it's nevertheless 
a different rule.  If so, their reasoning is similar to the one 
discussed earlier in the thread, and they simply picked the same 
threshold that was already in place.

> IME, it is by writing docs for a feature, that you come to learn about
> the flaws / gaps in the thing that is implemented, which feeds back to
> improve the code.  Generating docs you're just going get text that
> reflects the state of the code without the learning & improvement
> experiance.
> 
> I don't think we should have an exception for tests either. If we
> have code in the tests directory that is generalized to become
> part of the broader codebase, we shouldn't have to think about the
> history of whether the tests code was AI generated.

No one is going to agree 100% with everyone else; the only possible 
equilibrium is going to be the current "no AI for code generation" 
policy.  The problem with it is that it is hard both to comply with and 
to enforce.  Contribution to a community is based on some kind of honor 
system, but the reality of LLM operation makes it very hard to use them 
even for tasks that are considered acceptable.  In that sense, the 
policy hinders the honor system instead of helping it.

For example, our policy says that you can use AI for review.  You get a 
review like this (it's Linux but you get the idea):

    kvm_put_kvm() now runs under sev_mirror_lock.  The put is inside the
    critical section [...] If that's the last reference it drags all of
    kvm_destroy_vm() under the mutex.  It's easy to keep it a leaf:

	mutex_lock(&sev_mirror_lock);
	sev->enc_context_owner = NULL;
	mutex_unlock(&sev_mirror_lock);
	kvm_put_kvm(owner_kvm);

    Should I apply the change?

Am I supposed to say no and swap the last two lines myself?  This case 
is probably fine, but where do I draw the line?

In other cases, during review the LLM will sometimes write testcases 
even without asking.  Recently, one model came up with this 
exponential-time testcase while I was trying to understand some Meson code:

    project('t', 'c')
    pkg = import('pkgconfig')
    l0 = static_library('l0', 'x.c', install: true)
    l1 = static_library('l1', 'x.c', link_with: l0, install: true)
    l2 = static_library('l2', 'x.c', link_with: [l1, l0], install: true)
    l3 = static_library('l3', 'x.c', link_with: [l2, l1], install: true)
    l4 = static_library('l4', 'x.c', link_with: [l3, l2], install: true)
    l5 = static_library('l5', 'x.c', link_with: [l4, l3], install: true)
    # ...
    pkg.generate(l22, filebase: 'top')

If I decide that this is a good regression test, how do I (in the 
context of a policy like QEMU's) even rewrite a testcase like this for 
inclusion?  Do I have to rewrite it as a loop:

    project('t', 'c')
    pkg = import('pkgconfig')
    a = static_library('l0', 'x.c', install: true)
    b = static_library('l1', 'x.c', link_with: a, install: true)
    foreach i : range(2, 23)
      t = a
      a = b
      b = static_library(f'l@i@', 'x.c', link_with: [t,a], install: true)
    endforeach
    pkg.generate(b, filebase: 'top')

?  Is this actually an improvement?  Maybe in a test the repetitive text 
is actually clearer.  If I decide the loop shape is worse, or in cases 
where there simply isn't another way to write it, the current policy 
doesn't even let me be honest.

"Use it only for study or review" is a fig leaf.  We *won't* be able to 
catch all AI contributions, whether to code, tests or documentation.  A 
no-agents/no-copy-and-paste policy is clearly enforceable because the 
LLMs' (unbearable) mannerisms jump out instantly.  But if we're talking 
about AI code written by someone who already knows what they want to 
get, who knows the surroundings and has a design in their mind that 
informs the discussion with the LLM, the result is practically (or 
completely) indistinguishable from human-written code; the requirement 
to split the change into logically independent patches alone imposes a 
large amount of human-like structure.

So, the no-AI policy is an equilibrium only because it's stable, not 
because it's good.  I would like to point out two recently released 
documents, one more philosophical and one more practical, hoping that 
this can help finding an alternative.

The first is Conservancy's own recommendations for generative AI 
(https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html). 
  While I believe we wouldn't follow all of them (for example the 
recommendation to treat chat logs as artifacts to be conserved is not 
practical), there are some useful points to consider, with respect to 
the copyright infringement risks that drove the current policy and to 
the general recommended attitude on both ends:

   The FOSS community should support, not just tolerate, those who
   outright reject LLM-gen-AI systems.  [...]  FOSS projects should not
   shun contributors who choose to use LLM-gen-AI systems.

   Before submission, FOSS Contributors must invest substantial time
   reviewing LLM-gen-AI -assisted and/or -generated contributions.

   “Copyleft Everything” remains the best viable and safest approach
   Certainly those who want to release FOSS under non-copyleft licenses
   have more to worry about when using these tools.  [...]

   When LLM-gen-AI systems (including proprietary ones) can massively
   accelerate FOSS improvements, use of such tools is an appropriate
   strategic compromise [...]

Second, the Rust project came up with a different way to approach the 
issue: require disclosure of LLM-assisted changes and hold them to a 
higher bar.  The policy is summarized as follows 
(https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/):

   It's fine to use LLMs to answer questions, analyze, distill, refine,
   check, suggest, review. But not to create. [...]

   Pre-arranged, non-critical, high-quality, well-tested, and well-
   reviewed code changes that are originally created by an LLM are
   allowed, with disclosure.

I would replace "are originally created by an LLM" with "include 
substantial amounts of code written by an LLM" (maybe GCC's 15 line of 
code threshold?), but that's it.

I understand that this may not be a particularly popular position in the 
QEMU community, and that is completely different from what even I wrote 
last June.  But these two are new and recent developments, and it 
happens that I find them to strike the right middle ground.

Thanks,

Paolo