<!DOCTYPE html><html><head><title></title></head><body><div>Hi all,</div><div><br></div><div>One key point that has been missed so far, and was detailed by Luis in the OSGeo discuss thread [1], was including LLM-generated code puts the entire project's licensing at risk. Until this risk becomes clearer, a ban on LLM generated code in GDAL seems the most prudent approach.</div><div><br></div><div>As I understand it, even with a QGIS type policy, developers are still free to use LLMs to help understand the GDAL codebase, </div><div>assist with debugging, and provide code reviews on any proposed changes. Outside of new feature development, most issues typically only result in a few lines of code changes, so I don't see much advantage in using an LLMs/agents in this case. </div><div>For GDAL driver developers wishing to use LLMs, then these can be written as plugins in a separate repository, with different licensing. </div><div><br></div><div>Looking at geospatial projects that allow LLM contributions, it is 2 months since the last commit to oxigeo, and still only contributor [2].</div><div>RustGIS (a very new project), is part of a GitHub organisation with a history of open source projects, and has a few more contributors. But looking at an pull request with 29 comments [3], it is bots talking to bots all the way down. Personally, I have no interest contributing to a project written and run by AI. </div><div><br></div><div>While this discussion is ongoing, I'm sure it would be appreciated if GitHub pull requests were not used as a battleground for different points of view, resulting in even more pressure on maintainers.</div><div><br></div><div>Seth</div><div><br></div><div>[1] <a href="https://lists.osgeo.org/pipermail/discuss/2026-October/040423.html">https://lists.osgeo.org/pipermail/discuss/2026-October/040423.html</a></div><div>[2] <a href="https://github.com/cool-japan/oxigeo/graphs/contributors?all=1">https://github.com/cool-japan/oxigeo/graphs/contributors?all=1</a></div><div>[3] <a href="https://github.com/opengeos/RustGIS/pull/545">https://github.com/opengeos/RustGIS/pull/545</a></div><div><br></div><div id="sig62266145"><div class="signature">On Sun, Oct 18, 2026, at 10:17 PM, Nyall Dawson via gdal-dev wrote:</div></div><blockquote type="cite" id="qt" style=""><div dir="auto"><div><div><br></div><div><br></div><div class="qt-gmail_quote qt-gmail_quote_container"><div dir="ltr" class="qt-gmail_attr">On Mon, 19 Oct 2026, 6:03 am Kurt Schwehr, <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr"><div>I believe the term is "meat proxy" :)  <a href="https://not-an-llm.com/meat-based-llm-proxies" target="_blank" rel="noreferrer">https://not-an-llm.com/meat-based-llm-proxies</a> / <span style="background-color:transparent;"><a href="https://gruhn.me/blog/2026-08-03/" target="_blank" rel="noreferrer">https://gruhn.me/blog/2026-08-03/</a></span></div><div><br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Ah that's right. Just treat it as proof of my humanity 😂</div><div dir="auto"><br></div><div dir="auto">Nyall</div><div dir="auto"><br></div><div dir="auto"><div class="qt-gmail_quote qt-gmail_quote_container"><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr"><div><br></div><div><div>And that's basically what I was doing with <a href="https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba" target="_blank" rel="noreferrer">https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba</a></div><div><br></div></div><div>But TIL <a href="https://en.wikipedia.org/wiki/Meat_puppet" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/Meat_puppet</a></div><div><br></div></div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Sun, Oct 18, 2026 at 12:41 PM Nyall Dawson via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="auto"><div><div><br></div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Mon, 19 Oct 2026, 5:32 am Jan Heckman via gdal-dev, <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr"><div>Don't know if I should burden you with this - am not involved party, interested only.</div><div>But submitted the conversation (don't shoot me) to deepseek and got the following. It seems reasonable.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That is literally the WORST thing you could have contributed to this discussion. 👎</div><div dir="auto"><br></div><div dir="auto">Regardless of the stance on AI contributions, it is NEVER appropriate or socially acceptable to be a meat puppet and share an llm response like this in a human led discussion.</div><div dir="auto"><br></div><div dir="auto">Nyall</div><div dir="auto"><br></div><div dir="auto"><div class="qt-gmail_quote"><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr"><div><div><div style="max-height:192px;"><div><span>There is the gdal community, they have (probably) had some issues with ill advised pull requests containing 'vibe coding'. But the going on regulating LLM contributions (direct or indirect) is clearly hard. What would you say about this?</span></div></div></div><div><br></div></div><div><h1><span>On the GDAL AI-contribution thread: a hard problem, and the mailing list shows why</span></h1><p><span>This is genuinely hard, and the thread is valuable precisely because it exposes how many </span><i><span>different</span></i><span> problems are being bundled under one policy question. My read of the exchange:</span></p><h2><span>The strongest argument in the thread isn't "AI is bad" — it's asymmetric review burden</span></h2><p><span>Greg Troxel and Javier Jimenez Shaw land the most defensible point: the cost of </span><i><span>producing</span></i><span> a submission has collapsed while the cost of </span><i><span>reviewing</span></i><span> it has not. A plausible-but-subtly-wrong, verbose PR costs a maintainer 10–20x what a competent human-written patch does, because it must be fully understood and effectively rewritten. That's an economic argument about maintainer time, not an ideological one, and it survives regardless of how good the models get. Andrew Bell's point about test bloat (more test lines than code change, slowing an already-slow CI) is the same argument in a different register.</span></p><p><span>Notably, Daniel Baston — an actual maintainer — says the current policy plus GitHub moderation tools (PR rate limits, CI pre-approval, bans) has been </span><i><span>sufficient</span></i><span> for him. That's important counter-evidence: the "burden" claim is not uniformly experienced, and the thread would be better if it surfaced concrete PRs rather than abstractions. Andrew Bell's closing request for real examples is exactly right.</span></p><h2><span>The QGIS-style moratorium is a blunt instrument with a real cost</span></h2><p><span>Nyall's proposal is honest about being a time-limited moratorium, not a forever ban, which is more defensible than a permanent prohibition. But Andrew C Aitchison's objection is the one I'd press hardest: </span><i><span>if the problem is reviewer resources, a total ban doesn't obviously protect reviewer resources</span></i><span> — it just relocates the judgment call to "did they use AI?", which is unverifiable and invites the same policing burden. And his concrete case — using an LLM to </span><i><span>find</span></i><span> a bug, then understanding and taking responsibility for the fix — is exactly the kind of use a blanket ban criminalizes. A policy that can't distinguish "LLM helped me debug, I understand and own this" from "agent spat out a 2000-line PR I never read" is doing blunt work where precision is available.</span></p><h2><span>Michael Sumner's framing conflates things, and Greg's three-way split is the right correction</span></h2><p><span>Sumner asks whether opposition is about quality or ideology, and suggests a blanket ban is "political action." Greg's decomposition — (1) dealing with LLM text, (2) LLM text damaging the project's social structure, (3) LLM use being bad for society — is the cleanest analytical move in the thread. Points (1) and (2) are sufficient to justify </span><i><span>some</span></i><span> policy without touching (3), and that matters: it means people who are enthusiastic LLM users (like Kurt Schwehr, who is candid about spending >90% of coding time directing agents) can still support a tightened policy on non-ideological grounds.</span></p><p><span>Sumner's own position — "the outputs are so good I'm not going to stop" — is honest but is a statement about </span><i><span>his</span></i><span> experience producing code, not about the receiving end. Javier's distinction is the sharpest thing in the thread: </span><i><span>you</span></i><span> using an LLM on </span><i><span>your</span></i><span> project with care is not the same as </span><i><span>strangers</span></i><span> firing agents at </span><i><span>your</span></i><span> project. The externalities run one direction.</span></p><h2><span>What a good policy probably looks like</span></h2><p><span>The thread implicitly sketches something better than either pole:</span></p><ol start="1"><li><p><b><span>Keep the current disclosure-based policy, but make non-compliance cheap to close.</span></b><span> Greg's observation is the operational crux: in proj and gdal, likely-LLM PRs get labeled and left </span><i><span>open</span></i><span>. A policy whose enforcement is "label and wait" is worse than useless — it signals tolerance. The fix is procedural: undisclosed/likely-LLM submissions get closed quickly, not labeled and parked. That's a moderation-culture change, not a policy-text change.</span></p></li><li><p><b><span>Put the guidance where the models read it.</span></b><span> Kurt's AGENTS.md idea is the most constructive proposal in the thread. If the policy document is written for humans and the agents never see it, you get exactly the failure mode you're trying to prevent. A well-edited AGENTS.md plus a blunter CONTRIBUTING.md (his draft PR #15415) attacks the problem at the source rather than at review time. Caveat: an AGENTS.md is advisory to a stochastic system, not a filter — it will improve the distribution, not eliminate slop.</span></p></li><li><p><b><span>Separate "disclosure + human ownership" from "volume."</span></b><span> The defensible core rule is: </span><i><span>a named human must write the issue/PR description, understand the change, and take responsibility for it.</span></i><span> That covers Andrew Aitchison's debugging case, covers translation/refactor use cases, and excludes agent-fire-and-forget. Pair it with rate limits and CI pre-approval (which Dan says already work) to handle volume.</span></p></li><li><p><b><span>Distinguish contribution types.</span></b><span> A driver submission that a human has tested and understands is not the same as a drive-by typo PR generated by an agent. Policy that treats all code equally will either over-block or under-block.</span></p></li></ol><h2><span>Where I'd push back on the thread</span></h2><ul><li><p><span>Nyall asserts "net loss in sustainability, stability and security in recent months" and "community torn apart" without examples. That may be true, but as written it's an assertion that can't be evaluated — and Daniel, a maintainer, disputes the burden framing. The moratorium case needs evidence, not just frustration.</span></p></li><li><p><span>The QGIS precedent is cited as if its bluntness were a virtue; it's better read as "they hadn't solved the hard part either."</span></p></li><li><p><span>Nobody has proposed a </span><i><span>measurement</span></i><span>: e.g., time-to-review or revert-rate on disclosed-AI vs. human PRs. Without that, this debate will keep cycling between "slop is drowning us" and "I just close the slop."</span></p></li></ul><h2><span>Bottom line</span></h2><p><span>The moratorium is a defensible </span><i><span>emergency brake</span></i><span> if the maintainer burden is real and unmanageable — but the thread doesn't establish that it is, and one maintainer says it isn't. The more promising path is the unglamorous one the thread keeps circling: close non-compliant PRs fast instead of labeling them, write the policy for the agents as well as the humans, and make "a human owns and understands this" the load-bearing rule. That threads the needle between Nyall's protect-the-maintainers instinct and Aitchison's legitimate "I used a tool to debug, sue me" case — which a blanket ban cannot.</span></p></div><div><br></div></div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Sun, Oct 18, 2026 at 9:14 PM Andrew Bell via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" rel="noreferrer noreferrer" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr"><div dir="ltr"><span style="background-color:transparent;">On Sun, Oct 18, 2026 at 10:41 AM Greg Troxel via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" rel="noreferrer noreferrer" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:</span></div><div class="qt-gmail_quote"><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><br></div><div>I think there are three issues, super roughly</div><div>   - "dealing with LLM text"</div><div>   - "LLM text in the project is bad for the project's social structure"</div><div>   - "a broad culture of LLM use is bad for society".  </div><div> and I think you are referring the the third as "ideological".  However,</div><div> I think most of the concerns are reachable from the first two parts</div><div> alone.</div></blockquote></div><div><div><br></div><div>I think this discussion is pretty difficult without real examples. I've seen some translation and updating of projects that seem pretty amazing. On the other hand, most of the non-trivial fixes that I've seen haven't been good IMO. We had one recently in PDAL where the issue description was an outright lie.</div><div><br></div><div>Personally, I think a real person should *always* write the descriptive text of an issue or a PR. If they can't do that (succinctly), then they don't understand enough to be submitting a PR. I'm also concerned with test bloat. The GDAL CI loop takes forever already and adding tests for small and probably unimportant fixes (as AI seems set on doing) only makes this worse -- sometimes there are way more lines of test than code change. The tests become a burden.</div><div><br></div><div>Anyway, perhaps someone could point out some AI PRs that they think are OK and some that they find objectionable so that the discussion can move beyond the theoretical.</div></div><div><br></div><div><span class="qt-gmail_signature_prefix">--</span></div><div dir="ltr" class="qt-gmail_signature"><div dir="ltr"><div>Andrew Bell</div><div><a href="mailto:andrew.bell.ia@gmail.com" rel="noreferrer noreferrer" target="_blank">andrew.bell.ia@gmail.com</a></div></div></div></div><div>_______________________________________________</div><div> gdal-dev mailing list</div><div> <a href="mailto:gdal-dev@lists.osgeo.org" rel="noreferrer noreferrer" target="_blank">gdal-dev@lists.osgeo.org</a></div><div> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></blockquote></div><div>_______________________________________________</div><div> gdal-dev mailing list</div><div> <a href="mailto:gdal-dev@lists.osgeo.org" rel="noreferrer noreferrer" target="_blank">gdal-dev@lists.osgeo.org</a></div><div> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></blockquote></div></div></div><div>_______________________________________________</div><div> gdal-dev mailing list</div><div> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a></div><div> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></blockquote></div></blockquote></div></div></div><div>_______________________________________________</div><div>gdal-dev mailing list</div><div><a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a></div><div><a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div><div><br></div></blockquote></body></html>