For those of you who haven't seen: A satire website is hyping on Hacker News at the moment:
https://malus.sh/ " Clean Room as a Service. Finally, liberation from open source license obligations." I think it may fit in this thread, because it discusses licensing issues with LLMs and open source. Dominik On Sun 01 Mar 2026 07:55:18 PM GMT, Ihor Radchenko wrote: > Matthew Weymar <[email protected]> writes: > >> Of course, I can -- and of course, I did! >> >> Do you have a preference as to whether people do or do not use an LLM to >> write a patch?... If so, I am curious as to why. > > First reason is simple - I have been instructed by Emacs maintainers to > not accept LLM-written patches. This is because GNU does not yet have an > official policy on this. And GNU does not have a policy because the > licensing implications of LLM code are not yet clear. > So, I currently cannot accept anything that is generated by LLMs. > (We are discussing on some ways forward right now on GNU lists, but > there is no decision on the topic yet) > > The second reason is more important. > > I can clearly see that the patch is ignoring the basic Elisp standards. > For example, the \n in the docstrings made me think that you did not > review the patch much and just posted it as is after it was generated (I > am not sure if that's the case, but that's the impression). > > If my suspicion is correct, you are missing out on one of the benefits > of contributing to libre software - learning. Normally, even if you > never saw the Elisp standards documentation, you can follow the example > of the rest of Org code and get reasonable code quality, implicitly > learning the code style along the way. > > Third reason is my time. > > In most cases, it is more efficient for Org mode project to have patches > written by interested people - I can quickly review the patches, making > sure that the quality is good, and double-checking with the second pair > of eyes. That takes less time compared to me writing the same patches > myself. > > There are also patches from less experienced contributors. > These patches often take more time on my side compared to if I write > them myself. But by reviewing them, I get more people familiar with > contribution process and Org codebase. So, we end up growing the number > of contributors in the long run and again benefit the whole Org mode > project. > > However, if the patch is simply generated by LLM (especially by > inexperienced contributors or inexperienced LLM users), the time I spend > reviewing is much harder to justify. > > Do note that using LLM may be OK (let's forget about copyright issues > for a moment). LLMs are pretty good generating boilerplate code to > kickstart writing a patch. > But using LLM output without changes is generally > not the best idea. Unless you really know what you are doing and provide > detailed instructions and context, LLMs often suffer from subtle > mistakes in the code -- LLM-generated code MUST be reviewed carefully > before usage. Sometimes, it is simply faster to write code from scratch > compared to reviewing LLM output. I have to say that your patch is an > example of bad LLM code.
