Mastodon Feed
Boosted by cstanhope@social.coop ("Your weary 'net denizen"):
stsp@bsd.network ("Stefan Sperling") wrote:
There are forks of the #GameOfTrees version control system popping up merely because of worries that the project might eventually succumb to accepting LLM-generated contributions, then ending up on other people's lists of #noAI LLM-free alternatives.
Fork the code as much as you want, but please don't let your potential users hanging when important issues get fixed upstream, and keep in mind that I don't work with LLMs, have never even once asked an LLM for anything, and I don't intend to start. I don't believe the other developers involved are all as pristine as myself, but I've met most of them in person, do trust them, and have never seen anyone commit code which looked like they didn't write it.
As a community we are losing trust in established projects within the FOSS ecosystem very fast right now. I understand and share many of the concerns about LLMs, but the trend to quickly fork projects out of spite and fear without communication is also worrying. If you maintain a list of recommendations, please ask upstream projects which do not already have an obvious pro-LLM stance before recommending forks with little to no track record, especially when the software in question might handle sensitive data.
I have added the following to the project's README file. Not sure if this counts as a policy. To me it feels more like I'm writing down what should be common sense.
"""
Game of Trees is entirely handwritten and contributions generated by LLMs
will not be accepted. The main author (Stefan Sperling) has successfully
been avoiding LLMs and would prefer to keep it that way, even if/when legal
uncertainties around the copyright status of LLM-generated output settle.Should you feel a need to ask an LLM questions in order to help you understand
something, try asking us first. If you are truly trying to wrap your head
around something then you will learn from us, and we will learn from you.
We may have some expertise you are lacking, but because we cannot ignore what
we already know, we can be blind to problems you are seeing. Our code and
documentation can likely be improved as a result of communication, even before
you send a first patch.
"""