[Biopython] Generative AI policy for contributions to Biopython

Andrew Dalke dalke at dalkescientific.com
Sun Oct 25 17:47:06 EDT 2026


On Oct 21, 2026, at 19:50, Roo Sczesnak <andrewscz at gmail.com> wrote:
> 
> +1 to adopting a more moderate AI contribution policy, following NumPy/SciPy's example. IMHO, a blanket ban on all AI tool usage is heavy-handed. 

There are some very different political and economic differences between those two projects, and Biopython. For example, Nvidia is an institutional partner to NumPy, and has employees who work full-time on NumPy development, including Sebastian Berg, who is on the NumPy Steering Council. Nvidia, of course, profits greatly from wider AI use, and people who have strong ethical concerns with AI are unlikely to seek employment at Nvidia.

While on the other hand, who will have their job, or a job offer, or academic advancement, or grant funding, canceled if their AI-based software project is not accepted to Biopython should it have a strict "no AI" policy? And why isn't their solution simply to buy a few more tokens and create their own package?

An argument to moderation is the fallacy that the right answer is somewhere between two extremes. Let's assume it's not a fallacy for this case. What are the extremes?

We have one extreme - the mainstream AI viewpoint - that the global warming, noise and environmental damage, centralization of power into a handful of large corporations, hammering of servers to extract the most recent data, destruction of old books to get text which isn't online, abuse of data annotators, inducement of 'AI psychosis', union busting, etc. - is acceptable, and required for the glorious AI future where our new AGI god will fix all the problems.

Or at least required to keep one's job in the face of pressure from your boss, or funding source, to use AI.

We have another extreme, the Butlerian Jihad, "Thou shalt not make a machine in the likeness of a human mind", which very few people actually believe. The realistic other extreme is the "How to Blow Up a Pipeline"-style climate activism, when decades of nonviolent protest has failed, and sabotage and destruction are seemingly the only effective choices. We see some of this as the cameras which feed AI surveillance systems are cut down.

One extreme has powerful people willing to, for example, pollute nearby neighborhoods with the emissions of their fossil-fuel powered generators, with no concern for the health damages it causes, and the other extreme is causing at most some minor property damage in order to protect basic human rights like privacy.

Within these two extremes, I believe the moderate position is to wait until the ethical issues are much better resolved.

I mean, I've already seen a couple of AI-assisted/generated code bases in my field where the code is clearly derived from an existing open source project which is definitely in the training corpus, but where no copyright or acknowledgement is given. This is both copyright infringement and plagiarism. And from what I gather, this lack of appropriate attribution is far more common from these AI tools than they are for human-generated code, with https://arxiv.org/html/2408.02487v3 estimating about 1%.

So, why can't Biopython simply wait a bit for these tools to improve?

> It is entirely possible to write great code with AI tools.

I don't think it's a useful argument to point to exceptional cases as if that alone justifies the goal.

Let's get rid of language classes in schools, because it's entirely possible for someone to teach oneself Latin, Greek, French, Russian, German, Hebrew, Turkish, and Armenian by age 8, as William James Sidis reportedly did.

I believe the argument you are trying to make requires knowing numbers which don't exist and can't even be meaningfully guessed.

Assuming these people exist, and they write code which could be part of Biopython, you would need to know:

 - how many are there?

 - how many would simply publish the code as part of their own project, rather than contribute it to Biopython, no matter what AI policy Biopython has (perhaps all of these people think it's too slow and tedious to deal with a consensus-based group like Biopython)?

 - how many would contribute, but find the NumPy/SciPy's restrictions too strict?

You would then need to balance that against the number of people, including those who write great code, who could contribute to Biopython but who don't want to contribute to an AI project at all.

And somehow try to factor in out the effect of possible skill decay, cognitive decline, or deskilling due to AI use.

While remembering that most bioinformatics programmers don't write great code, but instead write good and useful code.


> A blanket ban won't stop anyone from using the tools, it just forces them to obscure their usage.


Biopython has adopted the Open Bioinformatics Foundation Code of Conduct. This doesn't stop anyone from breaking the code of conduct.

"The Code of Conduct documents describe norms, rules, and recommended practices for all our members and participants. In particular, we want to make sure that we create a welcoming and supportive community for everyone, provide clear guidelines for reporting incidents, and describe how such reports will be handled."

Similarly, a "No AI until the ethical issues have improved" rule would not stop people from breaking that rule. It would describe the norms, and what the response will be should that rule be broken.

Is your belief really that people who use AI tools are so much into their tools that they will ignore clear consent boundaries?

I mean, the major AI tools people mostly talk about are trained on non-consensual expropriation of content, so I can understand that people who use these tools are self-selected to be ones who care less about issues related to consent.

And I've read stories of projects clearly marked as 'no AI', which still get issues and PRs from AI agents.

I just don't see why the solution is to proactively submit to make those sorts of people happy.


					Andrew
					dalke at dalkescientific.com





More information about the Biopython mailing list