Define policy forbidding use of AI code generators

I wonder whether the motivation is really legal? I get the sense that some projects are just sick of reviewing crap AI submissions

This could honestly break open source, with how quickly you can generate bullshit, and how long it takes to review and reject it. I can imagine more projects going the way of Android where you can download the source, but realistically you can't contribute as a random outsider.

Quality contributions to OSS are rare unless the project is huge.

I've always thought that the possibility of forking the project is the main benefit to open-source licensing, and we know Android can be forked.

Historically the opposite of quality contributions has been no contributions, not net-negative contributions (random slop that costs more in review than it provides benefit).

i mean they say the policy is open for revision and it's also possible to make exceptions; if it's an excuse, they are going out of their way to let people down easy

the primary benefit of open source is freedom

I'm not sure which way AI would move the dial when it comes to the median submission. Humans can, and do, make some crap code.

If the problem is too many submissions, that would suggest there needs to be structures in place to manage that.

Perhaps projects receiving lage quanties of updates need triage teams. I suspect most of the submissions are done in good faith.

I can see some people choosing to avoid AI due to the possibility of legal issues. I'm doubtful of the likelihood of such problems, but some people favour eliminating all possibly over minimizing likelihood. The philosopher in me feels like people who think they have eliminated the possibility of something just haven't thought about it enough.

The policy is concise and well bounded. It seems to me to assert that you cannot safely assign attribution of authorship of software code that you think was generated algorithmically.

I use the term algorithmic because I think it is stronger than "AI lol". I note they use terms like AI code generator in the policy, which might be just as strong but looks to me as unlikely to becoming a useful legal term (its hardly "a man on the Clapham omnibus").

They finish with this, rather reasonable flourish:

"The policy we set now must be for today, and be open to revision. It's best to start strict and safe, then relax."

No doubt they do get a load of slop but they seem to want to close the legal angles down first and attribution seems a fair place to start off. This play book looks way better than curl's.

This is so tautological that I can't really tell what point you're trying to make.

> If the problem is too many submissions, that would suggest there needs to be structures in place to manage that. > Perhaps projects receiving lage quanties of updates need triage teams. I suspect most of the submissions are done in good faith.

This ignores the fact that many open source projects do not have the resources to dedicate to a large number of contributions. A side effect of LLM generated code is probably going to be a lot of code. I think this is going to be an issue that is not dependent on the overall quality of the code.

Barrier of entry, automated submissions are two aspects I see changing with AI. You at least have to be able to code before submitting bad code.

With AI you're going to get job hunters automating PRs for big name projects so they can stick the contributions in their resume.

No it hasn't? Net-negative contributions to open source have been extremely common for years, it's not like you need an LLM to make them.

how can it possibly be tautological? The comment just above me said something entirely different: that the primary benefit of open source is forking

Have you seen how Monsanto enforces their seed right?

I have an online acquaintance that maintains a very small and not widely used open-source project and the amount of (what we assume to be) automated AI submissions* they have to wade through is kinda wild given the very small number of contributors and users the thing has. It's gotta be clogging up these big projects like a DDoS attack.

*"Automated" as in bots and "AI submissions" as in ai-generated code

Possibly, but QEMU is such a critical piece software in our industry. Its application stretches from one end to the other - desktop VM, cloud/remote instance, build server, security sandbox, cross-platform environment, etc. Even a small legal risk can hurt the industry pretty badly.

I guess we've had very different experiences!

For many projects you realistically can't contribute as a random outsider anyway, simply because of the effort involved in grokking enough of the existing architecture to figure out where to make changes.

I thought that this could be an opportunity for volunteers who can't dedicate the time to learn a codebase thoroughly enough to be a regular committer. They just have to evaluate a patch to see if it meets a threshold of quality where they can pass it on to someone who does know the codebase well.

The barrier to being able to do a first commit on any project is usually quite high, there are plenty of people who would like to contribute to projects but cannnot dedicate the time n effort to pass that initial threshold. This might allow people an ability to contribute at a lower level while gently introducing them to the codebase where perhaps they might become a regular contributer in the future.

I think it is yet another reason (potentially malicious contributors are another) that open source projects are going to have to verify contributors.

I find that by being on codeberg instead of github i tune out a lot of the noise.

Nah. I've had a lot of bad contributions. One PR deleted and readded all of the lines in the project, and the entire test suite was failing.

The person got upset at me for saying I could not accept such a thing.

There's other examples.