Disallow or discourage use of "AI" tools (Christoph Cullmann)

[Alexander Potashev]

Hi Benson, (everyone,)

> Code contributions made using AI trained on unknown data is problematic.

Is this purely a legal/intellectual property concern?


If we can generalize this concern as

    "a contributor submits code incompatible with the project's license,
thus breaching the license"

, not only AI may put the project in trouble. It can be at least one of
these scenarios:
 1. The code the contributor submitted was generated by AI and originates
from e.g. another open source project distributed under an incompatible
license.
 2. The contributor steals proprietary code and submits it to an open
source project (no AI involved).

By banning the use of AI, you don't fully solve the legal risk.


On Thu, May 15, 2025 at 7:08 PM Benson Muite <benson_muite at emailplus.org>
wrote:

>
> Code contributions made using AI trained on unknown data is problematic.
> KDE does also create a lot of data that could be used to improve KDE. It
> may be good to see if AI or ML tools could use some of this data to improve
> KDE in an ethical manner.
>
> On Thu, May 15, 2025, at 5:09 PM, Felix Ernst wrote:
> > Late reply, but I also wanted to mention that I am 100% in support of
> > any anit-AI messaging and policies we might choose.
> >
> > The wording as linked by Akseli in their first post seems like a good
> > starting point in that regard:
> >
> >>Other projects have already done something similar, see for example:
> https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
> >
> > The only use of AI I support needs all its training data to be licenced
> > in a way that allows use for the AI training e.g. CC0 or WTFPL licence.
> > This way I don't see ethical issues because the copyright holders have
> > then given some sort of consenst for this use.
> >
> > I wouldn't even mind if we went one step further and actively promoted
> > e.g. Plasma as "free of AI". This does not need to be fully true, but
> > this would be more of an activism and marketing angle I would like to
> > see. There is a good chance though that this would not be a good use of
> > our time but it would align with KDE Eco IMO. (I know that there are
> > also great uses of AI, but public messaging needs to be clear and easy
> > to understand, and there is still enough pro-AI marketing out there to
> > the point that taking the opposite stance seems sensible to me.)
> >
> > Have a nice week!
> > Felix
> >
> >  > Date: Tue, 13 May 2025 09:22:22 +0930
> >  > From: Justin Zobel <justin at 1707.io>
> >  >
> >  > I am 100% for this. Most AI tools just scrape (read: steal) code
> > from
> >  > whatever source they can, with no attribution or consideration for
> > legal
> >  > rights/copyright.
> >  >
> >  > Accepting any AI generated code is a legal risk unless the source of
> > the
> >  > code can be verified.
> >  >
> >  > I would wager 99.999% of people using AI tools wouldn't know what
> > the
> >  > source of the code is, or how it is licensed.
> >  >
> >  > On 12/05/2025 22:23, Akseli wrote:
> >  > > Hi
> >  > >
> >  > > There's been a lot of "AI" slop spam to various KDE projects, bug
> > reports, forums, etc..
> >  > >
> >  > > We should take a more public stance on disallowing all this slop.
> > Lengthy gitlab issues that are just full of nonsense generated by a bot
> > just take time out of everyones schedules, trying to decipher if its
> > serious or not.
> >  > >
> >  > > Other projects have already done something similar, see for
> > example:
> https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
> >  > >
> >  > > I don't care if someone uses those tools in their personal
> > projects, but bringing this slop in to our shared space just frustrates
> > people and eats resources to go through.
> >  > >
> >  > > Can we have somekind of official "please don't AI slop in our
> > places" sign somewhere?
> >  > >
> >  > > Thanks,
> >  > > - Akseli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250515/084db9b9/attachment.htm>