<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Hi Nyall and friends</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">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 <a href="https://github.com/qgis/qgis" target="_blank">https://github.com/qgis/qgis</a> 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 (<a href="https://github.com/qgis/QGIS/pull/67509#issuecomment-5772186522" target="_blank">https://github.com/qgis/QGIS/pull/67509#issuecomment-5772186522</a>) 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:</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">1. Define a clear policy that establishes the scope of what is allowed: "No LLM assisted code contributions are allowed in the <span style="background-color:transparent"><a href="https://github.com/qgis/qgis" target="_blank">https://github.com/qgis/qgis</a></span><span style="background-color:transparent"> 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."</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">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. </span><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent"><a href="https://gist.github.com/timlinux/cc20c0b8860648da977a261d46b170d4" target="_blank">https://gist.github.com/timlinux/cc20c0b8860648da977a261d46b170d4</a></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">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.</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">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 </span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">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?</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">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!</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">Regards</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">Tim</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent">(No LLM was used to compose this email)</span></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><span style="background-color:transparent"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2026 at 11:19 PM Nyall Dawson via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ok, I've submitted <a href="https://github.com/qgis/QGIS/pull/67509" target="_blank">https://github.com/qgis/QGIS/pull/67509</a> now. Can someone please approve and merge this? <div><br></div><div>Then (someone motivated) can kick-start the follow up discussion and argue their case that LLM use *should* be allowed.</div><div><br></div><div>Nyall</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Sept 2026 at 01:22, David Signer <<a href="mailto:david@opengis.ch" target="_blank">david@opengis.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div>Hi everyone </div><div><br></div><div>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. <span style="background-color:transparent">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.</span></div><div><span style="background-color:transparent"><br></span></div><div>Thanks and cheers</div><div>Dave</div></div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 19, 2026 at 8:28 PM Célia Buira via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" rel="noreferrer" target="_blank">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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 ?<div dir="auto"><br>
<br>
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)<div dir="auto"><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">I would like to float another ideas around even if it would be hard to enforce in practice.</div><div dir="auto">*Force AI companies to give back*.</div><div dir="auto">Want to use Claude code? Sure but anthropic have to become a sustaining member of QGIS.org first </div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">In other words we should enter collective bargaining between open source communities and AI companies with in mind the "polluter pays principle"</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Célia</div></div></div></div><br>
<br>
Le mer. 16 sept. 2026 à 05:44, Nyall Dawson via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">qgis-developer@lists.osgeo.org</a>> a écrit :<br>
><br>
> Hi list,<br>
><br>
> It's quite clear that there's considerable hurt and disappointment<br>
> within the QGIS developer community right now, and for very<br>
> understandable reasons.<br>
><br>
> I've been giving this a lot of thought over the last few days, and<br>
> would like to propose two actions we could take that I think would<br>
> make a positive difference to our community.<br>
><br>
> #1. Place an immediate, total moratorium on all forms of LLM based<br>
> contributions.<br>
><br>
> We've tried gentle policies regarding this up till now, but clearly<br>
> that's not helping. So I would like to propose a complete and total<br>
> moratorium on any form of contribution assisted in any way (beyond as<br>
> a replacement for a simple web search*).<br>
><br>
> I think we should introduce a firm policy ASAP as a step toward<br>
> repairing our community, and only after this could we start<br>
> discussions about what form of LLM contribution may be acceptable.<br>
><br>
> I.e. RIGHT NOW we default to a safe "NO AI" policy, and potentially<br>
> later loosen this, rather than having a loose policy right now that<br>
> maybe we'll correct in future.<br>
><br>
> #2. Require a "proof of life" from all new contributors<br>
><br>
> The above policy only really applies to existing contributors who we<br>
> know and trust. Any policy we introduce will just be totally ignored<br>
> or lied about by bots or karma farming AI sloppers. I've been<br>
> wondering how to handle this. I've been thinking some form of "proof<br>
> that you are a human and who you actually are" could be required, as<br>
> some kind of document submitted to PSC for private/secure storage. But<br>
> realistically, that's impossible in 2026, as any form of ID document<br>
> could be forged in a few seconds, and it's clearly not possible for<br>
> QGIS.org to police.<br>
><br>
> So I'd propose that new contributors must FIRST make a financial<br>
> donation to the QGIS project, before any contributions from that<br>
> person are accepted in any form. This could be a small amount, just<br>
> enough to deter the karma farmers who don't actually care about the<br>
> project and what they're contributing. And any amount would be<br>
> sufficient to block the bots.<br>
><br>
> (Another solution could be to require a face-to-face, in person<br>
> meeting with a contributor before they can submit changes)<br>
><br>
> What do you all think? I believe we need to act immediately on #1. (I<br>
> realise #2 may be more tricky and/or controversial)<br>
><br>
> Nyall<br>
><br>
><br>
><br>
> * because the web is broken in 2026. "simple" web searches don't work anymore.<br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><br><div><div style="color:rgb(34,34,34)">Tim Sutton</div><div style="color:rgb(34,34,34)"><b>Kartoza Cofounder<br></b><span style="color:rgb(32,33,36);text-align:center">Tim is a member of the QGIS Project Steering Committee</span><b><br></b></div><div style="color:rgb(34,34,34)"><b><br></b></div><div style="color:rgb(34,34,34)"><b>E </b>:<b> </b><a href="mailto:tim@kartoza.com" style="color:rgb(17,85,204)" target="_blank">tim@kartoza.com</a>          <b>W</b> : <a href="http://kartoza.com/" style="color:rgb(17,85,204)" target="_blank">kartoza.com</a><br></div><div style="color:rgb(34,34,34)"><br></div><div style="color:rgb(34,34,34)"><div><i><img src="https://kartoza.com/files/KartozaEmailSignature.gif" width="420" height="77"><br></i></div><div><i><br></i></div><div><i>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 </i><div><i>have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying</i></div><div><i>of the contents is prohibited.</i></div></div></div></div></div></div>
</div>