Re: A "middle ground" Proposal for LLM policy

(Replying to -vote because that's where the discussion is taking
place. While non-DDs can't vote, the discussion is open to everyone
and all constructive contributions are welcome. At least that's how I
understand it.)

Aryan Karamtoth wrote:
> I've been reading the proposals listed for the GR about a project-wide LL=
M policy so far and they're all great but I feel like they've been focusing=
 on the extreme end of the discussion -- either ban them completely or allo=
w them completely.
>
> I was trying to imagine what a "middle ground" proposal might look like i=
f it were to exist and I got a glimpse of it when I saw GCC announcing its =
own AI policy [1].
>
> >The GCC steering committee has announced that it has accepted an AI cont=
ributions policy recommended by >the GCC AI policy working group.
>
> >The policy, in part, states that the project will decline any "legally s=
ignificant contributions which include LLM->generated content or are derive=
d from LLM-generated content". It uses the definition of "legally significa=
nt" >from the GNU Project maintainer guidelines, which holds that the thres=
hold is "around 15 lines of code and/or >text" to qualify as significant fo=
r copyright purposes. GCC maintainers may, however, choose to accept legall=
y >significant test cases that are generated by an LLM.
>
> >The policy does not forbid use of LLMs for research, analysis, bug disco=
very and reporting, patch review, etc. as >long as the output is not includ=
ed in contributions. The committee says that it expects the policy will evo=
lve and >will be revisited periodically.
>
> I feel like a similar proposal (maybe Proposal F) could focus on somethin=
g similar:
>
> " Allow LLM usage only for research or understanding purposes but forbid =
any of that work from being directly materialised into code or documentatio=
n (copy pasting). "
>
> This way we can not only limit the usage of LLMs in the project but also =
avoid DFSG compliance issues because the code must be written by humans.
>
> I personally feel like allowing LLM usage directly in the project would o=
nly result in more unmaintainable codebases, poor quality packages and a te=
chnical debt that will be a burden on new contributors as they may not be a=
ctively interacting with mentors for help. We're already dealing with sever=
al occurrences of server downtime because of the clankers and some vibe cod=
ed debian packages lying out there in mentors.d.net.
>
> On the other hand, we're way past the point where we can just block the u=
sage of LLMs completely because to be honest, despite being an anti-LLM per=
son previously (I still am but not very aggressive), I found them to be of =
some use when dealing with problems where there's a lack of documentation o=
r little resources online but when it comes to code, they still do a horrib=
le job. We need to focus on maintainability too and LLMs are bad at that.
>
> A good way forward that I personally see is actively discouraging LLM usa=
ge but not outright banning it completely and ensuring that the final work =
is human written even though there might be some LLM assistance with resear=
ch or understanding errors.
>
> I do not have voting rights yet so I just thought I'd raise my point of v=
iew about this GR.
>
> [1] https://lwn.net/Articles/1086041/
>
> --
> Regards,
>
> Aryan Karamtoth,
> Debian Maintainer

It is my understanding that the GCC policy addresses only one concern
about AI, that is, the copyright status of AI-generated code. They
won't incorporate code that someone else might be able to claim
copyright on. That's the whole point of the "legally significant"
thing and that's all they seem to worry about. Other activities are
allowed simply because they don't result directly in adding code to
the GCC codebase, so they are zero-risk from that point of view.

That is of course a valid concern, and possibly the one that could
most directly cause legal liability (in the current legal situation --
it is also possible that future rulings may establish that the output
of AI is never copyrightable, thus voiding the issue).

Other concerns are outside the scope of their policy and not addressed
at all: the reliability and quality of AI-generated contributions, the
negative effect on human ability to understand the codebase, the
burden that a flood of AI-generated patches place on maintainers, the
environmental impact of running big LLM models, and so on.

It is ok to adopt the GCC policy *if* you do not think that those
other concerns matter.

Gerardo