@ltning where do you see that?

@mwl https://codeberg.org/small-hack/open-slopware#operating-systems - links to offending commits and to standing policy on the matter.

@ltning @mwl That's BS. I opened an issue in that repo as the links they offer as evidence are either incorrect or misleading.

@emaste @mwl I agree the statement that FreeBSD is "slopware" is misleading - and it dilutes the term to the point of being nearly meaningless. But the "policy" linked is very much relevant, and I suspect the two commits may - in their simplicity - fall on different sides of the "line in the sand" that distinguishes between what is, and what isn't, acceptable. It could also be a matter of labelling in this case (making both commits fall on the same side of that line).

Whether code from external projects (llvm, zfs) should be subject to the same standards as core itself is a matter of some debate; the cost could be prohibitive if they are tested the same - but if they are not, then can we be sure the licensing holds?

And in the end, who decides if a piece of code is significant enough to be copyrightable, and therefore possible to apply a license to? IANAL, and neither are other contributors likely to be, and that is kind of the point. And even if we all were, I'm sure we'd disagree on all kinds of things anyway :)

@ltning @mwl I am the author of one of the commits they claim is LLM-generated; I'm sure nobody is seriously suggesting we wouldn't fix a reported security vulnerability because an LLM was used to help find it.

@emaste @mwl That is my point. Finding bugs is something LLMs are good at (but the training data is a problem, but not in scope here). Actually producing code - which cannot be copyrighted and thus licensed - is a different thing.

@ltning @mwl Exactly. Claiming that FreeBSD is slop because I wrote a patch for an issue that an LLM found is ridiculous.

@ltning @mwl To be explicit, the submission probably included a suggested fix, which may be identical to what I committed, because it's trivial and consistent with the way we normally initialize stack variables and missed in the reported instance. I'll take a look.