Most contributors tend to follow the rules of a project. Some will skirt them, some AI code will probably get in, but a ban will certainly limit it, and certainly look better in court compared to "We made it a rule that it's okay to not disclose that you used the likely copyrighted code generator".

Take for example the WINE project, which has a strict ban on anyone who has seen the Windows source code from contributing to the project (such as an ex-employee or someone who has seen the source code from a leak). This is obviously impossible to enforce; how could they reasonably prevent a microsoft employee from submitting code that might be infringing on Microsoft? They can't. But their ban will certainly aid them in court if MS ever did sue them for infringement. and I think it likely anyone who had seen the source code and wanted to add a patch would respect the rule. It's not perfect protection, but it's certainly better than "If you submit windows source code, just don't tell us, and hopefully we won't get in trouble".

i think the break down of trust, the perception of reality and destruction of communities has been greatly underestimated when it comes to AI (or it was deliberate, better put my tinfoil hat back on...)

even more so when there's no way of knowing how many of those pro-AI voices are even real people

That was a very good read, thank you for sharing it

Seconding Cris, that was a fantastic read.

The burden of proof from this angle unfairly rested on an "accuser", not "the accused". This mirrors many justice systems, but a PR being rejected is not equivalent to imprisonment or a fine or death. It's a mild social consequence, equivalent to saying "no thanks" to someone handing out flyers for a show at the Edinburgh fringe or leaflets of strange local religious sect.

Wow. The sheer gall.

I think had KDE's policy proposal limited LLM use to just finding bugs, but prohibited using it for code, there would've been much less uproar. However even that would still likely encourage corporate AI use to find those bugs, which brings with it

I agree Niri doesn't have a usable anti LLM policy as of today. But there are still other desktops!

E.g. the river compositor has this policy: https://codeberg.org/river/river#strict-no-llm-no-ai-policy

Use of generative AI/LLMs is strictly forbidden for all contributions to river.

This includes bug reports and comments on the issue tracker.

Since Vim moved to accept llm output, Drew DeVault maintains a fork called Vim Classic

There is a no AI vim fork, "evi": https://codeberg.org/evi-editor/evi

And a no AI tmux fork, "opentmux": https://codeberg.org/opentmux/opentmux

And a no AI keepass fork, "ChiPass": https://codeberg.org/ChiPass/ChiPass/

I'm not aware of any major project forks due to it, only smaller ones, such as this fork of Waybar that was specifically forked to remove the AI code added to the main project.

Forking the bigger projects would be a pretty huge effort. If enough left at once it could be viable, or perhaps a fork could be cut down to make it more manageable to maintain and develop for a smaller team.

If there is no forks, maybe the dissenters from the major projects will congregate toward independent projects who have already taken a stand against AI.

There is a system to identify frequent contributors, they used it to send mails for the KDE goals vote. I feel like if there was some sort of vote that it should probably use that to identify the votes of contributors.

Are you suggesting I made this initiative?