I think AI is pushing me toward the AGPL
Why agentic coding changes everything for the open-source craft and maintainership
It has been two months since I’ve been using AI coding agents “for real”. In my previous article, I reflected on my experiment to vibe-code a full Emacs module from scratch. In there, I intentionally left one important question unanswered: what is the meaning and impact of agentic coding on the free software ecosystem we have all grown accustomed to?
Right now, I have many thoughts but no good answers, and the reason is that the more I use these tools, the more I doubt my long-held beliefs about open-source licensing. While I’ve found that agentic coding makes me more productive—provided I supervise the agents carefully, in some circumstances—it also distances me from the act of coding itself, stripping away the pride of craftsmanship and thus the desire to publish code as open source.
The bigger worry, however, is for the ecosystem as a whole. Let’s dive into what’s on my mind right now.
A little history
I’ve been into open source for almost 30 years now. My first exposure to the ecosystem was the FIPS utility, which I had to use to install my first Linux distribution (Caldera OpenLinux 1.1 if you are wondering). To young-me, a 13-year old interested in low-level software and having only been exposed to Windows and OS/2, having full access to the source code of a frigging disk manipulation tool and even a full OS was mind-blowing.
From that moment on, I took the GPLv2 to heart because access to this ecosystem, vast in size and completely free, felt like a gift. I started publishing my own code as free software, licensed under the GPLv2, and I quickly got involved into existing projects. Not too long after, I joined NetBSD “full-time” because I found in it the perfect balance of “a system that worked well-enough for my day-to-day needs but that had plenty of room for contributions”.
As I continued to encroach myself in the BSD ecosystem, I was exposed to many… “discussions” comparing the GPL against BSD-like licenses. I came out believing that the GPL was more restrictive than the BSD licenses because it imposed extra limitations on consumers. As outreach was the (my) goal, I was all-in on licensing my code via BSD-like licenses. Until maybe now.
Friction no more
If you ask a modern AI agent to work within the constraints of an established project, you will realize that the agent’s output follows the architecture and coding style of the project extremely closely. The diffs I get back are really similar to what I’d have written by hand. But… even if you don’t prompt the right way, you still get features that work. Slop, probably, but still functional. And that’s what’s rubbing me the wrong way with regards to open source licensing.
In the past, when you published a piece of free software, you knew there was some risk that someone could take your code and selfishly benefit from it. But, for the most part, taking a project and modifying it in a way that provided value to users required significant effort. If someone wanted to build on your project and then redistribute it, they had to spend the time to change it and they had to reason about the consequences of their changes, the project’s license, and their own long-term maintenance efforts.
With AI? All of that seems gone. It’s just too easy for anyone to pick an existing project, run it through an agent to customize, fork, and ship it out. Zero need for any real time investment. Zero consideration for what was there in the first place. Zero need to worry about future maintenance because agents will just pile onto whatever they did before and, to users, it will all seem to work.
So, here I am, starting to question my long-held thoughts on copyleft licenses. As I said above in my personal story, I grew up believing that BSD licenses were the better choice for true software freedom. But now? Is it really a good idea to ship BSD-like licensed code anymore? The chances of a slop fork happening are way too real, and the consequences dire: after all, said fork will be able to display tons more features with ease, gain traction, and the pressure against upstream to “do something about them, quickly!” will be a thing. Left unattended, any interest and community around the original project may vanish.
And the reason I’m writing this article is because there is this disturbing thought in my mind right now: should I flip 180 degrees and start licensing my future code as… no less than the “evil” AGPLv3? I have usually avoided this license, but it sounds like it is the only chance at protecting projects from slop (commercial) forks.
Contribution doubts
But then what? Suppose you publish your project as AGPLv3. Suppose a downstream consumer forks the project and starts building on top of it with immense velocity thanks to AI agents. And suppose they have no problem with keeping the project open source per the license. Their changes may be slop, but they may be delivering features that users have wanted for a long time—and let’s face it, the vast majority of people have little consideration for software quality or performance.
In this situation, as the upstream, what do you do? Do you try to incorporate the vibe-coded changes with the massive effort that this requires? Or do you ignore them and hope that they go away, collapsing under their own complexity weight? The truth, I suspect, is that they won’t go away, so you as upstream may become irrelevant very quickly unless you can keep up with the “contributions” being made. Whether you care or not depends on why you published your code as free software in the first place, and different authors have different motivations.
So what else can you do? Maybe you make the project’s test suites proprietary and keep them secret. In an AI-powered world, test suites are THE secret sauce to keep agents on track, so if you don’t publish yours, slop forks will have a hard(er) time staying aligned with upstream. Unfortunately, keeping test suites secret is logistically difficult and annoying, plus it goes against the very tenets of a free software project.
No easy choices here…
What do you think?
I have several more thoughts on the topic of AI and how it affects open source, particularly regarding contributions and the feeling that they can easily lead to burnout, but in this article I wanted to focus purely on the licensing choices. I want to close this not with answers, but with a recap of the questions that would be nice to discuss:
If AI can closely mimic your architecture with zero effort, does the “friction of modification” need to be replaced by the legal friction of the AGPL?
Is keeping test suites proprietary a legitimate “moat” for human maintainers, or does it violate the core spirit of open source?
If we accept that AI agents are a tool and that, properly guided, can produce good PRs at an overwhelming rate, how do we keep up with contributions?
If you end up vibe-coding most of a project, does it even make sense to open-source it? Why? What pride is there in that?
Share your thoughts in the comments section!
And for the last bit... Aside from the problem of copyright status of AI-generated works, you still have put effort into the process,and perhaps some fraction of the code is legitimately yours and copyrightable. Claiming copyright and license of "parts that I can" protects your work, and your users, and allows for a future legal change where humans may claim copyright over AI works. I think the trick will be to come up with the right phrasing for the "parts that I can" part.
What this will actually do for a lot of people is just make them not want to write open source code at all, and who could blame them? Who in their right mind would want to publish their projects that will serve far more as LLM training fuel than something other humans will actually use and contribute back to?
You probably already noticed by now that licensing hasn't stopped those who put all their chips into code slopping. Look at what happened with Chardet, the v7.0.0 guys committed the equivalent of dirty reverse engineering and shamelessly slapped the MIT license in place of the GPL. The legal protections around open source code across the world are already pretty damn weak, which is what gives these hacks so much hubris.
Unless some big changes to the legality of slop code come in a way that will prevent blatant abuses of copyright (and copyleft) as outlined above, expect a lot of developers to start embracing proprietary software like it's the 1980s and 1990s again.