Looking for advice on how to deal with potential slop packages

Looking for advice on how to deal with potential slop packages

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3690 bytes --]

Hello, everyone.

Seeing more and more packages embracing LLM-driven development (to the
point of "vibe coding" or slopware), I'm looking for your ideas on how
distributions should deal with that.  I'm basically torn between three
things:

1. My duty towards the users to deliver up-to-date versions of software.

2. My duty towards the users to deliver *good* and *secure* software.

3. My ethical concerns, both directly related to LLM use, and to what
people are using them for.


As you may recall, Gentoo has already a strong policy prohibiting "AI"
contributions [1].  However, this policy applies merely to contributions
to the Gentoo projects themselves, and it does not affect the software
we package.  In fact, compared to binary distributions, Gentoo has had
rather relaxed approach to what's acceptable, that could be summarized
as "as long as it's not outright malicious and somebody is going to
maintain the package".  But over time, I'm having more and more concerns
about the state of FLOSS in general.


The first really doubtful case I've hit was the autobahn project.  I've
learned that it started using LLM-backend coding after it had a series
of releases with *really weird* issues (like "how that could even
happen?!" kind of issues) [2,3,4], and my bug reports were met with lots
of AI slop generated replies, and pull requests that were also complete
slop.  I've eventually called the problem out, and upstream pretty much
lashed at me [5].  Since then, I haven't pushed any new autobahn
versions.  While the issues I've hit were largely related to packaging,
I have no reason to believe that the actual code is any better.  So this
is a case of rejecting slop on basis of low quality.

The second big issue which you probably heard of is one of the
maintainers of chardet using an LLM to rewrite the code while erasing
the original autorship and changing the license, and then being an
asshole about it [6] (you don't want to read that thread, it's complete
shitshow with almost everyone cosplaying lawyers).  Here the primary
concern is copyright and ethics, but it also makes you wonder what the
actual code quality is.

Of course there are just two examples.  There is a lot of projects using
LLMs to various degree, and raising different concerns.  On the other
hand, I feel like a lot of these concerns existed before already, and it
is just that we previously didn't pay attention that much.  I mean, it's
easier to say "they're using an LLM, it must be slop" than actually
inspect the code and say "it's really bad quality".  And people were
being assholes long before LLMs.


What are your experiences, thoughts and ideas how to deal with this?  I
mean, staying on old software versions and hoping people will change
their minds (or more precisely, LLMs will stop being subsidized and
people will have to start paying serious money for their usage) is not
exactly a good idea.  Going around and telling people "please switch
from dependency X to Y because X is slop (and Y isn't yet)" doesn't
sound like the best use of our time either.  And forking?  With the
depressing state of FLOSS these days, I can't even find energy to
maintain my own projects, let alone take anything else.


[1] https://wiki.gentoo.org/wiki/Project:Council/AI_policy
[2] https://github.com/crossbario/autobahn-python/issues/1716
[3] https://github.com/crossbario/autobahn-python/issues/1735
[4] https://github.com/crossbario/autobahn-python/issues/1782
[5] https://github.com/crossbario/autobahn-python/discussions/1818
[6] https://github.com/chardet/chardet/issues/327

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Noé Lopez]

[-- Attachment #1: Type: text/plain, Size: 4726 bytes --]

Michał Górny <mgorny@gentoo.org> writes:

> Hello, everyone.
>
> Seeing more and more packages embracing LLM-driven development (to the
> point of "vibe coding" or slopware), I'm looking for your ideas on how
> distributions should deal with that.  I'm basically torn between three
> things:
>
> 1. My duty towards the users to deliver up-to-date versions of software.
>
> 2. My duty towards the users to deliver *good* and *secure* software.
>
> 3. My ethical concerns, both directly related to LLM use, and to what
> people are using them for.
>
>
> As you may recall, Gentoo has already a strong policy prohibiting "AI"
> contributions [1].  However, this policy applies merely to contributions
> to the Gentoo projects themselves, and it does not affect the software
> we package.  In fact, compared to binary distributions, Gentoo has had
> rather relaxed approach to what's acceptable, that could be summarized
> as "as long as it's not outright malicious and somebody is going to
> maintain the package".  But over time, I'm having more and more concerns
> about the state of FLOSS in general.
>
>
> The first really doubtful case I've hit was the autobahn project.  I've
> learned that it started using LLM-backend coding after it had a series
> of releases with *really weird* issues (like "how that could even
> happen?!" kind of issues) [2,3,4], and my bug reports were met with lots
> of AI slop generated replies, and pull requests that were also complete
> slop.  I've eventually called the problem out, and upstream pretty much
> lashed at me [5].  Since then, I haven't pushed any new autobahn
> versions.  While the issues I've hit were largely related to packaging,
> I have no reason to believe that the actual code is any better.  So this
> is a case of rejecting slop on basis of low quality.
>
> The second big issue which you probably heard of is one of the
> maintainers of chardet using an LLM to rewrite the code while erasing
> the original autorship and changing the license, and then being an
> asshole about it [6] (you don't want to read that thread, it's complete
> shitshow with almost everyone cosplaying lawyers).  Here the primary
> concern is copyright and ethics, but it also makes you wonder what the
> actual code quality is.
>
> Of course there are just two examples.  There is a lot of projects using
> LLMs to various degree, and raising different concerns.  On the other
> hand, I feel like a lot of these concerns existed before already, and it
> is just that we previously didn't pay attention that much.  I mean, it's
> easier to say "they're using an LLM, it must be slop" than actually
> inspect the code and say "it's really bad quality".  And people were
> being assholes long before LLMs.
>
>
> What are your experiences, thoughts and ideas how to deal with this?  I
> mean, staying on old software versions and hoping people will change
> their minds (or more precisely, LLMs will stop being subsidized and
> people will have to start paying serious money for their usage) is not
> exactly a good idea.  Going around and telling people "please switch
> from dependency X to Y because X is slop (and Y isn't yet)" doesn't
> sound like the best use of our time either.  And forking?  With the
> depressing state of FLOSS these days, I can't even find energy to
> maintain my own projects, let alone take anything else.
>
>
> [1] https://wiki.gentoo.org/wiki/Project:Council/AI_policy
> [2] https://github.com/crossbario/autobahn-python/issues/1716
> [3] https://github.com/crossbario/autobahn-python/issues/1735
> [4] https://github.com/crossbario/autobahn-python/issues/1782
> [5] https://github.com/crossbario/autobahn-python/discussions/1818
> [6] https://github.com/chardet/chardet/issues/327
>
> -- 
> Best regards,
> Michał Górny

Hi Michał,

Contributor for GNU Guix here. This same topic is bringing up a lot of
dicussion too.

In my point of view, an easier starting point is to know if
LLM-generated code can be free software or not.

If one can conclusively say that LLM-generated code is not free
software, then we can relegate these projects to the nonfree channels
where they can live their best slop-life with their proprietary friends.

For me, that would be the best outcome.

This is also important community-wise, so that existing free software
projects don’t start using slop libraries, at which point it will be
harder and harder to maintain a completely free system.

I also imagine that LLM-generated software will break compatibility very quickly
with older versions so it will be pretty hard to keep previously free libraries.

Good day,
Noé

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Morten Linderud]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

A lot of this is probably already a lost cause I think.

Linux accept LLM contributions (look for the `Assisted-by` tags), and there are
already multiple subsystems that are being developed in-part, or full, by LLM
agents.

See the LWN discussion: https://lwn.net/Articles/1026558/

`b4` has also incorperated llm agents for the review workflow.
https://b4.docs.kernel.org/en/latest/maintainer/review.html#configuration

b4 is also heavily developed by Claude these days.

I don't think we can reasonably argue that Linux is not free software, and I
don't think we can argue for forking Linux to remove llm generated code.

My take on this is mostly apathy. I don't think we can reasonably challenge the
use in the FOSS community. The productivity boost of experienced developers
using these is too appealing when we are looking at overburdened FOSS
maintainers.

We've aleady been repeadetly DDoSed by these companies. Spending hundreds of
volunteers hours keeping our services running while the companies extract the
labour to sell back to the FOSS community, using their standing in the Linux
Foundation to further cement their usage in our communities.

Then the FOSS communities use these models without any care of the ethical considerations.

Is this depressing? Yes.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

Morten Linderud <foxboron@archlinux.org> writes:

> A lot of this is probably already a lost cause I think.

+1

I wonder if there is even consensus to refuse to package AI-rewritten
packages with a different license, such as python-chardet:

https://github.com/chardet/chardet/issues/327
https://github.com/chardet/chardet/issues/331

I think that is a separate category of LLM contributions, unlike the
LLM-assistance used for many years in the Linux kernel.

If AI-rewrites for copyright reasons becomes common, that is problematic
for a free software perspective.  One recurse is to actively chose to
not use such rewrites, but to insist on using copyleft packages as a
policy and preference in order to defend user's rights.

To some extent we already see this split, between copyleft-aligned
GNU/Linux distributions like Guix that default to GnuPG and GNU
coreutils, and some commercial distributions that is on a path to
replace all GPL'd code.

Given that we couldn't establish such consensus in the pre-AI times (for
GnuPG vs Seqoia and GNU coreutils vs uutils), and there even seem to
some preference towards the non-copyleft agenda, I think the same will
happen again for AI-rewrites.

The commercial dynamic is pro LLM and against copyleft.  It is possible
to offer an alternative but it requires an active choice and interested
developers/users.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1251 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Guillem Jover]

On Sat, 2026-03-07 at 16:31:18 +0100, Simon Josefsson wrote:
> To some extent we already see this split, between copyleft-aligned
> GNU/Linux distributions like Guix that default to GnuPG and GNU
> coreutils, and some commercial distributions that is on a path to
> replace all GPL'd code.
> 
> Given that we couldn't establish such consensus in the pre-AI times (for
> GnuPG vs Seqoia and GNU coreutils vs uutils), and there even seem to
> some preference towards the non-copyleft agenda, I think the same will
> happen again for AI-rewrites.
> 
> The commercial dynamic is pro LLM and against copyleft. […]

I'm not sure why you felt the need to drag the GnuPG issue here in
this context, when that's already messy enough.

The reason many upstream projects and distributions are distancing
themselves from GnuPG (at various speeds), is a thing of GnuPG's
upstream own making. There's been long standing concerns about its
UI, security and implementation. Mishandling the OpenPGP RFC process
and then subsequently getting off it, and not just refusing to implement
it but in addition creating a schism and a fork in the ecosystem did
not help matters, which is what has triggered many to seriously look
into alternative OpenPGP implementations (which thankfully we have many
to choose from now!). All this has had no relation whatsoever with
licensing.

(BTW and AFAIR most of Sequoia components are either LGPL or GPL.)

Regards,
Guillem

Re: Looking for advice on how to deal with potential slop packages

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

Morten Linderud <foxboron@archlinux.org> writes:

> A lot of this is probably already a lost cause I think.
>
> Linux accept LLM contributions (look for the `Assisted-by` tags), and there are
> already multiple subsystems that are being developed in-part, or full, by LLM
> agents.

There is a distinction between the chardet case [0] or otherwise
massively-AI driven development introducing instability and bugs, and this.

>
> See the LWN discussion: https://lwn.net/Articles/1026558/
>
> `b4` has also incorperated llm agents for the review workflow.
> https://b4.docs.kernel.org/en/latest/maintainer/review.html#configuration
>
> b4 is also heavily developed by Claude these days.
>
> I don't think we can reasonably argue that Linux is not free software, and I
> don't think we can argue for forking Linux to remove llm generated code.
>
> My take on this is mostly apathy. I don't think we can reasonably challenge the
> use in the FOSS community. The productivity boost of experienced developers
> using these is too appealing when we are looking at overburdened FOSS
> maintainers.

It is of course your right to feel that way and I don't entirely
disagree, but I also think we have some responsibility to our users to
protect them in the way we always have.

I don't think that Linux having some AI-assisted commits means that we
can't discuss or perhaps even have some consensus on handling some packages.

Say, by trying to avoid new chardet and lobbying reverse dependencies to
not require newer versions if they do so, or to port to
charset-normalizer.

I don't think we'd have this response if some software was being made
proprietary. It's the same thing in that it requires some effort to
rebut, just like also if sometihng becomes unmaintained and has a
suitable alternative, or whatever else. We do that all the time.

> We've aleady been repeadetly DDoSed by these companies. Spending hundreds of
> volunteers hours keeping our services running while the companies extract the
> labour to sell back to the FOSS community, using their standing in the Linux
> Foundation to further cement their usage in our communities.
>
> Then the FOSS communities use these models without any care of the ethical considerations.
>
> Is this depressing? Yes.

[0] https://lwn.net/SubscriberLink/1061534/3040c9a3a6271043/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

Michał Górny <mgorny@gentoo.org> writes:

> Hello, everyone.
>
> Seeing more and more packages embracing LLM-driven development (to the
> point of "vibe coding" or slopware), I'm looking for your ideas on how
> distributions should deal with that.  I'm basically torn between three
> things:
>
> 1. My duty towards the users to deliver up-to-date versions of software.
>
> 2. My duty towards the users to deliver *good* and *secure* software.
>
> 3. My ethical concerns, both directly related to LLM use, and to what
> people are using them for.

For those interested, we've started discussing it on the Gentoo side at
https://public-inbox.gentoo.org/gentoo-dev/fd8fea8a469a11e302dfd66dad76bbfa230198cf.camel@gentoo.org/
now too.

> [...]
>
> What are your experiences, thoughts and ideas how to deal with this?  I
> mean, staying on old software versions and hoping people will change
> their minds (or more precisely, LLMs will stop being subsidized and
> people will have to start paying serious money for their usage) is not
> exactly a good idea.  Going around and telling people "please switch
> from dependency X to Y because X is slop (and Y isn't yet)" doesn't
> sound like the best use of our time either.  And forking?  With the
> depressing state of FLOSS these days, I can't even find energy to
> maintain my own projects, let alone take anything else.
>

You know my position on this but saying it here for the benefit of the
list: I think some collaborative effort is needed just like we ask
people to port away from unmaintained dependencies or something that is
otherwise broken. chardet has an alternative AFAIK:
charset-normalizer. And we can lobby upstreams to not depend on new APIs
introduced only in "infected" versions.

Of course, that's still work, and I'm very tired of all of this already
too.

>
> [1] https://wiki.gentoo.org/wiki/Project:Council/AI_policy
> [2] https://github.com/crossbario/autobahn-python/issues/1716
> [3] https://github.com/crossbario/autobahn-python/issues/1735
> [4] https://github.com/crossbario/autobahn-python/issues/1782
> [5] https://github.com/crossbario/autobahn-python/discussions/1818
> [6] https://github.com/chardet/chardet/issues/327

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Am Samstag, 7. März 2026, 16:31:18 Mitteleuropäische Normalzeit schrieb Simon Josefsson:
> Morten Linderud <foxboron@archlinux.org> writes:
> 
> > A lot of this is probably already a lost cause I think.
> 
> +1

Here's another example of a (cryptography-related) package gone full auto.

https://github.com/cpan-authors/Crypt-OpenSSL-RSA/commits/main/?after=5d7e2e6faf3d6938b55aeebd40f5fb2379248c36+34

Lost cause or not, shouldnt we even try to fight this tendency?

I mean, it's one thing to vibe-code a sandboxed browser game where graphics glitches are
the worst possible outcome... but...

-- 
PD Dr. Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

"Andreas K. Huettel" <dilfridge@gentoo.org> writes:

> Am Samstag, 7. März 2026, 16:31:18 Mitteleuropäische Normalzeit
> schrieb Simon Josefsson:
>> Morten Linderud <foxboron@archlinux.org> writes:
>> 
>> > A lot of this is probably already a lost cause I think.
>> 
>> +1
>
> Here's another example of a (cryptography-related) package gone full auto.
>
> https://github.com/cpan-authors/Crypt-OpenSSL-RSA/commits/main/?after=5d7e2e6faf3d6938b55aeebd40f5fb2379248c36+34
>
> Lost cause or not, shouldnt we even try to fight this tendency?

Could the answer be in the follow-on question "How?"?

I can't think of any feasible way to oppose this tendency today.

LLM-authored code is already part of a growing list of low-level and/or
security critical components of the free software eco-system --
including, if I'm not mistaken, Linux, systemd, OpenSSL, Go crypto, etc.

One reaction could be to build a GNU distribution based only on software
components that doesn't contain LLM-authored code.  This assumes we can
even identify that code.  I think that will be challenging -- some
projects are adopting policies to accept LLM-contributions that doesn't
acknowledge or mention that a LLM-assistant was used.  How to make a
decision in that case?

A stronger reaction could be to build a GNU distribution based only on
software components that have a sufficiently strong no-LLM policy.  A
100% "Human-written Software" distribution, based on something similar
to Debian's DFSG but replacing (or augmenting) 'free software' with
'human-written software'.

These things are do-able, but I don't see anyone verbalize the ideas and
starting the work involved.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1251 bytes --]

Re: Looking for advice on how to deal with potential slop packages

[Bernhard M. Wiedemann]

[-- Attachment #1.1: Type: text/plain, Size: 621 bytes --]



On 07/03/2026 11.38, Michał Górny wrote:
> Hello, everyone.
> 
> Seeing more and more packages embracing LLM-driven development (to the
> point of "vibe coding" or slopware), I'm looking for your ideas on how
> distributions should deal with that.

https://lwn.net/SubscriberLink/1064541/d71f362f9681ad2b/
picked up on this topic.
While it mentions chardet, the focus is on a submission to openBSD.
Copyright is a major concern.
Maintainability is another, because nobody fully understands the 
generated code and it often duplicates plenty existing code, violating 
DRY/SPOT .


Ciao
Bernhard M.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]