Hi Hugo, On 2026-05-04 at 11:41+02:00, Hugo Buddelmeijer wrote: > On 4/5/26 10:01, Nguyễn Gia Phong wrote: > > I like OpenJDK interim policy [3]: > > > > > Contributions in the OpenJDK Community must not include content > > > generated, in part or in full, by large language models, > > > diffusion models, or similar deep-learning systems. [...] > > > > > > Contributors in the OpenJDK Community may use generative AI tools > > > privately to help comprehend, debug, and review OpenJDK code > > > and other content, and to do research related to OpenJDK Projects, > > > so long as they do not contribute content generated by such tools. > > I could be OK with such a policy (as an LLM proponent). But I don't > understand how this works in practice. > > Developer: "Claude/Codex/.., please check this code I just wrote" > Claude: "There is a subtle security problem, which can easily be > remedied by rewriting the code as such:" > > Then what? The OpenJDK policy as written seems to indicate that the > rewrite cannot be used. The only way I can think of that would adhere > to the policy if the developer then goes to a second developer and > explains the problem and have the other developer do the rewrite without > being exposed to the LLM output. To me that just seems wasteful theater.
Not using content generated by LLMs is different from not taking suggestions from them, at least when copyright is concerned IMHO: - Algorithms and ideas are not copyrightable. - Most people do not remember by heart legally significant changes. Contributors should not worry about using things like list comprehensions, most memory-safety fixes, or single words that are similar to what LLMs generates. On 2026-05-04 at 11:41+02:00, Hugo Buddelmeijer wrote: > That still sounds like a waste, because then we'd still have to write > code that a machine can write for us. But I'd be okayish with such a > policy, as I primarily use LLMs to explore and to learn. Writing the > code is the easy part. A machine could also give me the source code of Unreal Engine, it does not mean I can _release_ it under the GPLv3. Likewise, I expect Unreal Engine cannot include GPL'ed code and remain proprietary. On 2026-05-04 at 11:41+02:00, Hugo Buddelmeijer wrote: > If LLMs are the one true evil, then the above all applies. Like if I > learned how to do 'list comprehension in guile' through human sacrifice, > then I should be banned from Guix and jailed. Speaking for myself, even if you learned it through genocide, I still have no problem incorporating your contributions into my free software projects as long as you have the rights to redistribute it. This includes even murdering the right holders and wait for XX years from now instead of waiting for them to die from other causes. On 2026-05-04 at 11:41+02:00, Hugo Buddelmeijer wrote: > Is that the crux of the matter? That we have a relatively high amount > of people who consider LLMs so bad that any use is always bad and always > leads to tainted code? > > Can I also add things to the list of unacceptable evils? (I can assure > you there would be no contributors left, certainly not myself.) The approach Oracle took (which I agree with) is about avoiding risks, which if you like evil/good alignments instead, trying to only do good and not doing evil, which is *not* avoiding association with evil. On 2026-05-04 at 11:41+02:00, Hugo Buddelmeijer wrote: > > As mentioned in the linked thread [2], > > while we wait for legal advisories from the FSF or FSFE, a similar > > temporary policy should be in place. > > > > [2]: https://yhetil.org/guix-devel/[email protected]/t/ > > We should also think for ourselves and discuss amongst ourselves. Well, > assuming we can all stay respectful of each other. The thread is really long and I don't expect anyone to reread the entire thing, but the context of the suggestion was that usually Guix does not directly do legal consultations, while the FSF(E) do. It's of course better if someone in Guix can hire a lawyer to do it, but that's even less likely to happen soon. Best wishes, Phong
signature.asc
Description: PGP signature
