Post
curious points about LLM bans:
as a result, it's ideal if the ban directly results from appeals to previously adjudicated concerns. this is why copyright is effective, because by selecting a license for the project you are already requiring that all contributions fall under a compatible license!
if you want to introduce new grounds for rejection such as ethical concerns, it's worth codifying those explicitly, and marking them as a new policy of the project. this will make it easier to litigate borderline cases in the future
but i'd also encourage considering the gnulib approach https://circumstances.run/@hipsterelectron/116121894991198670 where the enforcement of rejecting LLM contributions is stated in terms of your existing policies (in particular, copyright and review procedures).
i argue this is not a "cop-out" by any means, although it does avoid a direct ban. i'll explain why i believe this to be the ideal approach:
first, explicitly stating your requirements to avoid copyright liability helps to shield your project later if someone contributes code that was taken from elsewhere (LLM or not). if you have precise requirements that each contribution must conform to, then the contributor generally becomes liable for misrepresenting their contribution, instead of "poisoning" your whole project. this is related to why the fsf famously requires copyright assignment statements
that may not be terribly interesting to most people, but i argue that this reframing is actually where you can do the work of convincing anyone on the fence (contributors, users, lurkers) that LLMs are harmful to them. if you go through the process (like gnulib) of describing the necessary caveats to make an LLM contribution allowable, i believe you also produce a persuasive document enumerating all the liabilities LLM users incur.
Install bonfire.cafe
Get the full app experience
