<div dir="ltr">Dear Peter,<div><br></div><div>I don't think there is a viable answer that does not go in the direction you point towards (i.e. some sort of ban), if the aim is to keep manually reviewing Biopython. It simply does not scale up. I believe the discussion now for open-source projects like Biopython is whether to maintain manual review or fully embrace AI both as contributor and maintainer/reviewer. I, for one, would rather stick to manual review.</div><div><br></div><div>How to maintain manual review in an AI world, as Markus points out, is an entirely different question. Some initiatives, like Vouch (<a href="https://github.com/mitchellh/vouch">https://github.com/mitchellh/vouch</a>) explore the old concept of a web-of-trust. Simply pre-authorizing/vetting contributors via an old fashioned mail list, rather than through github, may be an effective way to screen out fully-automated PRs or PRs intended only to boost creds. It's essentially a throttle question. Constrain too much and you'll lose some quality contributions, open up too much and you'll get swamped. A fine line to walk.</div><div><br></div><div>Incidentally, thank you and the main reviewer cadre for keeping Biopython alive and kicking.</div><div><br></div><div>Ivan</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Apr 24, 2026 at 3:00 PM <<a href="mailto:biopython-request@biopython.org">biopython-request@biopython.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">Send Biopython mailing list submissions to<br>
<a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:biopython-request@biopython.org" target="_blank">biopython-request@biopython.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:biopython-owner@biopython.org" target="_blank">biopython-owner@biopython.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Biopython digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Generative AI policy for contributions to Biopython (Peter Cock)<br>
2. Re: Generative AI policy for contributions to Biopython<br>
(Peter Cock)<br>
3. Re: Generative AI policy for contributions to Biopython<br>
(Markus Piotrowski)<br>
4. Re: Generative AI policy for contributions to Biopython<br>
(Andrew Dalke)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 24 Apr 2026 11:16:09 +0100<br>
From: Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>><br>
To: "<a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a>" <<a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a>><br>
Subject: [Biopython] Generative AI policy for contributions to<br>
Biopython<br>
Message-ID:<br>
<<a href="mailto:CAKVJ-_603iM02QN-ORLuGvkNjiL2YL0RLKp-h20FKmRMLrmK-Q@mail.gmail.com" target="_blank">CAKVJ-_603iM02QN-ORLuGvkNjiL2YL0RLKp-h20FKmRMLrmK-Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Dear Biopythoneers,<br>
<br>
We need to set out a generative AI policy for contributions to Biopython.<br>
<br>
There are now multiple recent PRs submitted by new contributors which<br>
are openly using AI tools, more that I suspect are, and now even AI assisted<br>
PRs from past contributors (where CV padding or other external metrics<br>
are unlikely to be driving this). These are generally more work to review<br>
than human written PRs, and that is a growing issue.<br>
<br>
I blogged about my views late last year - ending in the line "Right now, I<br>
still lean very much to saying no any PR using generative AI".<br>
<br>
<a href="https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html" rel="noreferrer" target="_blank">https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html</a><br>
<br>
Things will change (both tool capabilities, but also the social and legal<br>
interpetations) but that post still describes my views today - note I did<br>
not touch on the topic of communications there (see below).<br>
<br>
Recently Linux adopted what has been described as a balanced stance<br>
treating it as a tool with very clear expectations that usage MUST be declared<br>
and that the human submitter is responsible for (quoting these four points):<br>
<br>
* Reviewing all AI-generated code<br>
* Ensuring compliance with licensing requirements<br>
* Adding their own Signed-off-by tag to certify the DCO<br>
* Taking full responsibility for the contribution<br>
<br>
<a href="https://docs.kernel.org/process/coding-assistants.html" rel="noreferrer" target="_blank">https://docs.kernel.org/process/coding-assistants.html</a><br>
<br>
That is pragmatic but ignores the legal and ethical minefield. We don't<br>
have a Developer Certificate of Origin (DCO), but I think the other<br>
points are a bare minimum for any Biopython policy.<br>
<br>
Most of my personal open source projects have only had a very small<br>
number of contributors, and I am comfortable with outright rejecting<br>
generative AI. I know some of the past/current Biopython contributors<br>
are more willing to embrace this technology though - so I doubt support<br>
for a simple ban would be unanimous.<br>
<br>
Speaking for a moment as the current Open Bioinformatics Foundation<br>
president, the board has discussed this and agreed not to try to micro<br>
manage the member projects. For reference, BioPerl have started<br>
<a href="https://github.com/bioperl/bioperl-live/issues/407" rel="noreferrer" target="_blank">https://github.com/bioperl/bioperl-live/issues/407</a> which has some<br>
excellent points and examples to consider.<br>
<br>
In particular, this is not just a code or documentation changes issue - but<br>
also about the communication around any proposed change: the nature<br>
of the commit messages, pull request description, and discussion. This<br>
ties into the maintainers' burden - many of our recent AI generated PRs<br>
have fairy short code changes but the verbose text is exhausting to read<br>
and unhelpful. It has sometimes felt like I have been talking to an AI agent<br>
rather than a human - I actually liked the feeling of mentoring a new<br>
contributor and guiding them through minor hurdles to getting their<br>
change accepted, but you lose that with an AI agent inbetween you.<br>
<br>
I therefore very much like this line from the curreth Codeberg policy:<br>
<br>
> All communication, that includes: commit messages, pull request<br>
> messages, documentation, code comments and issues (and<br>
> comments on issues/pull requests), that is intended to be read<br>
> by people to understand your thoughts and work must not have<br>
> been generated with AI. We exclude machine translation and<br>
> tooling that helps with grammar and spelling check.<br>
<br>
<a href="https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md" rel="noreferrer" target="_blank">https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md</a><br>
<br>
Would anyone like to speak in defence of accepting AI (assisted) PRs,<br>
and suggest an existing policy you would be happy we adopt or base<br>
ours on?<br>
<br>
Or should I start drafting a more draconian but likely much shorter one -<br>
a few lines like this in the CONTRIBUTING file and/or PR template: No<br>
generative AI to be used in any Biopython contributions, with the exception<br>
of machine translation to/from English (where you might consider including<br>
your original language text as well).<br>
<br>
Thank you,<br>
<br>
Peter<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 24 Apr 2026 11:26:28 +0100<br>
From: Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>><br>
To: "<a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a>" <<a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a>><br>
Subject: Re: [Biopython] Generative AI policy for contributions to<br>
Biopython<br>
Message-ID:<br>
<CAKVJ-_59PsJ=<a href="mailto:oX_VGE6O20-qdcGhuVu7noFmOFO1Oqzk%2Bqk8vg@mail.gmail.com" target="_blank">oX_VGE6O20-qdcGhuVu7noFmOFO1Oqzk+qk8vg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
I just posted this on Mastodon (neither I nor Biopython or the OBF use X/Twitter<br>
anymore):<br>
<br>
<a href="https://fediscience.org/@pjacock/116143426085553346" rel="noreferrer" target="_blank">https://fediscience.org/@pjacock/116143426085553346</a><br>
<br>
And that reminded me of an earlier remark I made:<br>
<br>
> Seems the recent #GenerativeAI #slop pull requests that I've looked at for<br>
> #Biopython have preferentially targeted the "Good First Issues". We really<br>
> wanted those to be onboarding ramps for new #OpenSource contributors -<br>
> and not for padding anyone's GitHub profile or whatever the motivation here is.<br>
><br>
> So I think any formal policy will want to say explicitly #NoAI on those issues<br>
> at the very least.<br>
<br>
<a href="https://fediscience.org/@pjacock/116161804363016972" rel="noreferrer" target="_blank">https://fediscience.org/@pjacock/116161804363016972</a><br>
<br>
Peter<br>
<br>
On Fri, Apr 24, 2026 at 11:16?AM Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>> wrote:<br>
><br>
> Dear Biopythoneers,<br>
><br>
> We need to set out a generative AI policy for contributions to Biopython.<br>
><br>
> There are now multiple recent PRs submitted by new contributors which<br>
> are openly using AI tools, more that I suspect are, and now even AI assisted<br>
> PRs from past contributors (where CV padding or other external metrics<br>
> are unlikely to be driving this). These are generally more work to review<br>
> than human written PRs, and that is a growing issue.<br>
><br>
> I blogged about my views late last year - ending in the line "Right now, I<br>
> still lean very much to saying no any PR using generative AI".<br>
><br>
> <a href="https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html" rel="noreferrer" target="_blank">https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html</a><br>
><br>
> Things will change (both tool capabilities, but also the social and legal<br>
> interpetations) but that post still describes my views today - note I did<br>
> not touch on the topic of communications there (see below).<br>
><br>
> Recently Linux adopted what has been described as a balanced stance<br>
> treating it as a tool with very clear expectations that usage MUST be declared<br>
> and that the human submitter is responsible for (quoting these four points):<br>
><br>
> * Reviewing all AI-generated code<br>
> * Ensuring compliance with licensing requirements<br>
> * Adding their own Signed-off-by tag to certify the DCO<br>
> * Taking full responsibility for the contribution<br>
><br>
> <a href="https://docs.kernel.org/process/coding-assistants.html" rel="noreferrer" target="_blank">https://docs.kernel.org/process/coding-assistants.html</a><br>
><br>
> That is pragmatic but ignores the legal and ethical minefield. We don't<br>
> have a Developer Certificate of Origin (DCO), but I think the other<br>
> points are a bare minimum for any Biopython policy.<br>
><br>
> Most of my personal open source projects have only had a very small<br>
> number of contributors, and I am comfortable with outright rejecting<br>
> generative AI. I know some of the past/current Biopython contributors<br>
> are more willing to embrace this technology though - so I doubt support<br>
> for a simple ban would be unanimous.<br>
><br>
> Speaking for a moment as the current Open Bioinformatics Foundation<br>
> president, the board has discussed this and agreed not to try to micro<br>
> manage the member projects. For reference, BioPerl have started<br>
> <a href="https://github.com/bioperl/bioperl-live/issues/407" rel="noreferrer" target="_blank">https://github.com/bioperl/bioperl-live/issues/407</a> which has some<br>
> excellent points and examples to consider.<br>
><br>
> In particular, this is not just a code or documentation changes issue - but<br>
> also about the communication around any proposed change: the nature<br>
> of the commit messages, pull request description, and discussion. This<br>
> ties into the maintainers' burden - many of our recent AI generated PRs<br>
> have fairy short code changes but the verbose text is exhausting to read<br>
> and unhelpful. It has sometimes felt like I have been talking to an AI agent<br>
> rather than a human - I actually liked the feeling of mentoring a new<br>
> contributor and guiding them through minor hurdles to getting their<br>
> change accepted, but you lose that with an AI agent inbetween you.<br>
><br>
> I therefore very much like this line from the curreth Codeberg policy:<br>
><br>
> > All communication, that includes: commit messages, pull request<br>
> > messages, documentation, code comments and issues (and<br>
> > comments on issues/pull requests), that is intended to be read<br>
> > by people to understand your thoughts and work must not have<br>
> > been generated with AI. We exclude machine translation and<br>
> > tooling that helps with grammar and spelling check.<br>
><br>
> <a href="https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md" rel="noreferrer" target="_blank">https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md</a><br>
><br>
> Would anyone like to speak in defence of accepting AI (assisted) PRs,<br>
> and suggest an existing policy you would be happy we adopt or base<br>
> ours on?<br>
><br>
> Or should I start drafting a more draconian but likely much shorter one -<br>
> a few lines like this in the CONTRIBUTING file and/or PR template: No<br>
> generative AI to be used in any Biopython contributions, with the exception<br>
> of machine translation to/from English (where you might consider including<br>
> your original language text as well).<br>
><br>
> Thank you,<br>
><br>
> Peter<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 24 Apr 2026 13:43:39 +0200<br>
From: Markus Piotrowski <<a href="mailto:Markus.Piotrowski@ruhr-uni-bochum.de" target="_blank">Markus.Piotrowski@ruhr-uni-bochum.de</a>><br>
To: <a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a><br>
Subject: Re: [Biopython] Generative AI policy for contributions to<br>
Biopython<br>
Message-ID: <<a href="mailto:a48519d2-8a7f-45cf-a6e6-3bb0b02fc80a@ruhr-uni-bochum.de" target="_blank">a48519d2-8a7f-45cf-a6e6-3bb0b02fc80a@ruhr-uni-bochum.de</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
Dear Peter,<br>
<br>
While I also tend to strongly restrict or even forbid the usage of AI in <br>
Biopython, I wonder how you really can prevent this. A careful submitter <br>
can mask the AI signs in his/her code so that I will go undetected. So <br>
wouldn't it be better to allow the usage under strong restrictions and <br>
conditions (and I agree with the those that you have mentioned, <br>
including the "good first issues" in your other e-mail) to encourage <br>
potential contributors to be transparent about the of use of AI?<br>
<br>
I'm unsure about this, but I wanted to include this topic into the <br>
discussion.<br>
<br>
Best<br>
Markus<br>
<br>
Am 24.04.2026 um 12:16 schrieb Peter Cock:<br>
> Dear Biopythoneers,<br>
><br>
> We need to set out a generative AI policy for contributions to Biopython.<br>
><br>
> There are now multiple recent PRs submitted by new contributors which<br>
> are openly using AI tools, more that I suspect are, and now even AI assisted<br>
> PRs from past contributors (where CV padding or other external metrics<br>
> are unlikely to be driving this). These are generally more work to review<br>
> than human written PRs, and that is a growing issue.<br>
><br>
> I blogged about my views late last year - ending in the line "Right now, I<br>
> still lean very much to saying no any PR using generative AI".<br>
><br>
> <a href="https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html" rel="noreferrer" target="_blank">https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html</a><br>
><br>
> Things will change (both tool capabilities, but also the social and legal<br>
> interpetations) but that post still describes my views today - note I did<br>
> not touch on the topic of communications there (see below).<br>
><br>
> Recently Linux adopted what has been described as a balanced stance<br>
> treating it as a tool with very clear expectations that usage MUST be declared<br>
> and that the human submitter is responsible for (quoting these four points):<br>
><br>
> * Reviewing all AI-generated code<br>
> * Ensuring compliance with licensing requirements<br>
> * Adding their own Signed-off-by tag to certify the DCO<br>
> * Taking full responsibility for the contribution<br>
><br>
> <a href="https://docs.kernel.org/process/coding-assistants.html" rel="noreferrer" target="_blank">https://docs.kernel.org/process/coding-assistants.html</a><br>
><br>
> That is pragmatic but ignores the legal and ethical minefield. We don't<br>
> have a Developer Certificate of Origin (DCO), but I think the other<br>
> points are a bare minimum for any Biopython policy.<br>
><br>
> Most of my personal open source projects have only had a very small<br>
> number of contributors, and I am comfortable with outright rejecting<br>
> generative AI. I know some of the past/current Biopython contributors<br>
> are more willing to embrace this technology though - so I doubt support<br>
> for a simple ban would be unanimous.<br>
><br>
> Speaking for a moment as the current Open Bioinformatics Foundation<br>
> president, the board has discussed this and agreed not to try to micro<br>
> manage the member projects. For reference, BioPerl have started<br>
> <a href="https://github.com/bioperl/bioperl-live/issues/407" rel="noreferrer" target="_blank">https://github.com/bioperl/bioperl-live/issues/407</a> which has some<br>
> excellent points and examples to consider.<br>
><br>
> In particular, this is not just a code or documentation changes issue - but<br>
> also about the communication around any proposed change: the nature<br>
> of the commit messages, pull request description, and discussion. This<br>
> ties into the maintainers' burden - many of our recent AI generated PRs<br>
> have fairy short code changes but the verbose text is exhausting to read<br>
> and unhelpful. It has sometimes felt like I have been talking to an AI agent<br>
> rather than a human - I actually liked the feeling of mentoring a new<br>
> contributor and guiding them through minor hurdles to getting their<br>
> change accepted, but you lose that with an AI agent inbetween you.<br>
><br>
> I therefore very much like this line from the curreth Codeberg policy:<br>
><br>
>> All communication, that includes: commit messages, pull request<br>
>> messages, documentation, code comments and issues (and<br>
>> comments on issues/pull requests), that is intended to be read<br>
>> by people to understand your thoughts and work must not have<br>
>> been generated with AI. We exclude machine translation and<br>
>> tooling that helps with grammar and spelling check.<br>
> <a href="https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md" rel="noreferrer" target="_blank">https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md</a><br>
><br>
> Would anyone like to speak in defence of accepting AI (assisted) PRs,<br>
> and suggest an existing policy you would be happy we adopt or base<br>
> ours on?<br>
><br>
> Or should I start drafting a more draconian but likely much shorter one -<br>
> a few lines like this in the CONTRIBUTING file and/or PR template: No<br>
> generative AI to be used in any Biopython contributions, with the exception<br>
> of machine translation to/from English (where you might consider including<br>
> your original language text as well).<br>
><br>
> Thank you,<br>
><br>
> Peter<br>
> _______________________________________________<br>
> Biopython mailing list - <a href="mailto:Biopython@biopython.org" target="_blank">Biopython@biopython.org</a><br>
> <a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 24 Apr 2026 14:53:15 +0200<br>
From: Andrew Dalke <<a href="mailto:dalke@dalkescientific.com" target="_blank">dalke@dalkescientific.com</a>><br>
To: Markus Piotrowski <<a href="mailto:Markus.Piotrowski@ruhr-uni-bochum.de" target="_blank">Markus.Piotrowski@ruhr-uni-bochum.de</a>><br>
Cc: <a href="mailto:biopython@biopython.org" target="_blank">biopython@biopython.org</a><br>
Subject: Re: [Biopython] Generative AI policy for contributions to<br>
Biopython<br>
Message-ID: <<a href="mailto:A18E3F32-46C0-4AFC-8092-D18DA3B47E86@dalkescientific.com" target="_blank">A18E3F32-46C0-4AFC-8092-D18DA3B47E86@dalkescientific.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Apr 24, 2026, at 13:43, Markus Piotrowski <<a href="mailto:Markus.Piotrowski@ruhr-uni-bochum.de" target="_blank">Markus.Piotrowski@ruhr-uni-bochum.de</a>> wrote:<br>
> I wonder how you really can prevent this.<br>
<br>
The same way Biopython prevents someone from contributing code without permission of the copyright holder, or code which implements an algorithm under patent protection - say "no", be aware that people may do it, and if that happens and is found out, do what can be done to remove it.<br>
<br>
<br>
> Am 24.04.2026 um 12:16 schrieb Peter Cock:<br>
>> I blogged about my views late last year - ending in the line "Right now, I<br>
>> still lean very much to saying no any PR using generative AI".<br>
<br>
I'm one of those contributors, leaders, and maintainers who have gone and went. I know I have no say at all about the project direction.<br>
<br>
Given what little it's worth, I support the no-AI position.<br>
<br>
I long ago moved over to cheminformatics. I've had the displeasure of seeing AI-generated code bases in my field. One was clearly using AI for not-actually "clean room" rewrite of an existing code base, and falsely believed that doing so removed copyright protection. Another contained code obviously derived from an open source code base, but without the required attribution. "Obvious" to someone like me, who has looked at the original source and alternative implementations, but the novice developer using AI tooling likely didn't realize it was plagiarized.<br>
<br>
Saying "the human submitter is responsible" assumes the contributor understands what it means to be responsible. As a general rule, scientists are not trained in the nuances of copyright law, nor have the time to evaluate the severe negative effects of these code generation tools while bombarded by "use AI!" boosterism, all under pressure of writing a thesis or paper.<br>
<br>
Some 20-odd years ago, when I helped manage the BOSC talk submission process, I would get submissions saying something like "code available for academic use only". I explained why that wasn't open source, and most (all?) changed their licenses to an actual open source license. They simply weren't aware, and needed guidance.<br>
<br>
Saying "No generative AI", and following up on it, is also a way to make people aware, and provide guidance.<br>
<br>
Andrew<br>
<a href="mailto:dalke@dalkescientific.com" target="_blank">dalke@dalkescientific.com</a><br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Biopython mailing list - <a href="mailto:Biopython@biopython.org" target="_blank">Biopython@biopython.org</a><br>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Biopython Digest, Vol 264, Issue 2<br>
*****************************************<br>
</blockquote></div>