[gdal-dev] Tightening AI based submission policy

Sun Oct 18 03:24:47 PDT 2026

Let me add an extra point of view. I know it has been mentioned some times,
but it can be forgotten (including by myself).

There are two very different scenarios:
- you create whatever with LLM.
- you (maintaining a FOSS project) receive PRs done with/by LLM.

In the former you can be very happy with the outputs. You can be cautious,
review everything, understand everything, and do a great work. You care
about the project.

In the latter you may be bombarded by a lot of work. Agents do not care
about your project, and some (most?) of the actual people behind those PRs
neither. You don't know if that people (if any) understand those changes
and the implications. BUT you have to waste your time (for free) to read
that PR, to understand the changes, the motivation, the implications.
That is unfair and unmaintainable.

If you think that the first scenario is ok, do extend that reasoning to the
second. They are not the same. At all.

Javier.

PS a friend of mine is not accepting LinkedIn invitations from people he
never met in person before. In the last FOSS4G he finally met a person, and
then accepted the invitation. I love that aspect of FOSS4G: see in person
the people you were working with (real humans).
Should I apply the same rule to accept PRs? Maybe it is too extreme. But
maybe it is also a good idea.
In any case, if you are in an event, try to meet the people from those
projects you care about. That's a way to create a community.

On Sun, 18 Oct 2026, 08:45 Michael Sumner via gdal-dev, <
gdal-dev at lists.osgeo.org> wrote:

> I don't understand if the llm generated material is too poor (easy to
> ignore/fix, especially by using llms), or if the opposittion is to llm
> generators themselves ideologically (an politlically, climate change and
> capitalism and fasciism etc), and I think these things are conflated
> somewhat.
>
> Agree with Kurt that skills and use-of-llms could reduce the admin load
> overall. And the quality can be extremely good. My ideal would be that
> these projects make the most of what best tech is available, before someone
> else does. I'd wish to see a kind of task-force to investigate
> various patterns of work to move forward that projects can agree on.
> Blanket ban seems like political action that is very unlikely to get the
> desired result, the result will be funds diverted to alternatives.   The
> quality is fundamentally excellent and mind-blowing and like nothing I've
> ever experienced, of course lots of bad stuff is also being made. Should I
> be using the llm I'm using, in terms of provenance and responsibility and a
> sane safe future of humanity ..  - I dunno, the outputs are so good I'm not
> going to stop. I'm not a skilled creator or coder, but I'm seeing really
> good ideas turn into really good tools in a way that has been impossible.
>
> Ideological opposition is a very different stance and I see no resolution
> to that,  and that will result in a proliferation of overlapping tools with
> some future reckoning of the best judged by folks who are engaged with new
> process.
>
> Cheers, Mike
>
> On Sun, Oct 18, 2026 at 12:36 PM Kurt Schwehr via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
>
>> In true LLM style of generating way too much text, I made
>> https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba with
>> two starter AGENTS.md files created by Gemini 4 Argon and Fable 5.1. I also
>> threw in two runs of going through the last 4000 commit messages. Creating
>> something useful as an AGENTS.md will take some serious human editing, but
>> there are lots of good parts in there (and things I disagree with).
>>
>> https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba
>>
>> On Sat, Oct 17, 2026 at 5:46 PM Kurt Schwehr <schwehr at gmail.com> wrote:
>>
>>> I wonder if we should first try working on a better AGENTS.md. AGENTS.md
>>> should be talking to the LLMs... The current one is this:
>>>
>>> # AGENTS instructions
>>>
>>>
>>> * This project does not accept vibe-coded contributions. See
>>>
>>>   [ai_tool_policy.rst](doc/source/community/ai_tool_policy.rst) for what
>>> is acceptable or not.
>>>
>>>
>>> doc/source/community/ai_tool_policy.rst is written for humans and does
>>> not give guidance about what makes for good PRs. If we make a solid
>>> AGENTS.md, I believe we will get better overall results. That AGENTS.md can
>>> be used by review agents on both human and LLM based code, which I view as
>>> a win. And yes, I recognize that LLM reviews do have a lot of noise.
>>>
>>> For context:
>>>
>>> I spend > 90% of my coding time directing agents to create code, but I
>>> spend a large fraction of my time debugging existing code where I use any
>>> tools I can get my hands on and that includes LLMs working in parallel with
>>> me. At this point, I'm accustomed to the noise that LLMs inject into the
>>> process and account for it. I can share some solid success on some small
>>> side projects where I've taken existing 100% human written legacy code (in
>>> this case > 15 years old) and modernized it with great success over the
>>> last 6 months or so. These are small Python libraries where as GDAL a
>>> dramatically larger project, so it might not seem to be equal, but I see
>>> careful use of LLMs working well in a code base with > 100K commits per day.
>>>
>>> https://github.com/schwehr/bitvector-modern
>>> https://github.com/schwehr/ais-area-notice (sorry, this is a seriously
>>> domain specific example, but it's using bitvector-modern)
>>>
>>> It takes careful work and you won't see all the failed changes and
>>> arguing with an LLM to get it on track, but I never would have been able to
>>> succeed given the time I have available without LLMs.
>>>
>>> -Kurt
>>>
>>> On Fri, Oct 16, 2026 at 6:59 AM Daniel Baston via gdal-dev <
>>> gdal-dev at lists.osgeo.org> wrote:
>>>
>>>> > I'd argue that the policy is too permissive and is placing too much
>>>> burden on project maintainers.
>>>>
>>>> As one of the maintainers, I am comfortable with the current policy.
>>>> While I wish we did not live in a world of low-quality AI-assisted pull
>>>> requests, they are not at the top of my personal list of burdens. If a PR
>>>> appears to be slop, I simply do not spend time reviewing it. We clearly
>>>> have had submissions that aren't compatible with the policy, and that will
>>>> be the case with whatever policy we choose. Fortunately, we have moderation
>>>> tools available through GitHub to:
>>>>
>>>> - limit the number of pull requests a user can open (I recently fixed a
>>>> loophole in this)
>>>> - require pre-approval for CI workflows to run, to avoid wasting
>>>> resources on PRs that do not appear to be valuable
>>>> - ban users who do not comply with the policy
>>>>
>>>> So far, these tools have been sufficient to prevent the PRs from being
>>>> a burden to me. Others may have different experiences.
>>>>
>>>> Dan
>>>>
>>>> On Thu, Oct 15, 2026 at 7:13 PM Nyall Dawson via gdal-dev <
>>>> gdal-dev at lists.osgeo.org> wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> I'd like to propose that the GDAL project tighten its current policy
>>>>> regarding submission of AI assisted contributions.
>>>>>
>>>>> Currently the proposal is per
>>>>> https://gdal.org/en/stable/community/ai_tool_policy.html#ai-tool-policy,
>>>>> which sounds like a fair and safe policy. However, we've seen the
>>>>> GDAL community torn apart recently even with this policy in place, so I'd
>>>>> argue that the policy is too permissive and is placing too much burden on
>>>>> project maintainers.
>>>>>
>>>>> I'd also argue strongly that there's been a net loss in the
>>>>> sustainability, stability and security of the GDAL project in recent
>>>>> months, as a direct result of this.
>>>>>
>>>>> For reference, the QGIS project introduced a moratorium on all forms
>>>>> of AI developed submissions (see
>>>>> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md),
>>>>> which is now quite a blunt policy: "No LLM, AI or agent assisted code
>>>>> contributions are allowed in the https://github.com/qgis/qgis
>>>>> repository. If we subsequently discover that you have used an AI, LLM, or
>>>>> any agent-based workflow for your contribution, you will be subject to code
>>>>> reversion and contributor rights sanctioning.".  This is intended as a way
>>>>> to block all forms of ai based submissions, until the project has had time
>>>>> to properly step back and thoughtfully see how they impact on open-source
>>>>> development (at which stages interested parties are invited to start
>>>>> discussions on how to suitably and sustainably loosen this policy).
>>>>>
>>>>> Perhaps a similar stance could be adapted for GDAL? To reiterate --
>>>>> this may not be a permanent, forever ban on AI based submissions. It's a
>>>>> moratorium designed to protect the project and community until we can move
>>>>> forward safely.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Nyall
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gdal-dev mailing list
>>>>> gdal-dev at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> --
> Michael Sumner
> Research Software Engineer
> Australian Antarctic Division
> Hobart, Australia
> 0438489030
> e-mail: mdsumner at gmail.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20261018/1ee23721/attachment.htm>