[Biopython] Generative AI policy for contributions to Biopython

[Andrew Dalke]

In all this discussion about being responsible, passing the Turing test, and the quality of automated code generation tools, remember that this is a tool. Tools can be both useful for some circumstances, and immoral in others. Some things seem great (asbestos, CFCs, fossil fuels, DDT) until the problems show up. I happen to think the negative externalities of this tool far outweigh its benefits, especially for a project like Biopython.

As Peter pointed out in his essay, "Most contributors make one or two fixes (often during their PhD) and move on - partly driven by the chopping and changing of projects on a typical post-doctoral career." (at https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html)

What does it mean to say that a PhD student must be responsible for a contribution, when that student will leave in 4 months to become a high school jazz band teacher after graduation? (Affectionately called "Doc" by all the student musicians.)

What does it mean to say a contributor must be responsible for a contribution, when that contributor likely has no experience on the long-term maintenance issues?

What does it mean to say a contributor must be responsible for a contribution, when it's impossible for that contributor to know how the model was trained, its environmental impact, its centralization of control into fascist loving companies, ... you all know the issues.

There are certainly AI successes, like cURL after the bug bounty finished, but that project has full-time paid developers, and the contributors now are mostly expert security professionals who are not interested in contributing to support, community building, or feature development. They are definitely not grad students and post-docs in a biology-related field with little formal training in software development.

If it's mostly Peter and a handful of overworked maintainers doing Biopython support in their free time, then the responsible thing is to not put more pressure on them by opening the code generation spigot. FOSS maintainer burnout is real, and not getting better.

We can see that in projects like Godot ("AI slop PRs ... are becoming increasingly draining and demoralizing for Godot maintainers." - https://www.theregister.com/2026/02/18/godot_maintainers_struggle_with_draining/) and Jazzband shutting down (https://jazzband.co/news/2026/03/14/sunsetting-jazzband) as the slopocalypse overwhelms maintainers.

If the goal is to convince them to use AI for that purpose, when the reason they took on that role is they enjoy mentoring humans, then there's conflict that can't easily be resolved by anyone except them.

If people are using these tools to write professional quality code for their research projects then good for them -- why are they involved with Biopython if the code generator tool can do it all for them in an integrated package without having to deal with others? It can even start from Biopython, and modify as needed.

And if in 5 years there are ethically trained AI models which need only a lemon and a few potatoes for power, and could generate code which would make both Knuth and rms happy, then Biopython can change its policies.

I also think there's an extra responsibility in the life scientists. I got to talking about AI with a couple other dads at the birthday party for one of my kids' schoolmates. One knows about the problem with AI, but think that the medical advances and new drugs will make it worthwhile. While I, as someone who has been helping with AI-directed drug discovery since the 1990s, in the AI winter of "machine learning" and "artificial reasoning", don't see the magic new cures appearing. While I do see synthetic text generation tools being used to peddle health lies and kill people.

I can't help but think life science research using AI tools then becomes cover to justify far greater abuses using those tools, which should be kept in mind when considering this topic.

					Andrew
					dalke at dalkescientific.com

P.S.

This didn't fit in the above, but I think it's relevant to the proposed requirement "Contributed code (whether generated by AI or not) must be understood by the PR submitter". I think that's too low of a standard.

Some of you may know about the big "chardet" rewrite a few months ago. In short, chardet is a Python library for character encoding detection. It was started by Mark Pilgrim in 2007, and licensed under the LGPL. The current maintainer used Claude code to write a new version, and believed that by doing so the rewritten version no longer fit the legal definition which required keeping the LGPL, so licensed the result as MIT as version 7.0, in March of this year.

This caused some uproar.

I'll set aside completely the question of copyright law, and consider only the question of what it means to understand the code for the developer, vs. what it means to understand the code for the maintainer.

Here's the same table from both versions, first for the LGPL'ed 6.0.0

    # Based on https://encoding.spec.whatwg.org/#names-and-labels
    # Maps legacy encoding names to their modern/superset equivalents.
    # Uses Python's canonical codec names (case-insensitive).
    LEGACY_MAP = {
        "ascii": "Windows-1252",  # ASCII is subset of Windows-1252
        "euc-kr": "CP949",  # EUC-KR extended by CP949 (aka Windows-949)
        "iso-8859-1": "Windows-1252",  # Latin-1 extended by Windows-1252
        "iso-8859-2": "Windows-1250",  # Central European
        "iso-8859-5": "Windows-1251",  # Cyrillic
        "iso-8859-6": "Windows-1256",  # Arabic
        "iso-8859-7": "Windows-1253",  # Greek
        "iso-8859-8": "Windows-1255",  # Hebrew
        "iso-8859-9": "Windows-1254",  # Turkish
        "iso-8859-11": "CP874",  # Thai, extended by CP874 (aka Windows-874)
        "iso-8859-13": "Windows-1257",  # Baltic
        "tis-620": "CP874",  # Thai, equivalent to Windows-874
    }

and then for the license-washed 7.0.0:

# Preferred superset name for each encoding, used by the ``should_rename_legacy``
# API option.  When enabled, detected encoding names are replaced with the
# Windows/CP superset that modern software actually uses (browsers, editors,
# etc. treat these ISO subsets as their Windows counterparts).
# Values use display-cased names (e.g. "Windows-1252") to match chardet 6.x output.
PREFERRED_SUPERSET: dict[str, str] = {
    "ascii": "Windows-1252",
    "euc-kr": "CP949",
    "iso-8859-1": "Windows-1252",
    "iso-8859-2": "Windows-1250",
    "iso-8859-5": "Windows-1251",
    "iso-8859-6": "Windows-1256",
    "iso-8859-7": "Windows-1253",
    "iso-8859-8": "Windows-1255",
    "iso-8859-9": "Windows-1254",
    "iso-8859-11": "CP874",
    "iso-8859-13": "Windows-1257",
    "tis-620": "CP874",
}

There is no copyright infringement here. The data comes from the the whatwg spec, and it's listed in alphabetical order, using the expected Python dictionary, so it doesn't have the creativity requirement for copyright, and clearly the comments are very different.

But while the developer of the second version knows why it works ("to match chardet 6.x output"), the maintainer should rightly want to know: Why is the table there at all? Is anything missing? Should someone be able to add a new superset entry? Which one is iso-8859-11?

For that, I believe the first version is much more informative. It was created by a human, for long-term support by other humans.

(You'll also notice the shift from describing the values as "Python's canonical codec names (case-insensitive)" to "display-cased names".)