Re: [Biopython] Generative AI policy for contributions to Biopython
Dan Bolser <[email protected]> Wed, 22 Jul 2026 19:02:58 +0100
| Newsgroups | gmane.comp.python.bio.general |
|---|---|
| Message-ID | <CANs1yPKSvReWTNSNhGs21U7naAzPsUmk8=AQ-v-epDwZWagmTg@mail.gmail.com> |
--===============5140844722295137531== Content-Type: multipart/alternative; boundary="000000000000c1119a065736f386" --000000000000c1119a065736f386 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm just popping in to announce my personal project, BioPAIthon (it's a fork of BioPython where AI and CI contributions are permitted). Please point your silicon buddies here (all PRs welcome): https://github.com/dbolser/BioPAIthon Thanks, On Fri, 3 Jul 2026 at 17:43, Peter Cock <[email protected]> wrote: > Hello Ant, > > I on the other hand rather hope the current AI-assisted coding boom is > just a passing trend, and will be looked back on like asbestos - with > similar long term problems cleaning buildings/code bases contaminated > with its usage. The metaphor here works for both the legal minefield > and vibe coding quality side - but the later may be a short term issue > if the tools improve. > > But if you're right, and we adopt a strict no-AI policy now, and > things move on and the legal issues settle quickly, moving towards a > policy something like that would be a sensible future choice. > > Peter > > On Thu, Jul 2, 2026 at 4:19=E2=80=AFPM Anthony Underwood <email2ants@gmai= l.com> > wrote: > > > > Dear Biopython maintainers, > > > > Thank you for setting out the contributing guidelines so clearly, > especially the licensing and practical points. I wanted to raise a friend= ly > but genuine concern about the blanket ban on LLM and generative AI use fo= r > contributions and community communication. > > > > I understand and share some of the underlying worries: copyright > provenance of generated code, licensing compatibility, and the review > burden on maintainers are all real issues. However, I think the current > policy, as written, risks being unworkable in practice and could quietly > undermine the project rather than protect it. > > > > AI-assisted coding is not a passing trend. It is now standard practice > across academic labs, research institutes, and commercial biotech and > pharma organisations, including in bioinformatics specifically. Most acti= ve > contributors, whether they disclose it or not, are very likely using code > completion, refactoring assistance, or LLM-based debugging as part of the= ir > normal workflow. A strict ban is difficult to enforce and, if taken > literally, would exclude a large and growing share of the contributor bas= e, > including experienced developers who use these tools responsibly. > > > > I would encourage the maintainers to consider reframing the policy > rather than prohibiting AI use outright. A more workable approach might > treat AI tools the way many teams already do: as a junior coder whose > output always requires review, testing, and sign-off by the human > contributor before submission. Under that framing, the responsibility and > accountability stay exactly where they already sit, with the person > submitting the pull request, while acknowledging the reality of how code > gets written today. This could be paired with a disclosure requirement > (similar to the translation exception already in the policy) rather than = a > ban, which would also make the licensing and provenance questions easier = to > track rather than harder. > > > > I raise this constructively and with real respect for the work the > maintainers do keeping Biopython healthy. I would be glad to help think > through wording for a revised policy if that would be useful, and I am > happy to discuss further on the mailing list or wherever is most > appropriate. > > > > Best regards, > > Ant > > > > On Thu, 2 Jul 2026 at 15:42, Hilmar Lapp <[email protected]> wrote: > >> > >> I left one comment. > >> > >> As a more general comment, a No AI policy as is here will require most > if not all future contributors to do their Biopython development under an > environment entirely disconnected and divergent from what they would be > using for anything else they do professionally. (I don=E2=80=99t think th= ere=E2=80=99ll be > any company or even academic lab in the future that can afford not to > *require* their software developers to use AI-assisted coding. This is > already the case in the teams I=E2=80=99m involved in, and they are all a= cademic.) > >> > >> So this will be an interesting experiment in whether and how > AI-assisted coding policies affect sustainability and viability of projec= ts. > >> > >> -hilmar > >> > >> On Jul 2, 2026, at 8:02=E2=80=AFAM, Peter Cock <p.j.a.cock@googlemail.= com> > wrote: > >> > >> One typo fix later, that's no longer a draft policy - but it is > >> waiting on some approval reviews from others with commit permissions > >> please. > >> > >> Peter > >> > >> On Mon, Jun 22, 2026 at 9:56=E2=80=AFAM Peter Cock <p.j.a.cock@googlem= ail.com> > wrote: > >> > >> > >> Feedback welcomed on this new draft PR for an explicit no-AI policy: > >> > >> https://github.com/biopython/biopython/pull/5241 > >> > >> I had one interesting comment over the weekend on Mastodon where I > >> asked about the AGENTS file text and if it was too whimsical (humour > >> is even harder with an international audience): > >> > >> https://fediscience.org/@pjacock/116782003665914065 > >> > >> https://illuminant.asjo.org/user/asjo/object/156156 > >> > >> I fear it is too whimsical. > >> > >> It will be appreciated by people who tend to agree, and those who > >> don't - for whom the message is - will read it as their belief being > >> ridiculed in an unserious manner. > >> > >> It is a fun idea, though :-) > >> > >> > >> Peter > >> > >> On Sat, Jun 6, 2026 at 10:13=E2=80=AFAM Peter Cock <p.j.a.cock@googlem= ail.com> > wrote: > >> > >> > >> Assuming no objections I'm planning to merge > >> https://github.com/biopython/biopython/pull/5229 > >> on Monday (a week for comment seems fine). > >> > >> Then on to the broader AI policy... > >> > >> Thanks, > >> > >> Peter > _______________________________________________ > Biopython mailing list - [email protected] > https://mailman.open-bio.org/mailman/listinfo/biopython > --000000000000c1119a065736f386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I'm just popping in to announce=C2=A0my personal proje= ct, BioPAIthon (it's a fork of BioPython where AI and CI contributions = are permitted). Please point your silicon buddies here (all PRs welcome):<b= lockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><a href= =3D"https://github.com/dbolser/BioPAIthon">https://github.com/dbolser/BioPA= Ithon</a></div></blockquote><div><br></div><div><span style=3D"background-c= olor:transparent">Thanks,</span></div></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Fri, 3 Jul 2026 at 17:43, Peter Co= ck <<a href=3D"mailto:[email protected]" target=3D"_blank">p.j.a= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">Hello Ant,<br> <br> I on the other hand rather hope the current AI-assisted coding boom is<br> just a passing trend, and will be looked back on like asbestos - with<br> similar long term problems cleaning buildings/code bases contaminated<br> with its usage. The metaphor here works for both the legal minefield<br> and vibe coding quality side - but the later may be a short term issue<br> if the tools improve.<br> <br> But if you're right, and we adopt a strict no-AI policy now, and<br> things move on and the legal issues settle quickly, moving towards a<br> policy something like that would be a sensible future choice.<br> <br> Peter<br> <br> On Thu, Jul 2, 2026 at 4:19=E2=80=AFPM Anthony Underwood <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wr= ote:<br> ><br> > Dear Biopython maintainers,<br> ><br> > Thank you for setting out the contributing guidelines so clearly, espe= cially the licensing and practical points. I wanted to raise a friendly but= genuine concern about the blanket ban on LLM and generative AI use for con= tributions and community communication.<br> ><br> > I understand and share some of the underlying worries: copyright prove= nance of generated code, licensing compatibility, and the review burden on = maintainers are all real issues. However, I think the current policy, as wr= itten, risks being unworkable in practice and could quietly undermine the p= roject rather than protect it.<br> ><br> > AI-assisted coding is not a passing trend. It is now standard practice= across academic labs, research institutes, and commercial biotech and phar= ma organisations, including in bioinformatics specifically. Most active con= tributors, whether they disclose it or not, are very likely using code comp= letion, refactoring assistance, or LLM-based debugging as part of their nor= mal workflow. A strict ban is difficult to enforce and, if taken literally,= would exclude a large and growing share of the contributor base, including= experienced developers who use these tools responsibly.<br> ><br> > I would encourage the maintainers to consider reframing the policy rat= her than prohibiting AI use outright. A more workable approach might treat = AI tools the way many teams already do: as a junior coder whose output alwa= ys requires review, testing, and sign-off by the human contributor before s= ubmission. Under that framing, the responsibility and accountability stay e= xactly where they already sit, with the person submitting the pull request,= while acknowledging the reality of how code gets written today. This could= be paired with a disclosure requirement (similar to the translation except= ion already in the policy) rather than a ban, which would also make the lic= ensing and provenance questions easier to track rather than harder.<br> ><br> > I raise this constructively and with real respect for the work the mai= ntainers do keeping Biopython healthy. I would be glad to help think throug= h wording for a revised policy if that would be useful, and I am happy to d= iscuss further on the mailing list or wherever is most appropriate.<br> ><br> > Best regards,<br> > Ant<br> ><br> > On Thu, 2 Jul 2026 at 15:42, Hilmar Lapp <<a href=3D"mailto:hlapp@d= rycafe.net" target=3D"_blank">[email protected]</a>> wrote:<br> >><br> >> I left one comment.<br> >><br> >> As a more general comment, a No AI policy as is here will require = most if not all future contributors to do their Biopython development under= an environment entirely disconnected and divergent from what they would be= using for anything else they do professionally. (I don=E2=80=99t think the= re=E2=80=99ll be any company or even academic lab in the future that can af= ford not to *require* their software developers to use AI-assisted coding. = This is already the case in the teams I=E2=80=99m involved in, and they are= all academic.)<br> >><br> >> So this will be an interesting experiment in whether and how AI-as= sisted coding policies affect sustainability and viability of projects.<br> >><br> >>=C2=A0 -hilmar<br> >><br> >> On Jul 2, 2026, at 8:02=E2=80=AFAM, Peter Cock <<a href=3D"mail= to:[email protected]" target=3D"_blank">[email protected]</= a>> wrote:<br> >><br> >> One typo fix later, that's no longer a draft policy - but it i= s<br> >> waiting on some approval reviews from others with commit permissio= ns<br> >> please.<br> >><br> >> Peter<br> >><br> >> On Mon, Jun 22, 2026 at 9:56=E2=80=AFAM Peter Cock <<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]= om</a>> wrote:<br> >><br> >><br> >> Feedback welcomed on this new draft PR for an explicit no-AI polic= y:<br> >><br> >> <a href=3D"https://github.com/biopython/biopython/pull/5241" rel= =3D"noreferrer" target=3D"_blank">https://github.com/biopython/biopython/pu= ll/5241</a><br> >><br> >> I had one interesting comment over the weekend on Mastodon where I= <br> >> asked about the AGENTS file text and if it was too whimsical (humo= ur<br> >> is even harder with an international audience):<br> >><br> >> <a href=3D"https://fediscience.org/@pjacock/116782003665914065" re= l=3D"noreferrer" target=3D"_blank">https://fediscience.org/@pjacock/1167820= 03665914065</a><br> >><br> >> <a href=3D"https://illuminant.asjo.org/user/asjo/object/156156" re= l=3D"noreferrer" target=3D"_blank">https://illuminant.asjo.org/user/asjo/ob= ject/156156</a><br> >><br> >> I fear it is too whimsical.<br> >><br> >> It will be appreciated by people who tend to agree, and those who<= br> >> don't - for whom the message is - will read it as their belief= being<br> >> ridiculed in an unserious manner.<br> >><br> >> It is a fun idea, though :-)<br> >><br> >><br> >> Peter<br> >><br> >> On Sat, Jun 6, 2026 at 10:13=E2=80=AFAM Peter Cock <<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]= om</a>> wrote:<br> >><br> >><br> >> Assuming no objections I'm planning to merge<br> >> <a href=3D"https://github.com/biopython/biopython/pull/5229" rel= =3D"noreferrer" target=3D"_blank">https://github.com/biopython/biopython/pu= ll/5229</a><br> >> on Monday (a week for comment seems fine).<br> >><br> >> Then on to the broader AI policy...<br> >><br> >> Thanks,<br> >><br> >> Peter<br> _______________________________________________<br> Biopython mailing list=C2=A0 -=C2=A0 <a href=3D"mailto:Biopython@biopython.= org" target=3D"_blank">[email protected]</a><br> <a href=3D"https://mailman.open-bio.org/mailman/listinfo/biopython" rel=3D"= noreferrer" target=3D"_blank">https://mailman.open-bio.org/mailman/listinfo= /biopython</a><br> </blockquote></div> --000000000000c1119a065736f386-- --===============5140844722295137531== 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 --===============5140844722295137531==--