Some thoughts for those lacking the energy to read the full FAQ I linked: LLM Generated Content is fundamentally not copyrightable (whether code, text or images), and it may reproduce copyrighted materials used in its training. Therefore, clear identification/demarcation of generated code, and the specific tool that generated it is probably important. (The link contains detailed guidance rules near the bottom of the section). Some generation tools would be ineligible. Some versions of deep seek don't appear to be compatible with the definition of open source (unless you train your own model from scratch) because the model license has restrictions prohibiting specific types of uses <https://github.com/deepseek-ai/DeepSeek-Coder/blob/2f9fd85927c669dae3c0fbb2d607274023af243e/LICENSE-MODEL>. That would violate point 6 in the definition link included in the ASF guidance <https://opensource.org/osd>. Note the line in the license that says:
On Fri, Aug 28, 2026 at 11:03 AM Gus Heck <[email protected]> wrote: > Key consideration: ASF legal guidance on copyright and LLM generated code: > https://www.apache.org/legal/generative-tooling.html#include-in-contributions > > On Fri, Aug 28, 2026 at 7:32 AM Dawid Weiss <[email protected]> wrote: > >> Hi everyone, >> >> This email has a few thoughts - loosely connected - and I'm sorry >> if it reads like a stream-of-consciousness log but I've meant >> to write it for quite some time and today is the tipping point for me >> (hello, >> Malcolm Gladwell). >> >> So. As I'm sure you've noticed, more and more code is being generated >> these days. I have some thoughts I wanted to share about it. >> >> # Trust, role models, credibility. >> >> LLMs change how the open source model works - not just the code >> submitted but how we (humans) lack the means to evaluate or assess the >> skills of those who submit those patches. In the past, you could build >> your assessment of what a person knows/ can do by looking at what >> they contributed. Even if the code they produced was by and large of >> different flavors (think Mike McCandless vs Rob vs Uwe), you could >> tell these were virtuoso programmers and build your trust in their >> judgement and opinion. >> >> Can this model be applied these days? If not - how do we select future >> committers? >> >> # Person-to-person discussions >> >> I've also noticed that there's less and less of the person-to-person >> discussions on the dev list. I am sentimental, maybe, but I miss the >> oddball conversations and jokes we used to have in the past. Maybe >> it's just the project going graybeard or maybe it's the sign of >> changing times but I can't help but think that it's became less of a >> forum for programming enthusiasts exchanging (wild) ideas and learning >> from each other and more of a corporate fix-this-add-this repository >> with some infrastructure built on top. Or maybe it's just people >> departing to more attractive languages/ projects - this can't be ruled >> out too. I'm not judging here, I'm just observing the reality. >> >> # Programming, the LLMs and the future of Lucene >> >> I really like programming - I've always liked it. But LLMs are getting >> so good at understanding code (and improving it) that I find myself >> more and more frequently in awe. Take a look at my recent CI failure >> investigations (intentionally done with LLM help)... or this >> patch/issue I (well) wrote last night - it rewrites bzip2 >> decompression and the output (in java) is faster than my native >> bunzip2... >> >> https://github.com/apache/commons-compress/pull/811 >> >> It is this wild. >> >> I don't want to go into the debate of whether programmers are still >> needed at all - I don't have an established opinion on this... yet. >> The (human) learning process is definitely affected by those tools - >> not only they make one lazy but the sheer amount of code LLMs can >> produce is so overwhelming that it's hard to keep up (and after a >> while you just trigger auto-mode...). >> >> This said... I've been wondering if - in the spirit of oddball and >> crazy things we used to do - we shouldn't create a branch and let LLMs >> rip through whatever they like (collectively) as long as they keep the >> tests, code and output right. There's a saying that LLMs enable >> "everything you ever wanted to do but thought too complex". If you >> take a look at that bzip2 patch, it certainly feels this way for me. >> >> So... maybe we (as people) should brainstorm some wild, hacky ideas on >> the mailing list and then have them implemented just to see what they >> outcome is like? Wouldn't it be fun? :) >> >> Looking forward to hearing from you. >> >> Dawid >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
