contributing to projects that have slop in them has legal liability. you'd have to essentially hardfork to remove the slop from git history and such.
for my part, when i do work on this, what i will do is this: re-use existing nuke.list mechanism in lbmk (used already to delete dubious files, e.g. code files with unclear licensing in u-boot) to delete the slopped files. then provide cleaned versions of the same files, with necessary patching re-written as necessary, and files that use it patched to include e.g. foo.deslop.c instead of foo.c - then git history is removed inside tarballs. filter out the changelogs for projects accordingly.
this is the most reasonable way to do it on projects with very little slop. with projects that become almost entirely slop, a hard fork becomes necessary.
So what OS are you building on and running on the machine? https://codeberg.org/ethical-foss/open-slopware#kernels doesn't seem to list anything I would consider a good alternative to Linux, although illumos or 9front becoming the preferred build environment for libreboot would make my inner nerd happy.
currently debian linux, though i have porting lbmk to openbsd on TODO. with a few small exceptions (e.g. recent tmux patch) they're generally quite hostile to use of AI.
yes that is why i mention openbsd. i haven't ported lbmk to it yet, was going to months ago. i'll start up that effort again at some point. future releases will one day be built with openbsd, and when that day comes, my reasons to use linux will drop to near zero. i'm an avid fan and user of openbsd - i even maintain a port for it (librewolf web browser)
for my part, when i do work on this, what i will do is this: re-use existing nuke.list mechanism in lbmk (used already to delete dubious files, e.g. code files with unclear licensing in u-boot) to delete the slopped files. then provide cleaned versions of the same files, with necessary patching re-written as necessary, and files that use it patched to include e.g. foo.deslop.c instead of foo.c - then git history is removed inside tarballs. filter out the changelogs for projects accordingly.
this is the most reasonable way to do it on projects with very little slop. with projects that become almost entirely slop, a hard fork becomes necessary.