I'm not sure I understand you dilemma. The point of open source was always so that you could modify, customize, and make derivatives. The main objection to old closed source unix software was that you *couldn't* do this, which made it difficult to port, maintain or fine tune for a particular system if the original developer wasn't interested in doing it.
Making it free (gratis) was almost an afterthought. All this stuff around "community" is tertiary at best, and the ideology around it came much later.
So, now LLMs let more people do that than could or would before. They're even less dependent on the developers/maintainers greenlighting a change or feature they want. Devs don't have to worry about the problem of software growing into unmaintainable homermobiles in order to serve every possible use case.
Fork away, I say. Slop away. Add every personal wishlist feature the LLM can give you to everything you ever use. If you can make it work well enough and you want the responsibility, publish it. If the original dev wants, he can merge it. If he doesn't he doesn't even have to think about the impact of saying no. If you want a freakish chimera of different forks, ask claude to fix the merge conflicts and pray.
To the extent any of this works, it can only be good. In the end we all get computers that work better for us as individuals. Wasn't that the idea?
It seems like your concern is that vibeslop makes it easy to steal clout. Speaking honestly, clout is a big part of why we open-source software. Your post is about a fork stealing your project’s thunder: building proprietary software in top of it isn’t even mentioned.
So AGPL is useless. Clout chasing vibeslop forks will just respect the license. Those people do exist, usually they’re in certain parts of the world where job competition is exceptionally brutal and that clout they’re after can feed their kids. They won’t care how you license it, at all.
I think this entire question is a bad place to expend anxiety.
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.
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.
I've come to the conclusion that if I, as an individual, am going to publish open source software, the restrictions of the license are irrelevant. They might prevent a good actor from using my software, but they will never stop a bad actor from using it in the way they please. I recall a conversation with a lawyer at a tech company we both worked for. As an engineer, I was obsessed with building license checking tools that could ensure strict compliance with everything the OSS world could throw at us. The lawyer was more sanguine. Their opinion was that if you try your best, in good faith, to comply but fail, the most likely outcome is that no one will notice. In the rare case someone does care, the remedy is usually correcting your mistake and paying some legal fees. I don't have the deep pockets nor inclination to sue people who violate the terms of the license I apply to my software. If I want to build my cred, I feel it's best to encourage the widest use. I'm pretty much an MIT user these days.
I'm skeptical of AGPL for a completely different reason - I think the behavior of AGPL is unspecified for several important, common use cases. AGPL requires, for instance, that you advertise access to the source code (section 13) to anyone accessing the code over the network. For a web app, that makes perfect sense, but what happens when someone wants to take the IP address parsing code from your network management app and use it in their DNS server? Does every DNS reply need to include a TXT record pointing to a Git repo?
I think AGPL makes sense only for frontend code that is only ever going to live in a frontend, and it's hard to predict in advance if that's true for any given chunk of code. Therefore I avoid AGPL and any other licenses that are underspecified and hard to implement.
I think that you're re-arranging the deck chairs on the Titanic. All open-source projects (and any kind of text, this comment included), present and future, are being given as a gift to AI companies to train their models on, and they don't seem to regard your choice of license with any degree of respect. So whilst you agonise over which license to put on your code and trying to find solutions, LLMs just use it to give others the ability to re-create the code with any license that they choose, if they cared about the original license in the first place. (LLM-laundering?)
It's a sad state of affairs, but if you proceed with this line of thinking what appears at the end of it is closed-source, not a license. That, or you do it for the joy of creating and giving and decide to not be bothered by the outcome.
I think that in the not-too-distant future, people will be asking LLMs to create sort of one-off projects that will solve a particular issue for them, and won't care about sharing this software.
If I personally open source a project I usually choose BSD/MIT style licenses or CC Public Domain if it seems too trivial. Open sourcing the project is my gift to the world hoping it will help or inspire others. If a commercial fork is helping the world, so be it. If an open source fork adds slop features en masse and gains more traction with the user base than my own repo - so be it!
The only thing I dislike and I have seen it recently in some open source projects: A fork is created of a large existing codebase, some (few) much-wanted features are added using AI, but the author of those new features doesn't even attempt to merge them back upstream, just tells users to use his own (slop) fork. To me it's mostly annoying as a user, not immediately as a developer, because I don't want to install his fork. I still want the updates from in the main project, which is in my trust circle (security/quality/longevity) already. As a user, I perceive the fork as lazy and potentially low quality (since it wont put in the effort for a PR & review by upstream). If other users see it similarly to me, such slop forks won't gain much traction in the user base, but may act more as showcases of potential new features.
As for the testsuites - AI can generate better testsuites that humans, at least in the case where test suites need to be comprehensive and hit all the edge cases, if AI is better at those tasks. A robust testsuite is friction against *incorrect* patches, but not *slop* patches. The tool to use against AI slop is... AI patch reviews. If slop is 90% of your influx, and AI can reject 90% of the patches (for legitimate reasons, of course), it's a net win. Note: the goal isn't to reject slop, it's to reject slop that's *wrong*.
I think you've tripped over a key difference between the BSD/MIT license and the GPL - BSD/MIT protects the freedom of the developer, but GPL protects the freedom of the user. The easier it is for bad actors to do bad things with code, the more legal protection you need to give to the end users of that code.
I dont think that friction will work/worth the effort. Especially when people would try to distill your product to a SPEC.md and then clean room reimplement it from scratch.
I also think people will just fork without contributing back. Because getting code review consensus is friction, but vibe fork is frictionless
I'm not sure I understand you dilemma. The point of open source was always so that you could modify, customize, and make derivatives. The main objection to old closed source unix software was that you *couldn't* do this, which made it difficult to port, maintain or fine tune for a particular system if the original developer wasn't interested in doing it.
Making it free (gratis) was almost an afterthought. All this stuff around "community" is tertiary at best, and the ideology around it came much later.
So, now LLMs let more people do that than could or would before. They're even less dependent on the developers/maintainers greenlighting a change or feature they want. Devs don't have to worry about the problem of software growing into unmaintainable homermobiles in order to serve every possible use case.
Fork away, I say. Slop away. Add every personal wishlist feature the LLM can give you to everything you ever use. If you can make it work well enough and you want the responsibility, publish it. If the original dev wants, he can merge it. If he doesn't he doesn't even have to think about the impact of saying no. If you want a freakish chimera of different forks, ask claude to fix the merge conflicts and pray.
To the extent any of this works, it can only be good. In the end we all get computers that work better for us as individuals. Wasn't that the idea?
It seems like your concern is that vibeslop makes it easy to steal clout. Speaking honestly, clout is a big part of why we open-source software. Your post is about a fork stealing your project’s thunder: building proprietary software in top of it isn’t even mentioned.
So AGPL is useless. Clout chasing vibeslop forks will just respect the license. Those people do exist, usually they’re in certain parts of the world where job competition is exceptionally brutal and that clout they’re after can feed their kids. They won’t care how you license it, at all.
I think this entire question is a bad place to expend anxiety.
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.
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.
I've come to the conclusion that if I, as an individual, am going to publish open source software, the restrictions of the license are irrelevant. They might prevent a good actor from using my software, but they will never stop a bad actor from using it in the way they please. I recall a conversation with a lawyer at a tech company we both worked for. As an engineer, I was obsessed with building license checking tools that could ensure strict compliance with everything the OSS world could throw at us. The lawyer was more sanguine. Their opinion was that if you try your best, in good faith, to comply but fail, the most likely outcome is that no one will notice. In the rare case someone does care, the remedy is usually correcting your mistake and paying some legal fees. I don't have the deep pockets nor inclination to sue people who violate the terms of the license I apply to my software. If I want to build my cred, I feel it's best to encourage the widest use. I'm pretty much an MIT user these days.
I'm skeptical of AGPL for a completely different reason - I think the behavior of AGPL is unspecified for several important, common use cases. AGPL requires, for instance, that you advertise access to the source code (section 13) to anyone accessing the code over the network. For a web app, that makes perfect sense, but what happens when someone wants to take the IP address parsing code from your network management app and use it in their DNS server? Does every DNS reply need to include a TXT record pointing to a Git repo?
I think AGPL makes sense only for frontend code that is only ever going to live in a frontend, and it's hard to predict in advance if that's true for any given chunk of code. Therefore I avoid AGPL and any other licenses that are underspecified and hard to implement.
I think that you're re-arranging the deck chairs on the Titanic. All open-source projects (and any kind of text, this comment included), present and future, are being given as a gift to AI companies to train their models on, and they don't seem to regard your choice of license with any degree of respect. So whilst you agonise over which license to put on your code and trying to find solutions, LLMs just use it to give others the ability to re-create the code with any license that they choose, if they cared about the original license in the first place. (LLM-laundering?)
It's a sad state of affairs, but if you proceed with this line of thinking what appears at the end of it is closed-source, not a license. That, or you do it for the joy of creating and giving and decide to not be bothered by the outcome.
I think that in the not-too-distant future, people will be asking LLMs to create sort of one-off projects that will solve a particular issue for them, and won't care about sharing this software.
If I personally open source a project I usually choose BSD/MIT style licenses or CC Public Domain if it seems too trivial. Open sourcing the project is my gift to the world hoping it will help or inspire others. If a commercial fork is helping the world, so be it. If an open source fork adds slop features en masse and gains more traction with the user base than my own repo - so be it!
The only thing I dislike and I have seen it recently in some open source projects: A fork is created of a large existing codebase, some (few) much-wanted features are added using AI, but the author of those new features doesn't even attempt to merge them back upstream, just tells users to use his own (slop) fork. To me it's mostly annoying as a user, not immediately as a developer, because I don't want to install his fork. I still want the updates from in the main project, which is in my trust circle (security/quality/longevity) already. As a user, I perceive the fork as lazy and potentially low quality (since it wont put in the effort for a PR & review by upstream). If other users see it similarly to me, such slop forks won't gain much traction in the user base, but may act more as showcases of potential new features.
As for the testsuites - AI can generate better testsuites that humans, at least in the case where test suites need to be comprehensive and hit all the edge cases, if AI is better at those tasks. A robust testsuite is friction against *incorrect* patches, but not *slop* patches. The tool to use against AI slop is... AI patch reviews. If slop is 90% of your influx, and AI can reject 90% of the patches (for legitimate reasons, of course), it's a net win. Note: the goal isn't to reject slop, it's to reject slop that's *wrong*.
I think you've tripped over a key difference between the BSD/MIT license and the GPL - BSD/MIT protects the freedom of the developer, but GPL protects the freedom of the user. The easier it is for bad actors to do bad things with code, the more legal protection you need to give to the end users of that code.
I dont think that friction will work/worth the effort. Especially when people would try to distill your product to a SPEC.md and then clean room reimplement it from scratch.
I also think people will just fork without contributing back. Because getting code review consensus is friction, but vibe fork is frictionless