On 2026-02-23 at 14:35+09:00, Maxim Cournoyer wrote:
> Divya Ranjan writes:
> > I don't think we should accept any contributions from LLMs, until FSF
> > has made it clear what their stance on the copyright situation
> > is. That has not been made clear, and this is the reason we do not
> > accept LLM generated code in Emacs core or ELPA as of now[0].
>
> I'm interested in what the FSF and their lawyers will have to say about
> it.
>
> I think it's important to see the nuances; I don't think the LLMs are
> good enough to author anything without any human refactoring/fixing, at
> least not that I saw in my experience, so a purely LLM-authored PR would
> probably not build/execute correctly.
>
> So what I expect we will see more instead is people relying on chatbots
> to get more insights, ideas of a solution, etc. Some code fragment will
> be produced but they will likely serve to guide the solution rather than
> be copied as whole. I think in these situations it's reasonable to
> assume the copyright holder remains the author of the change submitted,
> even if they got some guidance from an LLM to author it.
>
> I think it's unavoidable that this kind of LLM usage happens in the
> community (which mainstream search engine doesn't show some LLM-produced
> summary these days?), and I think a good thing we can do is ask from our
> contributors to be transparent about it, by adding a disclaimer when
> they've used an LLM to author their changes.  It could be just a box to
> check in the PR template, or some git trailer, or both.

I think the nuances in _what_ output from LLM is used is important too
(in comparison to _how_ it is used, e.g. insights/ideas
vs patch generation), as copyright is based on the nontriviality
of an artistic expression.  IANAL but I don't think fixing
a code fragment gives the fixer the complete copyright over it.
In other words, I think the threadshold should be drawn at the size
of the LLM output that is used within the patch, either verbatim
or with modifications.

BTW I started this discussion primarily for the software we package,
i.e. if we are aware of upstream claim to hold copyright
of snippets extracted from other codebases, do we remove such package
from the official free software channel, or are we complicit
and use search engines, fora, LLM, etc. along with upstream
as a legal scapegoat?  Because the legal risk is practically nonexistent
for packaging Linux with an ASL 2.0 metadata field, though it does hurt
our free software mission and morale from our user and contributor base.

Kind regards,
Phong

Attachment: signature.asc
Description: PGP signature

Reply via email to