On Wed, Jun 25, 2025 at 10:38:21PM +0200, Kevin Wolf wrote: > Am 25.06.2025 um 21:16 hat Michael S. Tsirkin geschrieben: > > On Mon, Jun 16, 2025 at 11:22:41AM +0200, Markus Armbruster wrote: > > > From: Daniel P. Berrangé <berra...@redhat.com> > > > > > > There has been an explosion of interest in so called AI code > > > generators. Thus far though, this is has not been matched by a broadly > > > accepted legal interpretation of the licensing implications for code > > > generator outputs. While the vendors may claim there is no problem and > > > a free choice of license is possible, they have an inherent conflict > > > of interest in promoting this interpretation. More broadly there is, > > > as yet, no broad consensus on the licensing implications of code > > > generators trained on inputs under a wide variety of licenses > > > > > > The DCO requires contributors to assert they have the right to > > > contribute under the designated project license. Given the lack of > > > consensus on the licensing of AI code generator output, it is not > > > considered credible to assert compliance with the DCO clause (b) or (c) > > > where a patch includes such generated code. > > > > > > This patch thus defines a policy that the QEMU project will currently > > > not accept contributions where use of AI code generators is either > > > known, or suspected. > > > > > > These are early days of AI-assisted software development. The legal > > > questions will be resolved eventually. The tools will mature, and we > > > can expect some to become safely usable in free software projects. > > > The policy we set now must be for today, and be open to revision. It's > > > best to start strict and safe, then relax. > > > > > > Meanwhile requests for exceptions can also be considered on a case by > > > case basis. > > > > > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > > > Reviewed-by: Kevin Wolf <kw...@redhat.com> > > > Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com> > > > Reviewed-by: Alex Bennée <alex.ben...@linaro.org> > > > Signed-off-by: Markus Armbruster <arm...@redhat.com> > > > > Sorry about only reacting now, was AFK. > > > > So one usecase that to me seems entirely valid, is refactoring. > > > > For example, change a function prototype, or a structure, > > and have an LLM update all callers. > > > > The only part of the patch that is expressive is the > > actual change, the rest is a technicality and has IMHO nothing to do with > > copyright. LLMs can just do it with no hassle. > > > > > > Can we soften this to only apply to expressive code? > > > > I feel a lot of cleanups would be enabled by this. > > Hasn't refactoring been a (deterministically) solved problem long before > LLMs became capable to do the same with a good enough probability? > > Kevin
Interesting. For example, I recently wanted to refector a bunch of bool fields to bit flags. Know of any tool that would do it without major pain? -- MST
