[PROJ] More restrictive LLM policy - like in GDAL

Tue Oct 20 21:08:36 PDT 2026

I am not certain that we are ready for a vote.

I have experienced the two-edged sword Kristian mentioned. I have seen the
barrier to entry lowered for contributors as well as an increase in the bot
accounts.

I have the same priorities Kristian mentioned as well:

* Community building/human interactions
* Avoiding maintainer burnout
* Producing a useful software package

I suggest we divide this discussion into two topics:

- How do we prevent bots from overwhelming PROJ?
- How do we guide new contributors who who might not have been able to
contribute code without AI/LLM usage? (i.e. guide developers to contribute
in a maintainer friendly manner)

On Tue, Oct 20, 2026, 8:20 AM Howard Butler via PROJ <proj at lists.osgeo.org>
wrote:

> -0 from me for the reason that it doesn't do anything to change the major
> complaint. We have a constant onslaught of LLM-generated content in the
> project that we must react to that is impeding maintainer's ability to
> manage the project effectively without feeling as if they're existing to
> satisfy the machine. The policy doesn't change that, but if it gives
> maintainers permission to close stuff without remorse, I would argue
> they've always had it.
>
> Much of the recent projection formula PR churn is clearly LLM-originated.
> It was either found by LLMs exercising lightly tested code paths, or found
> by someone prompting an LLM to look for obvious formula bugs. We're
> adapting and merging them because they are specific enough, small enough to
> reason about, and valuable because they fix real issues. A "No AI" policy
> is incongruent with this kind of contribution which from a practical
> standpoint is already happening in PROJ.
>
> I think we should invest more to harden the project against slop, protect
> our CI allocation by gatekeeping PRs to only run the simple linux test
> runner before workflowing a more substantial, maintainer-initiated CI loop,
> and be ruthless about closing anything we don't like for whatever reason.
> The old model of open source was to be accommodating in the face of
> contributors. It must now be the other way – contributors must be
> accommodating in the face of maintainers. Maybe that means they'll have to
> rework or recreate a PR two or three times to get enough attention on the
> topic to get it merged.
>
> The alternative is "Which PROJ?", which is going to happen regardless
> because a fork is now so easy to make, but it is not so easy to build up 43
> years of trust. PROJ and its code is what's trusted. We should not be in a
> hurry to break that trust. Not fixing obvious bugs because an LLM found
> them instead of a person weakens that trust, but we don't need to be
> accommodating of contribution that makes convenient distribution of
> capability for the contributor at the cost of diligence, review, agony of
> the maintainers.
>
>
> On Oct 20, 2026, at 7:23 AM, Kristian Evers via PROJ <proj at lists.osgeo.org>
> wrote:
>
> It's a +0 from me.
>
> I think the current GDAL policy is okay but I am not sure it will change
> much without further changes to how we handle new contributors and what
> expections we set to contributions. My feeling is that we will still get
> unwanted contributions no matter what policy we put in place.
>
> I am not sure what to make of the lack of votes though. Is it a silent
> acceptance or do we have community members that are against the policy but
> don't feel like disturbing the peace?
>
> /Kristian
> On Sunday, October 18th, 2026 at 20:16, Javier Jimenez Shaw <
> j1 at jimenezshaw.com> wrote:
>
> Hi Kurt
>
> Sorry, it could not be clear enough.
> This voting is about this PR
> https://github.com/OSGeo/PROJ/pull/4912
> to change the AI policy in PROJ.
>
> I found it an easy step to start with it PROJ.
>
> The initiative by Nyall to change the GDAL terms was happening as a
> consequence of my first email (if I understood correctly. I didn't know
> Nyall was in this mailing list!)
>
> Of course, changing today PROJ conditions doesn't mean we can't change
> them again tomorrow.
>
> Javier.
>
>
> On Sun, 18 Oct 2026, 20:03 Kurt Schwehr, <schwehr at gmail.com> wrote:
>
>> Javier,
>>
>> What exactly are you voting on?
>>
>> For those not keeping up, please also see this discussion:
>>
>> https://lists.osgeo.org/pipermail/gdal-dev/2026-October/061758.html
>>
>> I personally think both PROJ and GDAL need detailed AGENTS.md files to
>> help control the situation and to let AI review tools better help all who
>> use LLM agents in any part of their workflow.
>>
>> -Kurt
>>
>>
>> On Sun, Oct 18, 2026 at 7:55 AM Javier Jimenez Shaw via PROJ <
>> proj at lists.osgeo.org> wrote:
>>
>>> Let's vote
>>>
>>> I start with my +1
>>> Javier
>>>
>>> On Fri, 16 Oct 2026, 10:57 Kristian Evers, <kristian at evers.dev> wrote:
>>>
>>>> Thanks for starting this discussion, Javier! I think everyone that
>>>> follows the activity on GitHub will have been overwhelmed by recent
>>>> activity. I certainly have. It’s’ clear to me that we need to change
>>>> something but it is not clear to me what the best way forward is. Having
>>>> given the topic some though over the last week I think my priorities are as
>>>> follows:
>>>>
>>>> * Community building
>>>> * Human interactions
>>>> * Avoiding maintainer burnout
>>>> * Producing a useful software package
>>>>
>>>> At the moment we are struggling in the three first bullets. In
>>>> particular regarding human interaction. There are quite a few cases where
>>>> you can rightfully doubt if a human was even involved at all. Really
>>>> discouraging. The influx of new dubious contributors is driving maintainer
>>>> burnout at the moment and is not doing wonders for the community either.
>>>> That said, access to LLM tools has also lowered the barrier for entry[0] to
>>>> our community which can be seen in the increased number of contributions in
>>>> the cartographic parts of PROJ. An area that hasn't seen much focus over
>>>> the last few years. The LLMs are helping bridge the gap between web-based
>>>> cartography and our ancient ways of C and C++. I think it is fantastic to
>>>> see some of the innovation in the Javascript-space find its way into PROJ
>>>> but it is not worth anything if it causes the regular maintainers to burn
>>>> out.
>>>>
>>>> I can agree to adopt the GDAL policy but I don’t think it will fix
>>>> everything. I expect we will end up spending quite some time policing the
>>>> policy and new contributors trying to circumvent it. Probably that’s better
>>>> than doing nothing but still not particularly fun.
>>>>
>>>> Let’s finish this debate at the policy first and once that is settled I
>>>> would like to propose a few extra ideas on how to avoid bot accounts and
>>>> increasing community engagement. Stay tuned.
>>>>
>>>> /Kristian
>>>>
>>>>
>>>> [0] Two-edged sword, I know.
>>>>
>>>> On 15 Oct 2026, at 19.45, Javier Jimenez Shaw via PROJ <
>>>> proj at lists.osgeo.org> wrote:
>>>>
>>>> Hi
>>>>
>>>> Recently there has been a relative explosion of PRs (and issues) in
>>>> PROJ. I would say that many of them were LLM generated, by people (well,
>>>> probably not people) that do not know the project, do not care about it,
>>>> and very likely do not have any connection with it. Just to get some
>>>> "points" as contributors I guess.
>>>> I don't want to know how much energy and tokens they burned for such
>>>> PRs and issues.
>>>> You can go to the repository and have your own opinion.
>>>>
>>>> I created this PR that is a copy of the GDAL AI policy:
>>>> https://gdal.org/en/stable/community/ai_tool_policy.html
>>>>
>>>> I don't know if it will keep slope code out of PROJ, but it is another
>>>> step.
>>>> https://github.com/OSGeo/PROJ/pull/4912
>>>>
>>>> Cheers
>>>> Javier.
>>>>
>>>>
>>>> _______________________________________________
>>> PROJ mailing list
>>> PROJ at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/proj
>>>
>>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20261020/206c3d3f/attachment.htm>