Here is the proposed addition for the ToU that @Gusted and I agreed on post-assembly for the upcoming membership vote. 🙏
The discussion for this proposal is available for Codeberg e. V. members in the forum: https://forum.codeberg.org/d/139-resolutions-for-assembly-on-codeberg-taking-a-stand-a...
Yeah, this makes sense. They won’t be able to kick every vibecoded project off, but it gives them a rule to point to when they do find and remove slop.
Some of the commenters on the Codeberg issue are expressing concerns about copyright status, but my main concern is security issues with these projects, which I have expressed before. Somebody vibecoded a script to sort files? I don’t really care.
Someone vibecoded a network facing application, shipping a docker container, and is trying to encourage people to deploy it? If I investigate, and see the bad security practices common to vibecoding, I wouldn’t want to be providing that for people to download. Even though I’m technically not responsible for it, it just doesn’t feel right to host something that could explode later. I would want to be able to take it down, and having a rule to point to prevents complaints when Codeberg does so.
while I agree with the sentiment. what if someone just sloppily hand-coded an insecure docker container, should you be able to kick that off too? I fear security isn’t a good baseline to decide if a project should be hosted because security is a gradient and it becomes very subjective to say what constitutes secure. following that, would you give remediation opportunities for hand-coded insecure projects? It’s a can of worms.
I would argue that they can argue it purely from a capacity perspective.
They can estimate the scale of handwritten code growing over a period of time, but not the scale of AI written code scaling, meaning their platform cannot anticipate the scale and therefore it is unsustainable. And at that point the scale of security awareness as a whole can be considered, e.g. “how many attack surfaces, e.g. repos, are we hosting?” vs “how many of our repos are insecure?”
what if someone just sloppily hand-coded an insecure docker container, should you be able to kick that off too?
I can talk to them and have them fix it without them being weird about it. But if they don’t understand the poor design decisions in the first place then I have no confidence won’t be able to actually fix it, and keep it fixed in the future.
It’s fuzzy, and many generalizations are gonna be made.
Ultimately, it really comes down to human judgement and not your instance not your rules. They are hosting for free. They don’t have any obligation to host your projects. The rules and everything are nice conventions, and a good attempt at transparency, but at the end of the day, there is someone with access to the admin panel who is going to make the decisions, and you’re not really going to be able to do anything about them.
It’s the same thing with lemmy tbh, although it’s less annoying because it’s much easier to self host and migrate to Forgejo, as opposed to hosting Lemmy. That’s why I phrased it as “I would feel uncomfortable hosting this content” rather than trying to address the fuzzier arguments about the necessity of human judgement, the difficulty of detecting LLM generated code, or the possibility of incorrectness.
Yeah, this makes sense. They won’t be able to kick every vibecoded project off, but it gives them a rule to point to when they do find and remove slop.
Some of the commenters on the Codeberg issue are expressing concerns about copyright status, but my main concern is security issues with these projects, which I have expressed before. Somebody vibecoded a script to sort files? I don’t really care.
Someone vibecoded a network facing application, shipping a docker container, and is trying to encourage people to deploy it? If I investigate, and see the bad security practices common to vibecoding, I wouldn’t want to be providing that for people to download. Even though I’m technically not responsible for it, it just doesn’t feel right to host something that could explode later. I would want to be able to take it down, and having a rule to point to prevents complaints when Codeberg does so.
while I agree with the sentiment. what if someone just sloppily hand-coded an insecure docker container, should you be able to kick that off too? I fear security isn’t a good baseline to decide if a project should be hosted because security is a gradient and it becomes very subjective to say what constitutes secure. following that, would you give remediation opportunities for hand-coded insecure projects? It’s a can of worms.
I would argue that they can argue it purely from a capacity perspective.
They can estimate the scale of handwritten code growing over a period of time, but not the scale of AI written code scaling, meaning their platform cannot anticipate the scale and therefore it is unsustainable. And at that point the scale of security awareness as a whole can be considered, e.g. “how many attack surfaces, e.g. repos, are we hosting?” vs “how many of our repos are insecure?”
I can talk to them and have them fix it without them being weird about it. But if they don’t understand the poor design decisions in the first place then I have no confidence won’t be able to actually fix it, and keep it fixed in the future.
It’s fuzzy, and many generalizations are gonna be made.
Ultimately, it really comes down to human judgement and not your instance not your rules. They are hosting for free. They don’t have any obligation to host your projects. The rules and everything are nice conventions, and a good attempt at transparency, but at the end of the day, there is someone with access to the admin panel who is going to make the decisions, and you’re not really going to be able to do anything about them.
It’s the same thing with lemmy tbh, although it’s less annoying because it’s much easier to self host and migrate to Forgejo, as opposed to hosting Lemmy. That’s why I phrased it as “I would feel uncomfortable hosting this content” rather than trying to address the fuzzier arguments about the necessity of human judgement, the difficulty of detecting LLM generated code, or the possibility of incorrectness.