On Thu, Jun 26, 2025 at 09:18:22AM +0100, Daniel P. Berrangé wrote: > On Wed, Jun 25, 2025 at 04:49:17PM -0400, Michael S. Tsirkin wrote: > > On Wed, Jun 25, 2025 at 04:47:06PM -0400, Stefan Hajnoczi wrote: > > > On Wed, Jun 25, 2025 at 4:39 PM Kevin Wolf <kw...@redhat.com> 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? > > > > > > It's easier to describe a desired refactoring to an LLM in natural > > > language than to figure out the regexes, semantic patches, etc needed > > > for traditional refactoring tools. > > > > > > Also, LLMs can perform higher level refactorings that might not be > > > supported by traditional tools. Things like "split this interface into > > > callbacks that take a Foo * argument and implement the callbacks for > > > both a.c and b.c". > > > > > > I think what Daniel mentioned is a good guide: if it's something that > > > you think it copyrightable, then avoid it. > > > > Right. Let's put that in the doc? > > In terms of mitigating risk I think it is better to avoid saying that > explicitly, and be seen to actively encourage acceptance of AI generated > code. The boundary between copyrightable and non-copyrightable code is > always pretty fuzzy and a matter of differing opinions. > > With regards, > Daniel
Well fuzzy is not what this doc does... -- MST
