Proposed KDE LLM guidelines (#187) · Issues · Plasma / Plasma Workspace · GitLab
invent.kde.org
This is a continuation of this mailing list thread about "fully LLM-generated merge requests, preserved at https://mail.kde.org/pipermail/kde-devel/2026-September/004496.html There, I proposed...

Example of a KDE dev not wanting environmental concerns to play any role, despite KDE having an environmental project:

Devs rejecting any notion of transparency by disclosing AI usage in code submissions (in direct opposition to advice from the FSFE):

And all of this is coming right after the debacle with an AI slop project being allowed to give a presentation at Akademy, and the person asking how this was allowed being blocked by KDE:

https://lemmy.nz/post/42029517

as well as the discussion thread bringing up legitimate concerns about AI usage being closed:

https://discuss.kde.org/t/sorry-to-bring-up-a-contentious-topic-kde-ai-llm-policy/46333/164

As someone who genuinely loves KDE, and has even donated to the project multiple times, I sadly have to accept that the majority of KDE have hopped onto the Pro-AI train, and they will not be dissuaded otherwise.

  • tyler@programming.dev
    0·
    8 hours ago

    what can they do despite ban LLM usage altoguether (and per consequence get LLM generated code submitted anyway), they can’t have a blacklist for models, or force contributors to run them on their local hardware.

    But they can? Like OP pointed out, wine forbids contributions from those that have seen Windows source code. How in the world are they supposed to enforce that? Turns out the open source community is pretty good at self enforcing.

    • Richard@lemmy.world
      0·
      8 hours ago

      I don’t think the average person who wants to contribute to wine has seen windows source code in the first place.

      It is much easier to attempt on enforcing something like this that to enforce a full ban on AI. The problem is that AI has a much higher exposure rate than the windows source code.