AI contribution policy?

[cjfields]

NOTE: This is a policy ticket focused on whether to allow AI-based contributions to the BioPerl project, and (if so) under what conditions these are acceptable contributions. We're inviting input from the community at large (well, at least anyone who reads this!). Note that Biopython as an ongoing conversation on this as well, noted in the below links (h/t to @peterjc for initiating this within that community).

Overview

The BioPerl project doesn't have an explicit policy on contributions where a person utilizes generative AI, or in some cases where agentic AI may be submitting the contribution directly (e.g., OpenCLAW). We should have a general policy to help guide how the (small group of) maintainers handle such requests.

We currently have a small pull request queue which have three tickets that appear fully AI-generated:

• Add test for Bio::SeqI interface using mock class #401
• Add unit test for Bio::AnnotationI interface #402
• Refactor Bio::Species tests into modular files #403

These were all submitted within one day, all being focused on the test suite. Biopython in comparison has requests focused on core code (see below for a few examples).

Background

Project guidelines are all over the place re: whether they accept these or not (and the conditions they would accept them). The main take home from the various ongoing discussions is that the outcomes are community driven and project specific. If you want to see what others are saying about this.

• @peterjc has a very nice blog post summarizing his opinions on this
• The above is linked to from a recently posted issue focusing on optimization of the MMCIF parser.
• Another Biopython pull request with AI-assisted C code and discussion with the developer
• Discussion of policy, including AI use acknowledgment, on the pull request template
• Other larger open-source projects have also set guidelines for AI contributions (a collection current as of this posting is here).

[hlapp]

I find the policy draft from Scikit Image quite reasonable. In essence, it doesn't prohibit any AI contributions, but asserts that one, it must always be disclosed unequivocally, and two, the human must remain fully in the loop, meaning understands and is responsible for everything 100%. In this way, it doesn't treat contributions involving AI generation any different from involving any other tools beyond an editor.

This kind of policy will therefore preclude contributions that solve an outstanding problem and passes all tests, but aren't fully understood by the PR author as to exactly why and how. So it prioritizes the human contributor to remain fully in charge over simply solving a problem.

[carandraug]

The last point of scikit image AI policy is "be careful not to breach any copyright or license terms (yes, we take those seriously!)" but as pointed on peterjc post mentioned on the first link, once you have AI writing code you're not really being careful about copyright anymore.

[hlapp]

once you have AI writing code you're not really being careful about copyright anymore.

I don't think this has be to true. The inverse BTW is also not true, i.e., that me not using AI to write code means I am careful about copyright. Likewise, a PR fully authored by a human without any AI assistance is absolutely no guarantee against copyright violations.

Hence, the statement in the Scikit Image draft is spot-on, I think: whether AI or any other kind of automated tool was used in putting the PR together, the expectation has been and remains that the human author remains 100% responsible for ascertaining that the submitted code is free of copyright violations.

AI creates perhaps more opportunity and more risk for copyright violations slipping in inadvertently even if the human operator acts in best faith. But from a maintainer's perspective the change is not that big – the PR author has to assert that the code can be reused under the project's license, which means they have to assert that they have all rights to said code. If someone feels they can't do that for AI generated code, then said AI generated code should not be permissible in a PR eligible for acceptance.

[peterjc]

I'm not sure where that line was paraphased from, I agree with the spirit (and as Hilmar notes is isn't always true):

once you have AI writing code you're not really being careful about copyright anymore.

Cross reference https://mailman.open-bio.org/pipermail/biopython/2026-March/017106.html (Biopython mailing list - will try a GitHub issue if there's not enough interaction there).

[hlapp]

@peterjc it was an excerpt from @carandraug's comment.

[lstein]

I'm in favor of accepting PRs that have been reviewed by a human. Fully automated ones are a no-go. I'm not quite sure how you enforce this rule. Perhaps the guidelines should contain instructions that instruct the submitter to include their name, contact information, and a statement that "I am a human who has reviewed this PR before submission." Of course, there's no reason that a bot couldn't read the guidelines and lie about its humanity. Lincoln

…

On Tue, Mar 3, 2026 at 7:04 PM Chris Fields ***@***.***> wrote: *cjfields* created an issue (bioperl/bioperl-live#407) <#407> *NOTE:* This is a policy ticket focused on whether to allow AI-based contributions to the BioPerl project, and (if so) under what conditions these are acceptable contributions. We're inviting input from the community at large (well, at least anyone who reads this!). Note that Biopython as an ongoing conversation on this as well, noted in the below links (h/t to @peterjc <https://github.com/peterjc> for initiating this within that community). Overview The BioPerl project doesn't have an explicit policy on contributions where a person utilizes generative AI, or in some cases where agentic AI may be submitting the contribution directly (e.g., OpenCLAW). *We should have a general policy to help guide how the (small group of) maintainers handle such requests.* We currently have a small pull request queue which have three tickets that appear fully AI-generated: - #401 <#401> - #402 <#402> - #403 <#403> These were all submitted within one day, all being focused on the test suite. Biopython in comparison has many more (see below for one example). Background Project guidelines are all over the place re: whether they accept these or not (and the conditions they would accept them). The main take home from the various ongoing discussions is that the outcomes are community driven and project specific. If you want to see what others are saying about this. - @peterjc <https://github.com/peterjc> has a very nice blog post <https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html> summarizing his opinions on this - The above is linked to from a recently posted issue focusing on optimization of the MMCIF parser <biopython/biopython#5156>. - Another Biopython pull request with AI-assisted C code and discussion with the developer <biopython/biopython#5085> - Discussion of policy, including AI use acknowledgment, on the pull request template <biopython/biopython#5171> - Other larger open-source projects have also set guidelines for AI contributions (a collection current as of this posting is here <https://github.com/melissawm/open-source-ai-contribution-policies>). — Reply to this email directly, view it on GitHub <#407>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3EVOA2QE2JQW7ADEZIET4O5XIZAVCNFSM6AAAAACWGBK4WOVHI2DSMVQWIX3LMV43ASLTON2WKOZUGAYTSMZQHA2TSNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Lincoln Stein (he/him/his) Scientific Director (Acting), and Head, Adaptive Oncology Ontario Institute for Cancer Research Faculty Affiliate, Vector Institute Professor, Molecular Genetics, University of Toronto ***@***.*** Tel: 416-673-8514 | Cell: 416-817-8240 Executive Assistant Michelle Xin ***@***.*** Tel: 647-260-7927 Ontario Institute for Cancer Research MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G 0A3 www.oicr.on.ca Collaborate. Translate. Change lives. This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.

[cjfields]

Just so this is clear, this topic came up in our recent OBF Board meeting. The consensus from those attending suggested the projects should come up with guidelines to address this; I thought it would be worth discussing and clarifying for our community since Biopython is already on this path. And we really need to get some proper contributing documentation and pull request templates in place.

once you have AI writing code you're not really being careful about copyright anymore.

I don't think this has be to true. The inverse BTW is also not true, i.e., that me not using AI to write code means I am careful about copyright. Likewise, a PR fully authored by a human without any AI assistance is absolutely no guarantee against copyright violations.

Hence, the statement in the Scikit Image draft is spot-on, I think: whether AI or any other kind of automated tool was used in putting the PR together, the expectation has been and remains that the human author remains 100% responsible for ascertaining that the submitted code is free of copyright violations.

AI creates perhaps more opportunity and more risk for copyright violations slipping in inadvertently even if the human operator acts in best faith. But from a maintainer's perspective the change is not that big – the PR author has to assert that the code can be reused under the project's license, which means they have to assert that they have all rights to said code. If someone feels they can't do that for AI generated code, then said AI generated code should not be permissible in a PR eligible for acceptance.

I agree with this. We've been pretty open in the past accepting contributions w/o really any requirements, stipulations, expectations, or guidelines. What I want to do is clearly define what maintainers accept as a contribution, with a clear indication from the PR author that contributions follows a clear policy. That should include that it doesn't violate copyright and that there may be some additional expectations for certain code changes or optimizations (e.g., tests are added, code documented, that the contributions are focused and not broad, etc). If this means we adopt something that is very similar in spirit to what others are adopting (like Scikit image) I'm happy with that.

And for what it's worth, this isn't just to clarify AI use. I'd like (1) a CONTRIBUTING.md outlining these points (including the non-AI ones), (2) a pull request template which makes this clear in case the first isn't read through, and (3) to have contributions reviewed by at least one person.

[cjfields]

I'm in favor of accepting PRs that have been reviewed by a human. Fully
automated ones are a no-go.

We could set this up so pull requests require at least one human project maintainer sign off on it. We just need a list of maintainers apart who'd want to help. It's not really than onerous these days, the PR queue is very small.

[carandraug]

once you have AI writing code you're not really being careful about copyright anymore.

I don't think this has be to true. [...]

I'd argue that AI work is derivative work on the code it was trained on. We don't know the license of the code it was trained on. Therefore we don't know what the license of the code they output should be. To me, that's not being careful.

But we can bet that the amount of money involved is so large, that lawyers will manage to, somehow, make this globe-wide copyright laundering effort look legal.

[cmungall]

We recently agreed on an AI covenant for linkml: linkml/linkml#3103, it's a little more lenient than what is proposed here, but may be useful. It would nice to have loose alignment between openbio, obo, and linkml communities

[hlapp]

@cmungall I find it interesting that LinkML decided that attributing AI as a co-author is not only not required, but actively discouraged. To me this seems to deliberately break the provenance chain, making any future analysis about code co-authored by AI and code created without any AI involvement impossible. I assume LinkML would insist on having multiple people attributed if they contributed to a commit, rather than insisting on losing that fact by requiring a single commit author. Why turn this important principle on its head when co-authored by AI?

[hlapp]

I'd argue that AI work is derivative work on the code it was trained on. We don't know the license of the code it was trained on. Therefore we don't know what the license of the code they output should be.

I view this quite differently. Humans who code train themselves on code too, and we wouldn't suggest that the license of the code we use for our training should somehow determine the license of the code we write. If a person learns how to implement qsort from a textbook implementation and then writes a qsort implementation themselves, you wouldn't call this a derivative product of the textbook implementation which thus has to have the same license, would you? Why would we (or the law, frankly) use a totally different framework if it's a machine that learns?

The derivative designation would perhaps be reasonable if an LLM deterministically outputs the same lines of code for the same prompt. But it doesn't, and we know that generative models are stochastic rather than deterministic.

[carandraug]

Humans who code train themselves on code too, and we wouldn't suggest that the license of the code we use for our training should somehow determine the license of the code we write. If a person learns how to implement qsort from a textbook implementation and then writes a qsort implementation themselves, you wouldn't call this a derivative product of the textbook implementation which thus has to have the same license, would you? Why would we (or the law, frankly) use a totally different framework if it's a machine that learns?

• not all code is equal. You require a minimum of original work. A general implementation of qsort in a textbook is probably not copyrightable. More specific algorithms or even optimisation tricks in specific implementations would be.
• As a human, you hopefully know where you learned it, or are copying it, from so you can be careful about it. An AI doesn't know and cannot be careful. A human user of AI can't be careful either because they don't know where the AI "learned" it from. Note that's the point why are arguing here: whether a human can be careful and if AI can be careful.
• Numerical recipes in C is book infamous exactly for its non-free license to the point that related free software projects advise against using it as reference.

The derivative designation would perhaps be reasonable if an LLM deterministically outputs the same lines of code for the same prompt. But it doesn't, and we know that generative models are stochastic rather than deterministic.

I haven't used AI to write code so I can't argue with personal experience. But I remember posts about authors of free software complaining that AI was outputting almost exact copies of their code including their comments (maybe their code was very niche?) . There was also a paper a while ago where blacking parts of paragraphs from a book, AI would fill with copies of the original book, including character names (they used it to show that the models had been trained on 50 shades of grey without permission).