[PROJ] More restrictive LLM policy - like in GDAL
Jérôme St-Louis
jerome at ecere.com
Tue Oct 20 07:53:39 PDT 2026
> 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?
While I've contributed some code and reviews to PROJ, I'm not clear on
who gets to cast these votes -- is it only PSC members, or anyone on
this list?
If I get to vote, it would be a -1 from me to adopt the GDAL AI policy,
for those two reasons I described in the GitHub issues (
https://github.com/OSGeo/PROJ/pull/4912#issuecomment-6198785065 ):
- The definition of "vibe-coded" is ambiguous
- This wording of the policy puts using AI as a tool by knowledgeable
developers who carefully review what they are contributing and take
responsibility for it, and whose modifications / integration of any
AI-generated content within a larger contribution I believe may in fact
be copyrightable, in the same bag as the unwanted automated pull
requests with zero human involvement.
Something like what Felix proposed for deck.gl ( see
https://github.com/OSGeo/PROJ/pull/4912#issuecomment-6211867588 ) and
definition suggested by Luis (
https://github.com/OSGeo/PROJ/pull/4912#issuecomment-6214208175
"contributions lacking significant human creation/input") I believe
would achieve most of the intended goals while remaining receptive to
otherwise suitable use of AI-assisted contributions.
That being said I do not wish agony on any of the maintainers, and there
needs to be a clear way to avoid this overwhelm...
I really think the best way to guarantee this is ensuring that there is
a human behind that PR who spent at least as much effort as it will take
to review the PR, and who is willing to engage with the
maintainers/reviewers, and adjust the PR as necessary.
Thank you for considering this alternate point of view :)
Kind regards,
-Jerome
On 10/20/26 9:20 AM, Howard Butler via PROJ 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/e3bc5d77/attachment-0001.htm>
More information about the PROJ
mailing list