What should we do with CLs generated by AI?
Ian Lance Taylor
"Co-Authored-By: Claude Opus 4.5 <nor...@anthropic.com>". (I may have
missed this in other CLs.)
Do we have a policy about accepting CLs that were co-written by AI? In
particular, are there any copyright concerns? Has Anthropic signed the
copyright disclaimer? Is that even meaningful given that Claude Opus
has undoubtedly been trained on software distributed under licenses
that are not compatible with Go's license?
These are questions across the broader free software ecosystem, of
course. If anybody is aware of any official stance taken by other free
software projects, that would be helpful.
Thanks.
Ian
Robert Griesemer
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAOyqgcVYa-AfmgF%3DmgOshhmKNnjxHdWzMnvZ1rYEUqo%2BPR%3D6fg%40mail.gmail.com.
Keith Randall
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAKy0tf5DsWPNhjsf9_HEgxXt4DTkGoLbetCuVgDftnYjcM3ksA%40mail.gmail.com.
Keith Randall
John S
Rob Pike
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAAZVx9-N06zXkQUZioAQgGBa0fsANXM0Y%3DqwxNH9iYiBGBGQYg%40mail.gmail.com.
robert engels
On Feb 3, 2026, at 5:17 PM, Rob Pike <r...@golang.org> wrote:
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAOXNBZQtbwBPXza3Dk32xKHQ39a04fijks86fKmcdEcZ3YERGA%40mail.gmail.com.
Alan Donovan
I agree. I think there are going to be massive lawsuits by open source developers and orgs. That will cripple AI - or they will pay. This isn’t fair use - it’s stealing. The purpose of fair use was to encourage building upon - free - which isn’t what AI agents do.
robert engels
On Feb 3, 2026, at 10:23 PM, Alan Donovan <al...@alandonovan.net> wrote:
Russ Cox
Hi all,
These are “interesting times” for sure. We should absolutely be careful and intentional about our use of AI tools when working on Go. And that’s not easy: the landscape looks very different today than it did twelve months ago, and it will probably look very different twelve months from now. The whole industry is trying to answer these questions, with little agreement yet; we are unlikely to hit upon a lasting solution today.
All that said, I think the most important thing we can do is to maintain our usual processes around code review and code quality. Whenever we accept code changes into Go, as reviewers and approvers we are committing to maintain this code in the future, even when the original author is no longer available. We are also committing to the effects of the change on the rest of the codebase. The most important purpose of code review is to ensure that the code is written appropriately for us to make those commitments, usually through an editing process of significant comment and revision. That same bar must still apply when some or all of the code was written with the help of AI-based tools. And if it does, then the result should be that Go’s codebase remains a place where we can all work productively. As long as we keep focused on that goal and end result, I think we will all be fine, even if some of us use AI tools.
Software Engineering Concerns
To me the most important questions around AI tools concern the effect on our software engineering. The fundamentals of software engineering itself have not changed. We still need carefully written, well structured code. We still need good tests to keep code working in the future. We still need to respect the latent information content of existing code and not rewrite whole pieces for no good reason. We still need to review code for maintainability, readability, and understandability, and to catch mistakes.
AI tools have seduced many people into a false belief that these fundamentals no longer apply. People brag about codebases of hundreds of thousands of lines that have never been viewed by people, churned out in record time. On closer inspection, these codebases inevitably turn out to be more like dancing elephants than useful engineering artifacts. For what they accomplish, they are usually too large, too slow, buggy, and awkward to maintain. This “never look at the code” approach to software is the antithesis of what the Go project stands for. If we adopt any official policy around AI tools, I think it should be to reinforce that point.
On the other hand, it is certainly possible to use AI tools for good software engineering. I have written a few programs entirely by prompting AI tools, mostly as an experiment to see what it would be like. For certain use cases, it is great. The most important thing is to keep thinking. The tools make it very easy to turn off your brain, but if you are careful to avoid that trap, you can produce good work. When the AI tool is working on the code for one step, you can spend time thinking about how to approach the next step. You still need to think about what code needs to be written, how best to structure that code, what needs testing, and how best to structure those tests. You also need to read the code the AI tool generates and often need to provide feedback on how it should be rewritten. It is entirely possible to write high quality software this way.
(As an aside, the examples in the previous two paragraphs demonstrate how pointless it is to say things like “AI is writing 100% of our code”. That accurately describes both scenarios!)
From a social standpoint, we have always expected that when contributors send code for review, they are sending quality code that they’ve already self-reviewed, not the first thing that happened to work. In fact, we expect them to send the best code they can write to solve the problem, taking into account maintainability over time and by other people. My initial drafts look nothing like that ideal—I’m usually just trying to get the code working and willing to commit all kinds of software engineering sins to reach that milestone. Once I have code that works, I take that as proof (or at least strong evidence) that I finally understand the problem. Then I think about what a properly engineered solution would look like, and I try to write that solution instead. I might repeat that revision process a few times. I only mail the final version, the one worth the reviewer’s time. I think most of our contributors know this and do this too, but I also think we’ve not said it enough.
We may need to make clear that contributors using AI tools are still expected to send quality code that they’ve already self-reviewed. It is certainly unacceptable to send code you haven’t so much as looked at, but it is also unacceptable to send code you haven’t thought enough about: Is it the right solution? Is there a simpler, faster, or cleaner way to write the code? Are important tests missing? And so on. These questions are especially important when you are using AI tools. It is not okay to delegate careful thought about proper software engineering to the AI tooling.
We probably should have written some of this down in go.dev/doc/contribute long ago. Now would be a good time too. We should frame it as expectations of all contributors, and then point out that using AI tooling does not relieve you of these expectations.
The Oxide RFD about LLM usage observes that people ultimately must take responsibility for what they produce, no matter what tools they use. I agree with that entirely: your responsibilities are not lessened when you use AI tools for your work.
Legal Concerns
People have also raised questions about legal concerns like copyright, and I don’t want to ignore those. At the same time, it is important to remember that (almost) none of us are lawyers. Even if we were, regulators, legislators, and judges will have the final say, and so far they have said very little. And of course software engineers speculating about legal matters often do more harm than good. With all those caveats, I will wade a few inches into these murky waters...
U.S. Copyright Office guidance says that programs—including AI-based tools—cannot be considered authors for copyright purposes. In the courts, Thaler v. Perlmutter affirmed this. However, it is still entirely possible that people using those programs can be considered authors. With that as our starting point, we should consider three non-mutually-exclusive possibilities for the copyrightability of an AI-based tool’s output.
The first possibility is that an AI-based tool would be treated like a paintbrush or typewriter, with the outputs copyrightable by the wielder of the tool. If this comes to pass, then using an AI-based tool is no different from using a text editor, and the Go project doesn’t have anything to worry about.
The second possibility is that the output cannot be copyrighted at all for having been computer-authored. This seems unlikely to me, but there is already source code in our tree that cannot be copyrighted, namely tables of factual information, equations, and code so devoid of expressive content that it is the only way to achieve a particular result. If we need to add purely AI-generated code to the list, then so be it. There will also still be copyright in the work as a whole. Also, as contributors edit and work on the code by hand, their modifications will be unambiguously human-authored and copyrightable. Once again, the Go project would have nothing to worry about.
The third possibility, the most serious one, is that some outputs might be considered to infringe on existing copyrights. Note that the question of whether a specific output infringes is very different from the question of whether the AI tools themselves infringe, which Robert Engels raised. A small number of lines that happen to overlap with existing lines in another program are not a problem. If the lines are arrived at independently, they are not infringement (see “What Colour are your bits?”), and if there is some link, such as the other program being in the AI training data, a small number of lines is almost always going to be fair use. The problem we care about is a large number of lines emitted all at once by the AI tool.
Most tools already contain checks to avoid emitting large numbers of lines found in training data—in the Gemini API this is referred to as the “recitation check”—and the AI companies have fairly strong incentives to make sure those work, compounded by some of them offering their users indemnification against copyright claims. But to continue the hypothetical, suppose the checks didn’t work. That’s when my comments about code review are most important. We are already suspicious of large new chunks of code that don’t read like idiomatic Go you’d find in our repo. We already ask where they came from, for a variety of reasons that already include copyright concerns. We already reject some and write replacements for others. We should keep pushing back on large chunks of code that don’t seem right. That practice will keep catching manually copied code, and it will also help us catch AI recitations, to the extent that they happen.
Keith already quoted the official Google policy from our Open Source Programs Office (OSPO), which is:
“All submissions to Google Open Source projects need to follow Google’s Contributor License Agreement (CLA), which covers any original work of authorship included in the submission. This doesn’t prohibit the use of coding assistance tools, including tool-, AI-, or machine-generated code, as long as these submissions abide by the CLA's requirements.”
It seems to me that this sentence is carefully worded to cover both copyright concerns. If parts of the code you are uploading aren’t copyrightable, then that’s fine, since the CLA covers “any original work of authorship included in the submission”. If parts of the code you are uploading are infringing, then that’s definitely not fine. While we will probably catch it in code review, it’s ultimately up to you as the submitter to abide by the CLA requirements of only sending code you are authorized to send. That is, you are expected not to contribute code owned by others, and AI tooling does not relieve you of that expectation.
Personally, I think the chance of undetected infringement happening is very small. Most CLs are tailored to fit into the existing codebase and involve relatively little code that could plausibly be copied from elsewhere. If you gave the AI tool significant guidance about how to write the code during an interactive development process, it’s extremely unlikely that the tool could find and copy code from elsewhere that fits the bill. In any event, our normal review is already good at catching copying, and we should rely on it to keep doing that.
As a final note, some people may argue that every line produced by an AI tool is somehow tainted by having been trained on copyrighted material, including other open source repositories. Google’s policy allows the use of AI tools, as do many other companies, which suggests that they believe there is not much risk of this argument holding up. Eventually the legal system will decide this legal debate, and we are not experts in copyright law. What matters for Go is that Google’s policy permits the use of these tools. (As a vendor of a few such tools, Google obviously has a vested interest in their legality. This list is not the place for that legal debate.)
Finally, if you are fascinated by these legal issues and want to read more, one jumping off point full of other references is “Talkin' 'Bout AI Generation”, published in the Journal of the Copyright Society last year. But again, please keep that broader discussion off this list.
Co-Authored-By
Finally, for the very specific question of whether to accept Co-Authored-By lines in commit messages, I think we should say no and ask people to remove those lines if we see them in CLs.
To start with, those lines are legally confusing. This thread started with Ian asking whether we need a CLA covering the AI “authors”. As I mentioned above, it is currently legally impossible in the U.S. for an AI tool to “author” code for copyright purposes. We shouldn’t muddy the waters with Co-Authored-By lines that pretend otherwise.
Of course, if we felt the lines added software engineering value to our repository history, we could decide to include them anyway. But on closer inspection, they carry almost no information content. If I write the code myself and then ask a tool to take care of the git incantations to make a commit, a Co-Authored-By line that the tool adds is arguably misleading. If I let a tool write most of the code and then write the commit message myself (without the line), then that’s arguably misleading as well. In the middle of these two extremes, perhaps I write most of the code myself and use the tool for wordsmithing comments. Or perhaps I let the tool write the first working draft and then I substantially rewrite it to clean it up and make it suitable for long-term maintenance. None of this nuance is captured in that one line. Also, the tools can be inconsistent—even during a single session—about whether they include such a line. The result is that the line is almost entirely meaningless.
As far as I can tell the only purpose of the line is to provide free advertising to the companies making coding tools. Let’s not.
(In return, I promise not to add ‘Co-Authored-By: acme’ to all my CLs.)
Conclusion
To wrap up, I think we need to focus on our overall approach to software engineering and treat AI as a tool. A powerful tool, a new kind of tool, but still a tool. At a high level, what we expect from contributors, reviewers, or maintainers is not changing, although some expectations we have taken for granted may need to be made more explicit. As a group, we—The Go Authors—already make different choices about what editors, debuggers, profilers, and other tools we use when we work together on Go. It is fine for us to make different choices about AI tools as well. But we should also be clear with each other and with all contributors that no matter what tools anyone chooses, all the usual expectations and responsibilities remain.
That’s a very long response, but I hope it is helpful.
Best,
Russ
robert engels
On Feb 12, 2026, at 11:25 AM, Russ Cox <r...@golang.org> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/CAA8EjDTuHB8RCHJPzdKOSfvrjqDof4DN8HTwtNpLvDUTXb4-wA%40mail.gmail.com.