LLM policy

Alexandre Lessard alexandre.lessard at mapgears.com
Fri Jun 19 11:01:37 PDT 2026


Thanks,

I've realized that I had missed a good chunk of the discussion because my
email service decided that it was spam !?

I personally like this conclusion, it's still protecting the openness of
Open Source and at the same time giving an exit door in case the time of
the maintainers isn't respected.

I'm sad that to see all the divisions that LLMs are causing in open source
projects, I keep myself informed on the subject and there's a few clashes
that happened in the last few months around open source projects. I'm
neither for nor against AI in the projects of others, but I'm against
reviewing extruded code from someone that doesn't understand what they are
doing and disrespects the valuable time of maintainers.

For the "Assisted by" requirement, there's one big plus for having it. In
the case there's changes in the court of law about the legality of AI code
using copyrighted content, it would make it easier to find the affected
commits in case the law forces people to revert those. And with the
precedent the US Supreme court has made a few months back; "works created
solely by AI are not eligible for registration under the current rules.";
Only work with "Sufficient human involvement" can be copyrighted at the
moment. So it would also make it clear which parts of postgis are protected
by the Group's copyrights, and which parts aren't.

Thanks again for the extra clarification,
Alex.





On Fri, 19 Jun 2026 at 12:06, Regina Obe <lr at pcorp.us> wrote:

> Alex,
>
>
>
> Thanks for pointing all those things out.  I agree with all of them.
>
>
>
> There are two things we are thinking of:
>
>
>
>    1. Yes clarify our code of conduct
>    2. To Greg’s point who sadly left presumably because of irreconcilable
>    differences, and to strk’s conclusion, I think it’s worthwhile to make an
>    LLM policy and I’ve been reading the ones Greg pointed out to see what we
>    like and don’t like
>    https://lists.osgeo.org/pipermail/postgis-devel/2026-June/030773.html
>
>
>
> We have decided that yes ultimately the human is responsible for the
> actions of the LLM, but we also want to not discourage people from using
> them and are more concerned with setting up best practices of using LLM as
> best we can by experimenting with them ourselves to make it less likely
> that a user will inadvertently break our code of conduct.
>
>
>
> We are still experimenting with what do we consider good practices of
> using an LLM and as you can see @Sandro Santilli <strk at kbt.io> set up a
> repo here for that - https://gitea.osgeo.org/postgis/postgis-ai
>
> The idea being something like, we may decide not to allow LLM generated
> from new users, unless they’ve played at least once in our postgres-ai
> playpen.  I think that will help curve drive-by LLM pull requests, which we
> haven’t gotten any of yet to my knowledge aside from the ones Darafei has
> been generating.
>
>
>
> Also  we have decided that any contribution largely written by an LLM
> should have an Assisted By: <org> Model .
>
> Case in point -
> https://gitea.osgeo.org/postgis/postgis_tiger_geocoder/pulls/25
>
>
>
> I don’t know if anyone agrees with me or not, but I don’t want links back
> to the site of the org, because then it would just feel like marketing that
> org to others.  We were torn with Assisted By because:
>
>    1. Feels like just marketing
>    2. It’s the honest thing to do though and will flag that yes we need
>    to pay more attention to this PR because of generation of poorer code by
>    LLM (which I expect to improve with time)
>    3. It could get noisy as Darafei mentioned if a core contributor is
>    using it a lot for some tasks.  Strk had suggested maybe contributors that
>    want to use an LLM a lot, have the commits done by an ai proxy e.g. if
>    strk’s ai was writing the code, it would be strk-ai (as the author), but of
>    course strk would be the one to merge it and be responsible for having
>    merged it.  Then in that case, strk-ai bio would show the details of models
>    used etc.
>    4. At what point do you say you don’t need to disclose.  E.g. If I use
>    a search AI mode on a search engine to write a line of code I am struggling
>    with, do I need to say Assisted By?  Cause I would never write that when I
>    do a seach engine search to find someone who has had the same problem and
>    use that person’s recipe.  I wouldn’t write “Assisted-By: DuckDuckGo” in my
>    commit notes, though I may provide a link to where I got the answer in the
>    pull request description.
>
>
>
>
>
> Darafei has been experimenting with LLMs and he did say it is taking him a
> bit of time to review some of these.  So we might put another restriction
> like, No big patches period,
>
> unless you have made contributions in the past, cause we don’t have faith
> in you yet that you can review your code.  If a core contributor does it we
> of course expect the contributor to have thoroughly reviewed before
> applying and thus can commit any size.
>
>
>
> So that would be a simple reject and we can even auto do that – any patch
> written by someone for the first time can’t be longer than X characters
> total.
>
> That would force users to solve simpler problems before they try to solve
> larger ones and prove that they are not just a drive-by patcher.
>
>
>
> *From:* Alexandre Lessard <alexandre.lessard at mapgears.com>
> *Sent:* Friday, June 19, 2026 10:22 AM
> *To:* postgis-devel at lists.osgeo.org
> *Subject:* Re: LLM policy
>
>
>
> After re-reading the Code of Conduct, I see how this could cover any issue
> with LLMs, but now because of :
>
> PostGIS welcomes and encourages participation by everyone. We are
> committed to being a community that everyone feels good about joining, and
> we will always work to treat everyone well. No matter how you identify
> yourself or how others perceive you: we welcome you.
>
>
>
> but because of the Specific guidelines, especially those points :
>
>    - Be empathetic, welcoming, friendly, and patient; "At the moment,
>    LLMs are welcoming, friendly, and patient, but empathetic isn't part of
>    what they can do."
>    - Be inquisitive; "LLMs aren't inquisitive by default, they need to be
>    properly prompted to do so."
>    - Be concise; "This is the biggest pain with open source projects
>    right now, they are really verbose and are using a lot of the efforts of
>    reviewers."
>    - Step down considerately; "That is often an issue still, where either
>    they don't acknowledge an issue, or they just repeat the same thing and
>    pretend it's solved."
>
> The biggest issue that needs to be resolved here is, who is the entity
> breaking the code of conduct when this happens? Is it the human that
> connected the LLM to the Repository, the agent instance, the agent
> software/version, the agent developers, the LLMs, the LLM flavour, the LLM
> Flavour and version, or the developers of the LLM. And how breaking the
> Code of Conduct is going to be applied?
>
>
>
> I believe that if those are clearly addressed to clear the confusion, the
> code of conduct would be able to resolve any issue with humans,
> corporations or LLM.
>
>
>
> Thanks,
>
> Alex.
>
> P.S. To clear any ambiguities about my opinions, I do not like LLMs nor
> the generative AI industry right now, I believe the it can be a really
> useful tool in the hands of someone qualified, but I still find the ethical
> issue of how they acquired their, data and how energy and hardware hungry
> these things are. But I'm also of the opinion that if someone decides to
> use them, they should do it properly and not be a net negative to society.
>
>
>
> On Fri, 19 Jun 2026 at 07:02, Greg Troxel <gdt at lexort.com> wrote:
>
> I've stopped being maintainer of the pkgsrc package and am signing off
> the list.  I wish you well in postgis development!
>
>
>
>
> --
>
> Alexandre Lessard
>
> DevOps - Mapgears
>
>
>


-- 
Alexandre Lessard
DevOps - Mapgears
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260619/715d2c1f/attachment.htm>


More information about the postgis-devel mailing list