Post B6EVbx6O5ml00uxMIa by millihertz@oldbytes.space
 (DIR) More posts by millihertz@oldbytes.space
 (DIR) Post #B6EVbw3A0Ia6kcRGd6 by millihertz@oldbytes.space
       1 likes, 1 repeats
       
       oh for FUCK'S SAKEhttps://codeberg.org/small-hack/open-slopwareSvarDOS all the way, then, i guess
       
 (DIR) Post #B6EVbx6O5ml00uxMIa by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       the one reservation i have is their characterisation of NetBSD as having "an ambiguous policy". in fairness, NetBSD's policy does sound like it was drawn up by a judge: it takes the quickest, narrowest route to a position (LLM'd code is presumed tainted) and kicks the can as far down the road as possible ("LLM'd code must not be submitted without written permission from core", but as far as i can see there is no documented process by which one could obtain written permission, nor any indication of how once might convince core that your interactions with the giant plagiarism machines were unique and special) without actually taking a position on LLM'd code itself.but to call it ambiguous appears to misunderstand the way judges tend to avoid ruling on any more than they have to. in practice the NetBSD position is more than sufficient to keep LLM'd code out of it for the foreseeable future, regardless of future legal developments. the presumption of taint is going to be more or less impossible to meaningfully overcome, and without a process for seeking permission for an exception, it seems highly unlikely that any such permission would be granted - especially given that the appearance of such permission would essentially act as a canary for those of us who care about such things.put it this why. i think my position on slopware is quite clear, but i'm entirely comfortable with NetBSD's policy. in practice, it's a ban - it's just couched in terms that would be difficult for anyone to actually argue with.
       
 (DIR) Post #B6EVbxcIBAHHbrsq1o by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       in fact, it turns out that QEMU's policy is more or less the same as NetBSD's - except it includes a rider that the policy may change in future, which is a rider NetBSD's policy doesn't require (the "written permission" bit covers it) - and yet NetBSD's policy is described as "ambiguous", while QEMU is endorsed as a project that "does not accept slop contributions"