LLM policy

[Sandro Santilli]

On Sat, Jun 13, 2026 at 08:54:48AM -0400, Greg Troxel wrote:
> Sandro Santilli <strk at kbt.io> writes:
> 
> > On Tue, Jun 09, 2026 at 05:10:51PM +0400, Darafei "Komяpa" Praliaskouski wrote:
> >
> >> I believe AIs are covered by existing diversity statement of code of conduct:
> >> https://postgis.net/community/conduct/#diversity-statement
> >
> > I agree on not defining a policy about which tools you can use to
> > contribute to PostGIS.
> 
> It's not really about "tools you can use", but about input without
> proper licensing (models trained on stolen code)

I know I'm guilty of having contributed PostGIS code by copying what
I learnt by watching other people's code, and I'm grateful to those
who published that code for me to watch, and allowed me to even copy
that code by sharing the resulting code with the same license.

Should I call that stealing ?

> and about overly
> verbose input that is particularly hard to review because of an
> established pattern of subtle errors while seeming plausible.

Both overly verbose input and malicious code could also come from
humans,remmeber the xz-utils backdoor (CVE-2024-3094) ?

> > We need to be always careful about what we merge, and if it's too
> > difficult to review a contribution, we should not feel pressured to
> > accept it.
> 
> Under that, the response to most LLM contributions should be to reject
> them as too verbose, unless they are as tightly written as accepted
> human-authored contributions.  And, to reject contributions that have a
> hint of not being understand by the human submitter as well as one that
> was constructed without LLM.  This is not quite a ban, but in practice
> it's pretty close.

I think in general we should ONLY accept contribution when we're willing
to take on responsibility over what we're merging. If a contributor
doesn't understand the consequences of their contributions it is still
possible that a manintainer would want to merge it because it's well
understood by her/him.

> > Shall communication become too verbose we'll see how to approach that
> > problem, maybe we're not affected because there aren't many Coding Agents
> > capable of filing Trac tickets ;)
> 
> The problematic merge request I saw was filed by a human but the code
> changes were generated by an LLM.
> 
> I suggest looking over the gdal-dev list and Even's comments after
> trying to deal with LLM inputs.

I've been reading complains about the overload on the Fediverse and I
do symphatize with those maintainers. Me personally I don't even look
at GitHub filed pull requests without a corresponding Trac ticket and
even in that case I only review code if a contribution interests me
for some reason (intellectual, fun, work).

Citing Even's signature: "my software is free but my time generally isn't".

--strk; 

  Libre GIS consultant/developer 🎺
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260616/4025ccde/attachment.sig>