Re: Coding assistants (LLM) policy

Olivier Dion <[email protected]> writes:

> On Mon, 17 Aug 2026, Greg Troxel <[email protected]> wrote:
>> Olivier Dion <[email protected]> writes:
>>
>>> I have made a tentative policy regarding the usage of LLM for the Guile
>>> project [0].  You can find a verbatim copy of this policy at the end of
>>> this email along with the Developer Certificate of Origin (DCO) that
>>> accompany it.
>>
>> The comments about honor system are strange.  While I realize that
>> whenever there are rules, people might behave contrary to rules and not
>> disclose it, the honor system comment says more than is typical about
>> people that think LLMs are ok, or perhaps about what people who think
>> LLMs aren't ok think about people that use them :-)
>
> I think the honor system fits well here.  I trust that others will not
> generated LLM outputs if this is what we agreed upon.  Of course, that
> does not make me blind and I might have my suspicion if somebody drops a
> 1000 commits change that re-wrote Guile in Rust.

I didn't mean the concept was off.  I meant that it was strange to be
talking about it, because in every other aspect of interaction in Free
Software, we just say the expectations (like the DCO, like not
surreptiously photographing people or recording conversations at
conferences) and we don't make statements about honor system.  To me,
having to mention it is a huge red flag that we have a deep fracture in
the community -- that we believe we have community members who will
deliberately violate the rules because they object to them.

> But my idea with the honor system is:
>
>   - I want to read patches without thinking if this was LLM generated or
>     not.  I trust it is not.
>
>   - I do not want to confront peoples by asking them if their code was
>     LLM generated or not (could literally be an insult for some,
>     e.g. me).

Agreed about not wanting to read LLM content, but trust is a judgement
that others will behave honorably, or a decision taken on non-rational
grounds to behave as if trust were warranted.

I have on several occasions asked people if their email or code was LLM
generated, and so far in almost all of those questioning occasions,
perhaps even all of them, the answer was that an LLM was used.  It
wasn't fun to ask, but the fix for that is for people to follow the
policy, not for me to stop asking.

> And in the end, if we can not trust each other, what is the point of
> continuing making collaboration?

That's flipping things around, accepting that there is a point to
continue as an axiom.  The real issue is that in our larger community,
there are people that are so pro-LLM-use that they have a sense of
righteousness that anyone who doesn't want to play the LLM game is a bad
person and there's no reason to be resepectful to them.  At least that's
how it feels to me.  That's the elephant in the room.

>> I would therefore sugggest amending:
>>
>>   Require disclosure/attribution of any text/code that came from an LLM.
>>   (Implicitly, consider violating this equivalent to submitting code
>>   written by others while claiming to have written it.)
>
> If we go that route, I think this is already in contradiction with the
> DCO like you mention below.

The problem is that I read the DCO as prohibiting LLM use, and I think
you do too.  But pro-LLM people magically believe that there are no
ethical or legal copying issues with LLM training.   Therefore we need
written guidelines that are explicit about this, to avoid misinterpretation.

>> By saying this is even perhaps ok, the project is deciding:
>>
>>   Notwithstanding that whether LLM output is a derived work of training
>>   data is not a settled legal question, the project chooses to behave as
>>   it LLM output is *not* a derived work, and will accept that into the
>>   codebase.  Further, we do not have any requirements for tracking this,
>>   meaning that we will not have an obvious recovery plan if LLM output
>>   is rules to be a derived work of training data.
>
> I read it differently.  You can not sign the DCO and use LLM.  You are
> violating it by using LLM, because you can not claim copyright in a
> legal way.  Therefore, you can not contribute something coming from a
> LLM.  So I guess this is kind of a ban but indirect.

I think we actually agree and are just approaching from different
angles.  The problem is that your logic that "it's wrong to sign the DCO
for something that has LLM output" is something that many will agree
with, but pro-LLM people will not see the problem.

> Maybe it is better to affirmativaly say that you can not contribute
> anything from LLM and you need to sign the DCO, which implies you did
> not (for now, given no jurisprudence).

Yes, I think it's best to say:

   - Nothing in your contribution can be from an LLM (because the project
     considers that not properly licensed).
   - You must sign the DCO.

because that's much harder to misinterpet.

>> It should be policy that in all project forums, representing LLM text
>> asd one's own (by declining to identify it) should be prohibited.
>> I have seen this in other project environments, and I consider it a
>> serious offense.
>
> Back to the honor system I guess :-)

I don't follow your comment.  First there must be a published policy.
Then one can evaluate if it is violated.

> [0] https://forge.sourceware.org/redi/gcc-wwwdocs/commit/4d0793a6a14bf9bfe9e92ac1599840780355199d

That looks like a policy that is well over the line of "good enough".

(There's a second issue, which is "it's not ok to ask humans to read LLM
output", but that can be addressed later without license contamination.)