[QGIS-Developer] Two proposals -- moratorium on LLM use, and requiring a "proof of life" for contributors
Alessandro Pasotti
apasotti at gmail.com
Wed Sep 23 02:55:56 PDT 2026
Tim, thank you for your summary, I disagree with the CLA signing request,
can you please keep that out from the AI/LLM discussion?
Thank you.
On Wed, Sep 23, 2026 at 11:49 AM Tim Sutton via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:
> Hi Nyall and friends
>
> Thank you to everyone who has been participating in this thread. I wanted
> to share the PSC member perspective here. I think our job is to get out of
> your (developers, contributors) way and try to make sure nothing gets in
> your way. If that includes banning AI / LLM use in
> https://github.com/qgis/qgis we are fine with that. I think we have had
> ample time to debate the issue in various email threads and on the internet
> at large and we can bring this into a project policy. Could we just take
> Stefanos' comment (
> https://github.com/qgis/QGIS/pull/67509#issuecomment-5772186522) as a
> good summary of how we should deal with this and put it through the
> processes we have set up to create policies. Personally, I would prefer we
> remove any derisive language or easter eggs like mentioned above in the
> CONTRIBUTING.md and just keep it clean and tidy. Our proposed way forward
> would be:
>
>
> 1. Define a clear policy that establishes the scope of what is allowed:
> "No LLM assisted code contributions are allowed in the
> https://github.com/qgis/qgis repository. We know this is difficult to
> enforce, but if we subsequently discover that you have used and LLM for
> your contribution, you risk code reversion and contributor rights
> sanctioning."
> 2. Post this in our CONTRIBUTING.md and wire it into incoming PRs if you
> can figure out how to do that. Perhaps it is time to establish a CLA
> workflow that requires signing before any PRs are accepted. I suggest we
> use a modified version of the OSGEO CLA to add any clauses you think are
> appropriate in nice clear, neutral language. See e.g.
> https://gist.github.com/timlinux/cc20c0b8860648da977a261d46b170d4
> 3. Ideally this should go through the QEP process if you can survive the
> vibe coding hordes for another two weeks. I would be happy to help write
> the proposal if you like.
>
> In the QEP and CLA / Policy I would not put any rationale as to why we
> have the policy as that takes us down a rabbit hole of people arguing about
> nuances when IMHO all we should care about is the "what". Similar to how we
> don't explain why my arcane variable naming rules from 2003 persist, just
> that they should be followed :-P
>
> If you don't mind would you roll back the template change long enough for
> use to lay down the policy through a QEP and then have at it in terms of
> putting whatever tooling you need to reject LLM originated requests?
>
> I am happy to jump in to help with QEP writing etc. if needed, just let me
> know. Personally speaking, I know you and Even have expended a lot of
> mental energy on LLM related discussions and I would really love to see us
> provide an environment where it is simply a non-issue,we have clear
> policies and you can get on with the stuff you (hopefully) love - building
> the greatest GIS on planet earth!
>
> Regards
>
> Tim
>
>
> (No LLM was used to compose this email)
>
>
> On Mon, Sep 21, 2026 at 11:19 PM Nyall Dawson via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
>> Ok, I've submitted https://github.com/qgis/QGIS/pull/67509 now. Can
>> someone please approve and merge this?
>>
>> Then (someone motivated) can kick-start the follow up discussion and
>> argue their case that LLM use *should* be allowed.
>>
>> Nyall
>>
>>
>> On Tue, 22 Sept 2026 at 01:22, David Signer <david at opengis.ch> wrote:
>>
>>> Hi everyone
>>>
>>> I think #1 to get time until we have a good solution for #2 won't hurt.
>>> The QGIS project worked well before AI. I kind of miss the big argument for
>>> why we need to use AI for QGIS immediately. I am not against using new
>>> technology, but I think we risk nothing by proceeding with a careful
>>> deliberation. Regarding #2 I am not a big fan of validating a new
>>> contributor's credibility through financial donations, but with #1 we would
>>> have time to find a good solution there.
>>>
>>> Thanks and cheers
>>> Dave
>>>
>>>
>>> On Sat, Sep 19, 2026 at 8:28 PM Célia Buira via QGIS-Developer <
>>> qgis-developer at lists.osgeo.org> wrote:
>>>
>>>> What about implementing #2 proof of life first, see the effect of this
>>>> new policy on the github tracker, and only then implementing #1 if it's
>>>> still needed ?
>>>>
>>>>
>>>> About #2 I like the idea of the proof of life however requiring a
>>>> financial contribution is rubbing me the wrong way. Contributing
>>>> efficiently to the code of QGIS already required access to multiple
>>>> thousands of dollars hardware, often you come to qgis after higher degrees
>>>> of education which also adds inequality barriers. (I remember when I
>>>> started to contribute to qgis it would take a whole night to do a clean
>>>> build of qgis on my laptop at the time)
>>>>
>>>> I think we should go for something simpler as in require new
>>>> contributor to screencast the end result of their PR and made them open the
>>>> help > about this way we can also check they compiled with the last Sha
>>>> commit of the PR.
>>>>
>>>>
>>>> And for #1 My position is very much `wait and see`, I think it's too
>>>> early to tell where the balance between social benefits and social costs of
>>>> these tools will land in the end. And it would be too bad to remove a tool
>>>> that could genuinely be useful in the future. In the last discussion
>>>> Stefanos mentioned to allow contributor to use LLM once a certain threshold
>>>> of PR is reached I think we should explore this too before straight up ban
>>>> LLM
>>>>
>>>>
>>>> And overall it sadden me that we collectively spent 3 decades writing
>>>> free software, free tutorials etc... Effectively creating commons. And LLM
>>>> companies took that from us, and make us pay twice. A first time at
>>>> individual level to access this technology, and a second time by putting
>>>> pressure on people and infrastructure.
>>>>
>>>> I would like to float another ideas around even if it would be hard to
>>>> enforce in practice.
>>>> *Force AI companies to give back*.
>>>> Want to use Claude code? Sure but anthropic have to become a sustaining
>>>> member of QGIS.org first
>>>> Want to use codex, gemini? Then openAi and Google have to contribute to
>>>> the project financially and I'm talking geniully multiple thousands dollars
>>>> contributions.
>>>>
>>>>
>>>> In other words we should enter collective bargaining between open
>>>> source communities and AI companies with in mind the "polluter pays
>>>> principle"
>>>>
>>>> Cheers,
>>>> Célia
>>>>
>>>>
>>>> Le mer. 16 sept. 2026 à 05:44, Nyall Dawson via QGIS-Developer <
>>>> qgis-developer at lists.osgeo.org> a écrit :
>>>> >
>>>> > Hi list,
>>>> >
>>>> > It's quite clear that there's considerable hurt and disappointment
>>>> > within the QGIS developer community right now, and for very
>>>> > understandable reasons.
>>>> >
>>>> > I've been giving this a lot of thought over the last few days, and
>>>> > would like to propose two actions we could take that I think would
>>>> > make a positive difference to our community.
>>>> >
>>>> > #1. Place an immediate, total moratorium on all forms of LLM based
>>>> > contributions.
>>>> >
>>>> > We've tried gentle policies regarding this up till now, but clearly
>>>> > that's not helping. So I would like to propose a complete and total
>>>> > moratorium on any form of contribution assisted in any way (beyond as
>>>> > a replacement for a simple web search*).
>>>> >
>>>> > I think we should introduce a firm policy ASAP as a step toward
>>>> > repairing our community, and only after this could we start
>>>> > discussions about what form of LLM contribution may be acceptable.
>>>> >
>>>> > I.e. RIGHT NOW we default to a safe "NO AI" policy, and potentially
>>>> > later loosen this, rather than having a loose policy right now that
>>>> > maybe we'll correct in future.
>>>> >
>>>> > #2. Require a "proof of life" from all new contributors
>>>> >
>>>> > The above policy only really applies to existing contributors who we
>>>> > know and trust. Any policy we introduce will just be totally ignored
>>>> > or lied about by bots or karma farming AI sloppers. I've been
>>>> > wondering how to handle this. I've been thinking some form of "proof
>>>> > that you are a human and who you actually are" could be required, as
>>>> > some kind of document submitted to PSC for private/secure storage. But
>>>> > realistically, that's impossible in 2026, as any form of ID document
>>>> > could be forged in a few seconds, and it's clearly not possible for
>>>> > QGIS.org to police.
>>>> >
>>>> > So I'd propose that new contributors must FIRST make a financial
>>>> > donation to the QGIS project, before any contributions from that
>>>> > person are accepted in any form. This could be a small amount, just
>>>> > enough to deter the karma farmers who don't actually care about the
>>>> > project and what they're contributing. And any amount would be
>>>> > sufficient to block the bots.
>>>> >
>>>> > (Another solution could be to require a face-to-face, in person
>>>> > meeting with a contributor before they can submit changes)
>>>> >
>>>> > What do you all think? I believe we need to act immediately on #1. (I
>>>> > realise #2 may be more tricky and/or controversial)
>>>> >
>>>> > Nyall
>>>> >
>>>> >
>>>> >
>>>> > * because the web is broken in 2026. "simple" web searches don't work
>>>> anymore.
>>>> > _______________________________________________
>>>> > QGIS-Developer mailing list
>>>> > QGIS-Developer at lists.osgeo.org
>>>> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> _______________________________________________
>>>> QGIS-Developer mailing list
>>>> QGIS-Developer at lists.osgeo.org
>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> --
>
> Tim Sutton
>
> *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee
>
> *E *: tim at kartoza.com *W* : kartoza.com
>
>
>
> *This email and any attachments are confidential and intended solely for
> the use of the individual or entity to whom they are addressed. If you *
> *have received this email in error, please notify the sender immediately
> and delete it from your system. Unauthorised use, disclosure, or copying*
> *of the contents is prohibited.*
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
--
Alessandro Pasotti
QCooperative: www.qcooperative.net
ItOpen: www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260923/bc15c09d/attachment-0001.htm>
More information about the QGIS-Developer
mailing list