Re: [Biopython] Generative AI policy for contributions to Biopython
Michiel de Hoon <[email protected]> Fri, 24 Apr 2026 23:44:38 +0000 (UTC)
| Newsgroups | gmane.comp.python.bio.general |
|---|---|
| Message-ID | <[email protected]> |
--===============3219960096892847647== Content-Type: multipart/alternative; boundary="----=_Part_2925773_619827612.1777074278599" ------=_Part_2925773_619827612.1777074278599 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I am in favor of accepting code generated by AI in principle, as long as whoever submits the code is responsible for the contributed code.Key points are:- Contributed code (whether generated by AI or not) must be understood by the PR submitter;- The PR submitter takes responsibility for guaranteeing that the contributed code is free of license restrictions, and therefore can be released under Biopython's license. But the same requirement holds for any code contributed to Biopython, not just AI-generated code. Best,-Michiel On Friday, April 24, 2026 at 07:16:23 PM GMT+9, Peter Cock <[email protected]> wrote: Dear Biopythoneers, We need to set out a generative AI policy for contributions to Biopython. There are now multiple recent PRs submitted by new contributors which are openly using AI tools, more that I suspect are, and now even AI assisted PRs from past contributors (where CV padding or other external metrics are unlikely to be driving this). These are generally more work to review than human written PRs, and that is a growing issue. I blogged about my views late last year - ending in the line "Right now, I still lean very much to saying no any PR using generative AI". https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html Things will change (both tool capabilities, but also the social and legal interpetations) but that post still describes my views today - note I did not touch on the topic of communications there (see below). Recently Linux adopted what has been described as a balanced stance treating it as a tool with very clear expectations that usage MUST be declared and that the human submitter is responsible for (quoting these four points): * Reviewing all AI-generated code * Ensuring compliance with licensing requirements * Adding their own Signed-off-by tag to certify the DCO * Taking full responsibility for the contribution https://docs.kernel.org/process/coding-assistants.html That is pragmatic but ignores the legal and ethical minefield. We don't have a Developer Certificate of Origin (DCO), but I think the other points are a bare minimum for any Biopython policy. Most of my personal open source projects have only had a very small number of contributors, and I am comfortable with outright rejecting generative AI. I know some of the past/current Biopython contributors are more willing to embrace this technology though - so I doubt support for a simple ban would be unanimous. Speaking for a moment as the current Open Bioinformatics Foundation president, the board has discussed this and agreed not to try to micro manage the member projects. For reference, BioPerl have started https://github.com/bioperl/bioperl-live/issues/407 which has some excellent points and examples to consider. In particular, this is not just a code or documentation changes issue - but also about the communication around any proposed change: the nature of the commit messages, pull request description, and discussion. This ties into the maintainers' burden - many of our recent AI generated PRs have fairy short code changes but the verbose text is exhausting to read and unhelpful. It has sometimes felt like I have been talking to an AI agent rather than a human - I actually liked the feeling of mentoring a new contributor and guiding them through minor hurdles to getting their change accepted, but you lose that with an AI agent inbetween you. I therefore very much like this line from the curreth Codeberg policy: > All communication, that includes: commit messages, pull request > messages, documentation, code comments and issues (and > comments on issues/pull requests), that is intended to be read > by people to understand your thoughts and work must not have > been generated with AI. We exclude machine translation and > tooling that helps with grammar and spelling check. https://codeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md Would anyone like to speak in defence of accepting AI (assisted) PRs, and suggest an existing policy you would be happy we adopt or base ours on? Or should I start drafting a more draconian but likely much shorter one - a few lines like this in the CONTRIBUTING file and/or PR template: No generative AI to be used in any Biopython contributions, with the exception of machine translation to/from English (where you might consider including your original language text as well). Thank you, Peter ------=_Part_2925773_619827612.1777074278599 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div class=3D"ydpb0acf67yahoo-style-wrap" style=3D= "font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:10px;">= <div></div> <div dir=3D"ltr" data-setdir=3D"false">I am in favor of accepting c= ode generated by AI in principle, as long as whoever submits the code is re= sponsible for the contributed code.</div><div dir=3D"ltr" data-setdir=3D"fa= lse">Key points are:</div><div dir=3D"ltr" data-setdir=3D"false">- Contribu= ted code (whether generated by AI or not) must be understood by the PR subm= itter;</div><div dir=3D"ltr" data-setdir=3D"false">- The PR submitter takes= responsibility for guaranteeing that the contributed code is free of licen= se restrictions, and therefore can be released under Biopython's license. B= ut the same requirement holds for any code contributed to Biopython, not ju= st AI-generated code.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div= ><div dir=3D"ltr" data-setdir=3D"false">Best,</div><div dir=3D"ltr" data-se= tdir=3D"false">-Michiel</div></div><div id=3D"yahoo_quoted_7722307549" clas= s=3D"yahoo_quoted"> <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s= ans-serif;font-size:13px;color:#26282a;"> =20 <div> On Friday, April 24, 2026 at 07:16:23 PM GMT+9, Pet= er Cock <[email protected]> wrote: </div> <div><br></div> <div><br></div> =20 =20 <div><div dir=3D"ltr">Dear Biopythoneers,<br></div><div dir= =3D"ltr"><br></div><div dir=3D"ltr">We need to set out a generative AI poli= cy for contributions to Biopython.<br></div><div dir=3D"ltr"><br></div><div= dir=3D"ltr">There are now multiple recent PRs submitted by new contributor= s which<br></div><div dir=3D"ltr">are openly using AI tools, more that I su= spect are, and now even AI assisted<br></div><div dir=3D"ltr">PRs from past= contributors (where CV padding or other external metrics<br></div><div dir= =3D"ltr">are unlikely to be driving this). These are generally more work to= review<br></div><div dir=3D"ltr">than human written PRs, and that is a gro= wing issue.<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">I blogged = about my views late last year - ending in the line "Right now, I<br></div><= div dir=3D"ltr">still lean very much to saying no any PR using generative A= I".<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https:/= /blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.ht= ml" target=3D"_blank">https://blastedbio.blogspot.com/2025/11/thoughts-on-g= enerative-ai-contributions.html</a><br></div><div dir=3D"ltr"><br></div><di= v dir=3D"ltr">Things will change (both tool capabilities, but also the soci= al and legal<br></div><div dir=3D"ltr">interpetations) but that post still = describes my views today - note I did<br></div><div dir=3D"ltr">not touch o= n the topic of communications there (see below).<br></div><div dir=3D"ltr">= <br></div><div dir=3D"ltr">Recently Linux adopted what has been described a= s a balanced stance<br></div><div dir=3D"ltr">treating it as a tool with ve= ry clear expectations that usage MUST be declared<br></div><div dir=3D"ltr"= >and that the human submitter is responsible for (quoting these four points= ):<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">* Reviewing all AI-= generated code<br></div><div dir=3D"ltr">* Ensuring compliance with licensi= ng requirements<br></div><div dir=3D"ltr">* Adding their own Signed-off-by = tag to certify the DCO<br></div><div dir=3D"ltr">* Taking full responsibili= ty for the contribution<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr= "><a href=3D"https://docs.kernel.org/process/coding-assistants.html" target= =3D"_blank">https://docs.kernel.org/process/coding-assistants.html</a><br><= /div><div dir=3D"ltr"><br></div><div dir=3D"ltr">That is pragmatic but igno= res the legal and ethical minefield. We don't<br></div><div dir=3D"ltr">hav= e a Developer Certificate of Origin (DCO), but I think the other<br></div><= div dir=3D"ltr">points are a bare minimum for any Biopython policy.<br></di= v><div dir=3D"ltr"><br></div><div dir=3D"ltr">Most of my personal open sour= ce projects have only had a very small<br></div><div dir=3D"ltr">number of = contributors, and I am comfortable with outright rejecting<br></div><div di= r=3D"ltr">generative AI. I know some of the past/current Biopython contribu= tors<br></div><div dir=3D"ltr">are more willing to embrace this technology = though - so I doubt support<br></div><div dir=3D"ltr">for a simple ban woul= d be unanimous.<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Speaki= ng for a moment as the current Open Bioinformatics Foundation<br></div><div= dir=3D"ltr">president, the board has discussed this and agreed not to try = to micro<br></div><div dir=3D"ltr">manage the member projects. For referenc= e, BioPerl have started<br></div><div dir=3D"ltr"><a href=3D"https://github= .com/bioperl/bioperl-live/issues/407" target=3D"_blank">https://github.com/= bioperl/bioperl-live/issues/407</a> which has some<br></div><div dir=3D"ltr= ">excellent points and examples to consider.<br></div><div dir=3D"ltr"><br>= </div><div dir=3D"ltr">In particular, this is not just a code or documentat= ion changes issue - but<br></div><div dir=3D"ltr">also about the communicat= ion around any proposed change: the nature<br></div><div dir=3D"ltr">of the= commit messages, pull request description, and discussion. This<br></div><= div dir=3D"ltr">ties into the maintainers' burden - many of our recent AI g= enerated PRs<br></div><div dir=3D"ltr">have fairy short code changes but th= e verbose text is exhausting to read<br></div><div dir=3D"ltr">and unhelpfu= l. It has sometimes felt like I have been talking to an AI agent<br></div><= div dir=3D"ltr">rather than a human - I actually liked the feeling of mento= ring a new<br></div><div dir=3D"ltr">contributor and guiding them through m= inor hurdles to getting their<br></div><div dir=3D"ltr">change accepted, bu= t you lose that with an AI agent inbetween you.<br></div><div dir=3D"ltr"><= br></div><div dir=3D"ltr">I therefore very much like this line from the cur= reth Codeberg policy:<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">= > All communication, that includes: commit messages, pull request<br></d= iv><div dir=3D"ltr">> messages, documentation, code comments and issues = (and<br></div><div dir=3D"ltr">> comments on issues/pull requests), that= is intended to be read<br></div><div dir=3D"ltr">> by people to underst= and your thoughts and work must not have<br></div><div dir=3D"ltr">> bee= n generated with AI. We exclude machine translation and<br></div><div dir= =3D"ltr">> tooling that helps with grammar and spelling check.<br></div>= <div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://codeberg.org= /comaps/Governance/src/branch/main/AI_USAGE.md" target=3D"_blank">https://c= odeberg.org/comaps/Governance/src/branch/main/AI_USAGE.md</a><br></div><div= dir=3D"ltr"><br></div><div dir=3D"ltr">Would anyone like to speak in defen= ce of accepting AI (assisted) PRs,<br></div><div dir=3D"ltr">and suggest an= existing policy you would be happy we adopt or base<br></div><div dir=3D"l= tr">ours on?<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Or should= I start drafting a more draconian but likely much shorter one -<br></div><= div dir=3D"ltr">a few lines like this in the CONTRIBUTING file and/or PR te= mplate: No<br></div><div dir=3D"ltr">generative AI to be used in any Biopyt= hon contributions, with the exception<br></div><div dir=3D"ltr">of machine = translation to/from English (where you might consider including<br></div><d= iv dir=3D"ltr">your original language text as well).<br></div><div dir=3D"l= tr"><br></div><div dir=3D"ltr">Thank you,<br></div><div dir=3D"ltr"><br></d= iv><div dir=3D"ltr">Peter<br></div></div> </div> </div></body></html> ------=_Part_2925773_619827612.1777074278599-- --===============3219960096892847647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Biopython mailing list - [email protected] https://mailman.open-bio.org/mailman/listinfo/biopython --===============3219960096892847647==--